Re: [Patch] shmmin behaviour back to 2.2 behaviour

[Andries Brouwer <aeb@veritas.com>]

On Wed, Dec 27, 2000 at 01:16:44PM -0200, Marcelo Tosatti wrote:
> 
> On 27 Dec 2000, Christoph Rohland wrote:
> 
> > Hi Linus,
> > 
> > The following patchlet bring the handling of shmget with size zero
> > back to the 2.2 behaviour. There seem to be programs out, which
> > (erroneously) rely on this.
> 
> Just curiosity: do you know if any specification (POSIX?) defines this
> behaviour? 

I happen to see this post, but have not followed earlier discussion.
See a patch fragment

	-#define SHMMIN 0    /* min shared seg size (bytes) */
	+#define SHMMIN 1    /* min shared seg size (bytes) */

	+ if (size < SHMMIN || size > shm_ctlmax)
	+   return -EINVAL;

My first reaction is that this patch is broken, since
one usually specifies size 0 in shmget to get an existing
bit of shared memory (with known key but unknown size).

[Was this rehashed in earlier discussion? I wonder whether there
are any reasons to forbid size 0. Forbidding size 0 is
allowed by SUSv2 as I read it - it says

	The shmget() function will fail if: 

	[EINVAL]
		The value of size is less than the system-imposed minimum
		or greater than the system-imposed maximum,
		or a shared memory identifier exists for the argument key
		but the size of the segment associated with it is less
		than size and size is not 0. 

but is contrary to AIX, which says

	EINVAL
         A shared memory identifier does not exist and the Size
	parameter is less than the system-imposed minimum or greater
	than the system-imposed maximum.
	EINVAL
         A shared memory identifier exists for the Key parameter,
	but the size of the segment associated with it is less than
	the Size parameter, and the Size parameter is not equal to 0.

and is also contrary to the SysVR4 implementation.]

Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/