Michael Kerrisk [Fri, 17 Dec 2004 12:20:07 +0000 (12:20 +0000)]
Martin Schulze, mtk
Removed errno declaration from prototype, added notes
on historical need for this declaration.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=174175
Michael Kerrisk [Thu, 16 Dec 2004 14:45:45 +0000 (14:45 +0000)]
Enrico Zini
Added text to clarify that S_IS*() macros should be applied
to st_mode field.
as per: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249698
Michael Kerrisk [Thu, 16 Dec 2004 14:24:00 +0000 (14:24 +0000)]
After bug report from John V. Belmonte
Updated init and quit scripts to reflect kernel 2.4/2.6 reality
(Scripts taken from drivers/char/random.c)
as per http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=247779
[[.TP
.B IP_TTL
-Set or retrieve the current time to live field that is send in every
packet
-send from this socket.
+Set or retrieve the current time to live field that is used in every
packet
+sent from this socket.
This is a very ill written code, since realloc returning
NULL do not deallocate the original memory block. Such a
statement has a potential to become significant memory
hole. I suggest to correct this example since:
1. It may trick naive programmers to write bad code
2. It may lead skeptic observers to the believe
the whole Linux is written in a similar style.
Regards Jan Kuznik
]]
This guy is right on the money!
I've changed that example, so that the above code has been replaced by:
char *np;
...
if ((np = realloc (p, size)) == NULL) {
free(p);
return NULL;
} else {
p = np;
}
[[
shm_open(3) refers to O_RWDR during discussion of the possible values of
oflags, and later refers to O_RDWR. The reference to O_RWDR is
incorrect (likely a typo) and should be changed to O_RDWR.
]]
Michael Kerrisk [Mon, 13 Dec 2004 11:32:37 +0000 (11:32 +0000)]
Date: Mon, 13 Dec 2004 12:09:43 +0100 (MET)
From: "Michael Kerrisk" <mtk-manpages@gmx.net>
To: Andries Brouwer <Andries.Brouwer@cwi.nl>
Subject: Re: errno
Hi Andries,
> On Fri, Dec 10, 2004 at 05:07:36PM +0100, Michael Kerrisk wrote:
>
> > I added this text to fcntl.2:
> >
> > BUGS
> > A limitation of the Linux system call conventions means that
> > if a (negative) process group ID to be returned by F_GETOWN
> > falls in the range -1 to -4095, then the return value is
> > wrongly interpreted by glibc as an error in the system call;
> > that is, the return value of fcntl() will be -1, and errno
> > will contain the (positive) process group ID.
>
> Yes.
>
> (Maybe glibc always did this, early libc considered any negative
> return value an error. On the other hand, not all the world is an i386 -
> IBM has just decided that we don't need any i386's anymore
> and sold their stuff to the Chinese - we must use PPC, as Linus
> does already - and on other architectures we do not have this
> ugliness, I think.)
>
> You might consider adding "i386" somewhere:
> A limitation of the Linux i386 system call conventions ...
Some testing on ia64 (RedHat EL 3.0, 2.4.21) and
alpha (2.4.18, Debian 3.0) showed that any negative PGID value
causes F_GETOWN to fail.
My limited reading of the ia64 source:
sysdeps/unix/sysv/linux/ia64/sysdep.h
shows that there is a comment about the -4095 value there,
but that doesn't seem to reflect the reality of the code.
Reading the source, the -4095 limit seems to hold on some
other architectures, e.g.:
Unfortunately, I have no non-x86 systems other than the above
alpha and ia64 (HP-testdrive) on which I can test.
I modified the text a little:
BUGS
A limitation of the Linux system call conventions on some
architectures (notably x86) means that if a (negative) pro‐
cess group ID to be returned by F_GETOWN falls in the range
-1 to -4095, then the return value is wrongly interpreted
by glibc as an error in the system call; that is, the
return value of fcntl() will be -1, and errno will contain
the (positive) process group ID.
I've left a FIXME in the man page source noting that details have
yet to be sorted out for ia64, alpha, etc.
Michael Kerrisk [Fri, 10 Dec 2004 16:28:25 +0000 (16:28 +0000)]
[Further notes on that F_GETOWN bug]
Hi Andries,
[Just for my own reference, I reinclude the pointer to Philippe
Troin's patch
http://marc.theaimsgroup.com/?l=linux-kernel&m=108380640603164&w=2
]
> > > Except of course for fcntl(fd, F_GETOWN) where the owner is a
> > > (negative) process group... If the owning process group has a "low
> > > enough" PGID, it collides with errors and glibc reports an error and
> > > sets errno to -PGID. One might argue that in this instance, that the
> > > BSD's overloading of the pid field with pgids is at fault, but the
> > > bug
> > > still remains :-)
> >
> > I believe that practically speaking this is a non-issue. The
> > lowest PID / PGID that can be allocated to a process other than
> > init or a kernel thread is 300. (RESERVED_PID in kernel/pid.c
> > in 2.6, details differ, but same limit in <= 2.4.)
>
> Hmm. RESERVED_PIDS is used as starting value after overflow,
> not as a starting value at the beginning. I think you are mistaken.
Hmm -- yes. And I was in any case assuming the notion
of a process that might do an F_SETOWN assigning
its own PGID to the socket -- but that might not be so.
And I was overlooking a comment in the fs/fcntl.c
sources that reiterates the point:
case F_GETOWN:
/*
* XXX If f_owner is a process group, the
* negative return value will get converted
* into an error. Oops. If we keep the
* current syscall conventions, the only way
* to fix this will be in libc.
*/
err = filp->f_owner.pid;
force_successful_syscall_return();
break;
And now I've actually created the error in userland code.
It seems that whenever the -PGID retrieved by F_GETOWN is
smaller than 4096, then it is interpreted as an error.
Now I see the relevant code in
sysdeps/unix/sysv/linux/i386/sysdep.h:
==
/* Linux uses a negative return value to indicate syscall errors,
unlike most Unices, which use the condition codes' carry flag.
Since version 2.1 the return value of a system call might be
negative even if the call succeeded. E.g., the `lseek' system call
might return a large offset. Therefore we must not anymore test
for < 0, but test for a real error by making sure the value in %eax
is a real error number. Linus said he will make sure the no syscall
returns a value in -1 .. -4095 as a valid result so we can savely
test with -4095. */
Michael Kerrisk [Thu, 25 Nov 2004 14:39:43 +0000 (14:39 +0000)]
Consolidated mlock.2, munlock.2, mlockall.2, and munlockall.2 material into single page to eliminate duplicated material; updated notes for 2.6.9 changes in permissions and limist on memory locking
projects / thirdparty / man-pages.git / log
