On Nov 28, 2007 6:31 AM, Eric W. Biederman <[EMAIL PROTECTED]> wrote: > Ingo Molnar <[EMAIL PROTECTED]> writes: > > * Albert Cahalan <[EMAIL PROTECTED]> wrote: > >> On Nov 27, 2007 7:49 PM, Guillaume Chazarain <[EMAIL PROTECTED]> wrote:
> In a lot of ways if you access /proc/self and you get back information > that does not correspond to yourself the result is nonsense. Which > is a fairly mighty problem. In general, this is not a problem we have. /proc/self points to the process, not the task group leader. They are different. Look at /proc/*/stat, where the per-process info is summary data. The per-thread stat file is not summary data. This is intended to be true for all files in /proc; there may be some with bugs. Some of the data can not be summed up and will not always be shared. This is legacy crud. Don't use it, and don't try to "fix" it. It's there so that old programs can continute to work as long as weird threading isn't in use. Note that it was intended that non-legacy additions would normally be added to either the process directory or the thread directory, not both. I think somebody may have ripped out the ability to do this; at the very least there have been numerous illogical additions. > I'm still trying to understand which will break user space more, > adding /proc/task or changing /proc/self. Changing /proc/self makes you get per-thread data when you asked for per-process data. That's bad. > >> This one is probably best: > >> /proc/task -> 123/task/456 > >> (with both numbers showing) > > > > this sounds good to me. If it's a symlink then there's not much other > > choice because the thread PIDs do not even show up under /proc anymore. > > The name sounds good to me. > > I am not certain the two components make sense as we have a possible > permission problem where it is remotely possible that a task will > have permission to access /proc/<tid> but not /proc/<tgid>. If it hurts, don't do that. We allow foot shooting. > The reason I care is that we need to fix /proc/mounts. So once we > have /proc/task we can also have change /proc/mounts to > be a symlink to /proc/task/mounts. > > Once we get the /proc/mounts thing sorted out. There are several > other entries in /proc that need to that need to follow in it's wake > as they also become per namespace. /proc/net and /proc/sysvipc for > starters. As I predicted, the container bloat would be a never-ending source of bugs. You're discovering bugs where there were none. You'll never run out of this sort of problem. Keeping Linux lean and simple would be far better. - 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/
