Re: [Patch] shmmin behaviour back to 2.2 behaviour

[Christoph Rohland <cr@sap.com>]

Andries Brouwer <aeb@veritas.com> writes:

> On Wed, Dec 27, 2000 at 01:16:44PM -0200, Marcelo Tosatti wrote:
> I happen to see this post, but have not followed earlier discussion.
> See a patch fragment

(The patch does not show a lot of context. You should look at the
whole files)

> 
> 	-#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).

That's still covert: The check is moved out of shmget into the create
function. So you cannot create segments of size 0 but you can get
existing segments by giving a size 0.

> [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,

We match this with a system-imposed minimum of 1 now.

> 		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. 

We don't match this exactly since we allow arbitrary sizes smaller
than segment size for existing segments (0 included).

> 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.

That's what we do and always did.

So should we go for SUSv2? I do not think that we should restrict the
shmget so late in the release cycle. We could enhance this check
further in 2.5 perhaps.

Greetings
                Christoph

-
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/