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/
This archive was generated by hypermail 2b29 : Sun Dec 31 2000 - 21:00:10 EST