@Hans Dietz:

Hans,

I'm the upstream man-pages maintainer, and I took a look at this bug
report to see if I should fix anything upstream.

You wrote:

[[
However, setting IPC_RMID in recent Linux kernels has the important side effect 
of CHANGING the key associated with the segment to 0 (aka, IPC_PRIVATE). 
Ideally, this side effect should be removed from the kernel, but the kernel 
folks seem unlikely to do this (the new behavior was mentioned in a 
discussion). Thus, I suggest fixing the shmctl man page to mention this strange 
behavior in the discussion of IPC_RMID: after "IPC_STAT will be set." add the 
phrase "The segment key may be changed to IPC_PRIVATE as a side effect of 
IPC_RMID."
]]

Your report suggests ("in recent kernels") that the kernel's behavior
changed at some point. As far as I can see, there has been no change
from 2.2 through to 2.6.31-rc with respect to this particular point. The
key was always changed to IPC_PRIVATE, so that some program could not do
a shmget() with the original key in order to obtain the ID of the now
deleted object. As far as I know, all other Unix systems take analogous
steps (to prevent a deleted object being re-used).

What is unusual about the Linux implementation (i.e., different from
other systems) is this behavior described in the
http://www.kernel.org/doc/man-pages/online/pages/man2/shmat.2.html man
page:

       On Linux, it is possible to attach a shared memory segment even if it is
       already marked to be deleted.  However, POSIX.1-2001 does not specify 
this
       behavior and many other implementations do not support it.

However, again, this behavior is unchanged in Linux 2.2 to 2.6.31-rc, as
far as I can see.

So, at this point, it doesn't look like any change needs to be made to
the man page. But, I await further input.

Thanks,

Michael

-- 
shmctl man differs from kernel operation
https://bugs.launchpad.net/bugs/62858
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to