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.
Greetings
Christoph
diff -uNr c/include/linux/shm.h c1/include/linux/shm.h
--- c/include/linux/shm.h Fri Dec 22 10:20:08 2000
+++ c1/include/linux/shm.h Tue Dec 26 19:52:15 2000
@@ -10,7 +10,7 @@
*/
#define SHMMAX 0x2000000 /* max shared seg size (bytes) */
-#define SHMMIN 0 /* min shared seg size (bytes) */
+#define SHMMIN 1 /* min shared seg size (bytes) */
#define SHMMNI 4096 /* max num of segs system wide */
#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide (pages) */
#define SHMSEG SHMMNI /* max shared segs per process */
diff -uNr c/ipc/shm.c c1/ipc/shm.c
--- c/ipc/shm.c Fri Dec 22 10:05:38 2000
+++ c1/ipc/shm.c Tue Dec 26 19:53:35 2000
@@ -179,6 +179,9 @@
char name[13];
int id;
+ if (size < SHMMIN || size > shm_ctlmax)
+ return -EINVAL;
+
if (shm_tot + numpages >= shm_ctlall)
return -ENOSPC;
@@ -222,9 +225,6 @@
{
struct shmid_kernel *shp;
int err, id = 0;
-
- if (size < SHMMIN || size > shm_ctlmax)
- return -EINVAL;
down(&shm_ids.sem);
if (key == IPC_PRIVATE) {
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.
Hi Christoph,
I think I've come to the conclusion that Xine does not in the case I've
found, rely on this - it is a separate bug related to Xv telling xine that
it needs 0 bytes.
Dave
--
---------------- Have a happy GNU millennium! ----------------------
/ Dr. David Alan Gilbert | Running GNU/Linux on | Happy \
\ gro.gilbert @ treblig.org | Alpha, x86, ARM and SPARC | In Hex /
\ ___________________________|___ http://www.treblig.org |________/
Dave Gilbert <[email protected]> writes:
> I think I've come to the conclusion that Xine does not in the case
> I've found, rely on this - it is a separate bug related to Xv
> telling xine that it needs 0 bytes.
Yes, but this bug did not show on 2.2. It simply failed in shmget.
Probably it makes more sense to fail on creation of zero byte segments
and getting existing ones with zero length being legal... (The latter
is needed). That's what the patch does.
Greetings
Christoph
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?
Marcelo Tosatti <[email protected]> writes:
> On 27 Dec 2000, Christoph Rohland wrote:
> > 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 don't think so. IMNSHO it is not legal to call shmget with size <
SHMMIN. But there are programs which do that successfully on Linux
2.2. And I learnt not to break them without reason.
Greetings
Christoph
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
Andries Brouwer <[email protected]> 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
On Thu, Dec 28, 2000 at 01:01:53PM +0100, Christoph Rohland wrote:
> > 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
> That's still covered: 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.
Good. (The patch fragment gave the impression that 0 would be illegal.)
> We don't match this exactly since we allow arbitrary sizes smaller
> than segment size for existing segments (0 included).
Good.
> So should we go for SUSv2?
No.
I regard shm* as obsolete. New programs will probably not use it.
So, the less we change the better. Moreover, the SUSv2 text is broken.
One of these years the present Austin drafts will turn into the
new POSIX standard. That would be a good moment to look again.
Andries
> > So should we go for SUSv2?
>
> No.
> I regard shm* as obsolete. New programs will probably not use it.
> So, the less we change the better. Moreover, the SUSv2 text is broken.
There are fundmental things shm* can do that mmap cannot. Does posix shm
handle those (leaving segments alive but unattached being the obvious one)
Alan Cox <[email protected]> writes:
> There are fundmental things shm* can do that mmap cannot. Does posix
> shm handle those (leaving segments alive but unattached being the
> obvious one)
Yes:
shmget == shm_open (+ ftruncate(fd, size))
shmat == mmap (0, size, , , fd, 0)
shmdt == munmap (addr, size);
shmctl(IPC_RMID) == shm_unlink ()
shmctl(IPC_STAT) == fstat();
shmctl(IPC_LOCK) == mlock() /*nearly*/
shmctl(IPC_SET) == fchown(), fchmod()
You can get the Linux special behaviour to be able to attach to a
removed segment by its shmid by passing the file descriptor for the
posix shm from the attached process to the attaching process.
Did I miss something?
Christoph
> You can get the Linux special behaviour to be able to attach to a
> removed segment by its shmid by passing the file descriptor for the
> posix shm from the attached process to the attaching process.
>
> Did I miss something?
Not that I've ever used 8)