Messages in this thread |  | | | Date | Sun, 12 Mar 2000 17:30:26 +0100 | | From | Jamie Lokier <> | | Subject | Re: 2.3.51 -- I am still seeing the"shmget: shm filesystem not mounted" error |
| |
Christoph Rohland wrote: > > Recompile the Gimp and it works fine. I don't why it fails with the new > > kernel, but the recompile does solve the problem (it did for me). Go > > figure. > > The new kernel does not allow shmat to a removed segment. > > #strace -f -e shmget,shmat,shmctl,shmdt gimp fotos/Pingu.jpg > [...] > shmget(IPC_PRIVATE, 16384, IPC_CREAT|0x1ff|0666) = 950281 > shmat(950281, 0, 0) = 0x40013000 > shmctl(950281, IPC_RMID, 0) = 0 > [pid 3912] shmat(950281, 0, 0) = -1 EINVAL (Invalid argument)
Just as well. Some ancient X shm code I just looked at waits for a confirmation event back from X before doing IPC_RMID, so I guess this behaviour of not allowing shmat after IPC_RMID was already the case for a certain "SunOS" some years ago.
As it should be.
I would guess that the Gimp recompile worked because of an autoconf test that asks, "can we attach to a deleted segment?". It's a guess - I haven't looked at the Gimp source at all.
That was potentially useful because shm segments have an unfortunate habit of sticking around when the programs that use them die. The earlier you can IPC_RMID those infernal things, the better.
Now that we have POSIX shm (though anon shared mappings would have been just as good), a nice X extension would be to do shm but accept a passed file descriptor instead of a SYSV shm id.
That way you never leak shm segments. It's more secure too -- and it properly fails if your X connection is via a proxy: the current shm method can even cause the X server to connect to the _wrong_ shm segment under some circumstances (multiple hosts, coincidental ids).
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
|  |