shmmin behaviour back to 2.2 behaviour
PATCH 1/1 shmmin behaviour back to 2.2 behaviour
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
include/linux/shm.h +1 -1
@@ -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 */
ipc/shm.c +3 -3
@@ -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 ) {
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Christoph Rohland
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
Signature · 9 lines
---------------- 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 |________/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Dave Gilbert
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines · Christoph Rohland
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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · Marcelo Tosatti
Quoted 3 lines · Christoph Rohland
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 11 lines · Marcelo Tosatti
Quoted 5 lines · Christoph Rohland
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Andries Brouwer
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)
Quoted 10 lines
-#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.
Quoted 9 lines
[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.
Quoted 3 lines
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).
Quoted 10 lines
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 [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 7 lines · Christoph Rohland
Quoted 3 lines
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.)
Quoted 2 lines
We don't match this exactly since we allow arbitrary sizes smaller than segment size for existing segments (0 included).
Good.
Quoted 1 line
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines
Quoted 1 line
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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 3 lines · Alan Cox
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/
Quoted 5 lines
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)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/