Comment 4 for bug 62858

@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