Re: [RFC][PATCH] /proc/pid/maps doesn't match "ipcs -m" shmid

From: Albert Cahalan
Date: Fri Jun 08 2007 - 02:52:21 EST

On 6/8/07, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
"Albert Cahalan" <acahalan@xxxxxxxxx> writes:
> On 6/7/07, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:

>> So it looks to me like we need to do three things:
>> - Fix the inode number
>> - Fix the name on the hugetlbfs dentry to hold the key
>> - Add a big fat comment that user space programs depend on this
>> behavior of both the dentry name and the inode number.
> Assuming that this proposed fix goes in:
> Since the inode number is the shmid, and this is a number
> that the kernel randomly chooses AFAIK, there should be
> no need to have different shm segments sharing the same
> inode number.

Where we run into inode number confusion is that all of
these shm segments are actually files on a tmpfs filesystem
somewhere, and by making the inode number the shmid we loose
the tmpfs inode number. So it is possible we get tmpfs inode
number conflicts. However the inode number is not used for
anything, and the files are not visible in any other way except
as shm segments so it doesn't matter.

Eh, the kernel choses both shmid and tmpfs inode number.
You could set a high bit in one or the other.

There is another case with ipc namespaces where we ultimately need
to support duplicate shmids on the same machine (so migration
is a possibility). However by and large the user space
processes with duplicate ids should be invisible to each other.

On the bright side, this only screws up people who get the
crazy idea that processes can be migrated.

> The situation with the key is a bit more disturbing, though
> we already hit that anyway when IPC_PRIVATE is used.
> (why anybody would NOT use IPC_PRIVATE is a mystery)
> So having the key in the name doesn't make things worse.

Having "SYSV" in the name appears mandatory. Otherwise you
don't even know it is a shm file. Although I may be confused.

It's mandatory for a different reason: to satisfy parsers.

It is nearly useless for identifying shm files. Look what I can do:
touch /SYSV00000000
touch '/SYSV00000000 (deleted)'

(so pmap creates a shm, looks for the address in /proc/self/maps,
determines the device major/minor in use, and then uses that)

Hmm. Thinking about this I have just realized that we may want
to approach this a little differently. Currently I am reusing
the dentry and inode structure that hugetlbfs and tmpfs return
me, and simply have a distinct struct file for each shm mapping.

There is a little more cost but it may actually make sense to have
a dentry and inode that is specific to shm.c so we can do whatever
we need to without adding requirements to the normal tmpfs or hugtlb

Piggybacking on tmpfs has always seemed a bit dirty to me.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at