lkml.org 
[lkml]   [2007]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH] /proc/pid/maps doesn't match "ipcs -m" shmid
    On 6/8/07, Eric W. Biederman <ebiederm@xmission.com> wrote:
    > "Albert Cahalan" <acahalan@gmail.com> writes:
    > > On 6/7/07, Eric W. Biederman <ebiederm@xmission.com> 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
    > code.

    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-06-08 08:55    [W:4.357 / U:0.004 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site