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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Serge E. Hallyn wrote:


Quoting Badari Pulavarty ([email protected]):


On Thu, 2007-06-07 at 15:37 -0500, Serge E. Hallyn wrote:


Quoting Badari Pulavarty ([email protected]):


On Thu, 2007-06-07 at 12:48 -0700, Andrew Morton wrote:


On Thu, 07 Jun 2007 10:06:37 -0700
Badari Pulavarty <[email protected]> wrote:


On Thu, 2007-06-07 at 12:43 -0400, Albert Cahalan wrote:


On 6/7/07, Badari Pulavarty <[email protected]> wrote:


BTW, I agree with Eric that its would be nice to use shmid as part
of name instead of forcing to be as inode number. It should be
possible for pmap to workout shmid from "key" or name. Isn't it ?


It is not at all nice.

1. it's incompatible ABI breakage
2. where will you put the key then, in the inode? :-)


Nope. Currently "key" is part of the name (but its not unique).


Changing to "SYSVID%d" is no good either. Look, people
are ***parsing*** this stuff in /proc. The /proc filesystem
is not some random sandbox to be playing in.

Before you go messing with it, note that the device number
also matters. (it's per-boot dynamic, but that's OK)
That's how one knows that /SYSV00000000 is not just
a regular file; sadly these didn't get a non-/ prefix.
(and no you can't fix that now; it's way too late)

Next time you feel like breaking an ABI, mind putting
"LET'S BREAK AN ABI!" in the subject of your email?


I am not breaking ABI. Its already broken in the current
mainline. I am trying to fix it by putting back the ino#
as shmid. Eric had a suggestion that, instead of depending
on the inode# to be shmid, we could embed shmid into name
(instead of "key" which is currently not unique).


BTW, I suspect this kind of thing also breaks:
a. fuser, lsof, and other resource usage display tools
b. various obscure emulators (similar to valgrind)
If you strongly feel that "old" behaviour needs to be retained, 
yup, we should put it back.  The change was, afaik, accidental.


here is the patch I originally suggested.


Confused.  Will this one-liner fix all the userspace breakage to which
Albert refers?


Yes. Albert, please correct me if I am wrong.


It will, but could lead to two different inodes with the same i_ino,
right?


Only if we generate same ID in two different namespaces. Is it currently
possible ? 

Should be nothing stopping it.

But like I say we never find the inode based on i_ino, and don't hash
the inode, so it might be ok.
Correct. We might end up with same shmid - which mean same inode# shows up in /proc/pid/maps. If we don't unshare pid namespace or look from parent namespace - we will end up seeing same shmid/inode# in different /proc/pid/maps, even though they are different. But I guess its okay.. 

Thanks,
Badari



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux