Add note regarding the size of the output user space buffer
for PR_GET_TID_ADDRESS operation on x32/n32.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Give the reader a clue that there is another policy()
available that can't be set via sched_setscheduler(2).
See https://bugzilla.redhat.com/show_bug.cgi?id=1390546
Reported-by: Daniel Berrange <berrange@redhat.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
The discussion of 'socklen_t' editorializes and is repeated
across several pages. Replace it with a reference to accept(2),
where some details about this type are provided.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Further clarify that an error return should be used only
for diagnostic or remedial purposes.
Lifting Linus's words freely from
http://lkml.iu.edu/hypermail/linux/kernel/0207.2/0409.html
Re: close return value (was Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks)
Date: Wed Jul 17 2002 - 12:43:57 EST
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Looking at some historical source code (mostly from [1]) suggests
that the "close() always closes regardless of error return"
behavior has a long history, predating even POSIX.1-1990.
For example, in SVR4 for x86 (from the file sysvr4.tar.bz2 at
[1]), we see the following:
int
close(uap, rvp)
register struct closea *uap;
rval_t *rvp;
{
file_t *fp;
register int error;
if (error = getf(uap->fdes, &fp))
return error;
error = closef(fp);
setf(uap->fdes, NULLFP);
return error;
}
In the above, getf() can return EBADF. The other errors are
returned by closef(), but the file descriptor is deallocated
regardless of errors by setf().
A similar pattern seems to have been preserved into at least late
OpenSolaris days (verified from looking at the initial commit of
the illumos source code). There we find the following in
closeandsetf() (called by close()):
error = closef(fp);
setf(fd, newfp);
return (error);
Looking at the code of closef() in AIX 4.1.3 suggests that, as on
on Linux and FreeBSD, the open file is always released, regardless
of errors.
For Irix, 6.5.5, I'm not sure (the code is not so easy to quickly
read); it may be that it does return errors while leaving the FD
open.
[1] https://archive.org/download/various_operating_system_source_code
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
As Daniel Wagner noted, saying on the one hand that failing
to check the return value of close() is a "serious error"
seems contradicted by the next paragraph that notes that
the return value should be used for "just diagnostics".
Rework the text to resolve the apparent contradiction.
Reported-by: Daniel Wagner <wagi@monom.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
See Linus ancient comments re EINTR in
https://lkml.org/lkml/headers/2005/9/10/129
Date Sat, 10 Sep 2005 12:00:01 -0700 (PDT)
From Linus Torvalds <>
Subject Re: [patch 7/7] uml: retry host close() on EINTR
The FreeBSD 11.0 close() man page says similar:
In case of any error except EBADF, the supplied file
descriptor is deallocated and therefore is no longer valid.
For AIX:
http://publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/libs/basetrf1/close.htm
If the FileDescriptor parameter refers to a device and the
close subroutine actually results in a device close, and the
device close routine returns an error, the error is returned
to the application. However, the FileDescriptor parameter is
considered closed and it may not be used in any subsequent
calls.
See also:
http://austingroupbugs.net/view.php?id=529
and in particular:
http://austingroupbugs.net/view.php?id=529#c1200
Reported-by: Daniel Wagner <wagi@monom.org>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
At this stage, vague details (when does EINVAL get returned?) of
ancient implementations are little more than noise in the page.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Make the text a little clearer. In particular, clarify that the
raw system call (still) returns 0 on success.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Michael Kerrisk