SysV shm device number

SysV shm device number

[Albert Cahalan]

I'd like to reliably identify SysV shared memory
in the /proc/*/maps files. On one system, the entries
look like this:

40014000-40015000 r--s 00000000 00:04 0          /SYSV00000000 (deleted)
40015000-40016000 rw-s 00000000 00:04 32769      /SYSV000000ff (deleted)

On my system, they look like this:

30016000-30017000 r--s 00000000 00:06 870318096  /SYSV00000000\040(deleted)
30017000-30018000 rw-s 00000000 00:06 870350865  /SYSV000000ff\040(deleted)

So the key number is in the name, and the shmid
number is the inode number. The device major number
is 0, and the device minor number is 4 or 6.

Other than by creating my own SysV shared memory,
is there a way to tell what the minor number
should be?

Re: SysV shm device number

[Hugh Dickins]

On 29 Jan 2004, Albert Cahalan wrote:
> I'd like to reliably identify SysV shared memory
> in the /proc/*/maps files. On one system, the entries
> look like this:
> 
> 40014000-40015000 r--s 00000000 00:04 0          /SYSV00000000 (deleted)
> 40015000-40016000 rw-s 00000000 00:04 32769      /SYSV000000ff (deleted)
> 
> On my system, they look like this:
> 
> 30016000-30017000 r--s 00000000 00:06 870318096  /SYSV00000000\040(deleted)
> 30017000-30018000 rw-s 00000000 00:06 870350865  /SYSV000000ff\040(deleted)
> 
> So the key number is in the name, and the shmid
> number is the inode number. The device major number
> is 0, and the device minor number is 4 or 6.

I'm sure you don't mean to rely on it being 4 or 6: it just depends
on where in the init sequence init_tmpfs gets called, who else has
already allocated anon supers before it.

> Other than by creating my own SysV shared memory,
> is there a way to tell what the minor number should be?

I can't think of a better way.  I presume you're focussing on that
minor number because you don't want to be fooled by an mmap of a
regular file at root named /SYSVnnnnnnnn.  Beware that a shared
writable mmap of /dev/zero (or MAP_ANONYMOUS) also appears on
that major:minor, but named /dev/zero (deleted).

You might prefer to identify the minor number that way, via an
mmap(0, 1, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0),
I can't see any reason for their minors to diverge (so long as
minors make any sense at all here).

Hugh