Kirill Korotaev <[email protected]> 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 <[email protected]>
>
> 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 [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]
