Re: 2.3.51 -- I am still seeing the"shmget: shm filesystem not mounted" error

From: Jamie Lokier (lk@tantalophile.demon.co.uk)
Date: Sun Mar 12 2000 - 12:56:36 EST


Alan Cox wrote:
> I'd disagree. The remove and attach technique is very very commonly used
> by other applications in order to ensure the segment is deleted if a program
> crashed - directly analogous to open/unlink/read.

The problem is that shm segments are like temporary files in a lot of
way. You can't do open/unlink pass the name of a tmp file to another
program either -- so why should you be able to do it with shm segments?

To do open/unlink with multiple programs, you need some way to pass a
file descriptor around.

Besides, the creat/remove technique _still_ leaks from time to time. I
have seen it -- more and more shm segments being added because a program
crashed between the create and the remove.

> Gimp wont be the only thing that breaks. So the old behaviour needs to work
> at least for SYS5 IPC, what posix ipc does is another matter

I propose we wait and see what else breaks.

I would really like to see programs motivated to use a file descriptor
passing method for X. Currently these things can go wrong with X SHM:

    - The X connection is local, so you create a SHM segment. But the
      server is remote via a local proxy (an increasingly common
      arrangement), so the SHM fails. Some programs fall over at this
      point, but they can be fixed to fall back.

    - Same scenario but the server finds a SHM segment on it's system
      with the id you passed. Very bad: you think it succeeded, but the
      wrong images appear. It can even be a security hole.

    - Same again but you're reading images from X. E.g. to read font
      bitmaps. Very bad: you just trashed another applications shm
      segment.

    - Segments tend to get leaked because programs sometimes crash
      before IPC_RMID. On some systems, the total space is limited too,
      so you can't afford to have lots of them. Maybe this happens less
      with Linux. Typical fix: a script to delete bogus shms is run at
      the start of the application. Result: application occasionally
      breaks other applications or instances of itself.

These are typical, but easily fixed application problems:

    - The server is local but on a different IP to your standard
      address. You neglect to check all alias addresses so you don't
      use SHM even though you probably should.

    - You check for SHM extension, find it, try SHM and it fails. You
      crash. Yes I've seen this.

All the mess I can think of, including the "maps wrong SHM segment"
problem are all fixed nicely by using fd passing over a unix socket.
That, IMO, is the friendly way to establish a shm area with the X
server.

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



This archive was generated by hypermail 2b29 : Wed Mar 15 2000 - 21:00:21 EST