Re: [RFC][PATCH 20/20] proc: Update /proc to support multiple pidspaces.

[Eric W. Biederman]

Kirill Korotaev <dev@xxxxx> writes:

> Hello,
>
>> This patch does a couple of things.
>> - It splits proc into proc and proc_sysinfo
>> - It adds pspace support to proc
>> - It adds getattr methods to ensure proc has the proper hard link count.
>> - It increases the size of a couple of buffers by one to avoid buffer overflow
>> - It moves /proc/mounts and /proc/loadavg into the proc filesystem from
> proc_sysinfo
>> Sorry for the big patch.  When I start feeding this changes seriously I will
>> split this patch.
>> The split of /proc into mutliple filesystems works well however it comes
>> with one downsides.  There are now some directories where cd -P <subdir>/..
>> is not a noop.  Basically it is doing the equivalent of following symlinks
>> into an internal kernel mount.  It is well defined and safe behaviour but
>> I'm not certain if it is desirable.
>> Signed-off-by: Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
>
> This one is really ugly.

It is certainly to much at one time, and the code while semanticly 
interesting is still has significant issues with the implementation.
But a lot of the ugliness is inherent in the current implementation of
/proc and not what I am trying to do with it.

> And it is also controversial to your own idea of having separate namespaces, 
> but introduces a pointer to proc_mnt in pspace.

An instance of /proc being connected to a pid space is perfectly
natural.  /proc is after all the filesystem that reports what is in a
pspace.

I freely admit the way I am using the internal mount of proc is
wrong, and is something that needs to be resolved before I submit
this for kernel inclusion.  I was attempting to solve the problem
of having duplicate dcache entries in my recursive structure.
Unfortunately it was one of those clever solutions that only gets
you 99% of the way to where you want to go.

> You have many namespaces to which task_struct refers.
> Do you want proc to work in any configuration of namespaces?
Yes.

> Then you can't have pointers to proc_mnt from namespaces.
> Well, I understand that proc is the most painfull for you... yeah...

proc is the painful for any pid change in how pids are dealt with.
So far I have not seen a single implementation that cleanly and
correctly addresses all of the issues (including mine :)

Eric


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/