Re: proc/bus.usb regression in : [NETNS]: Fix /proc/net breakage

[Eric W. Biederman]

Giacomo Catenazzi <cate@xxxxxxxxxx> writes:

> Andrew Morton wrote:
>> On Mon, 3 Dec 2007 19:00:25 GMT Linux Kernel Mailing List
> <linux-kernel@xxxxxxxxxxxxxxx> wrote:
>> 
>>> Gitweb:
> http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
>>> Commit:     2b1e300a9dfc3196ccddf6f1d74b91b7af55e416
>>> Parent:     e03ba84adb62fbc6049325a5bc00ef6932fa5e39
>>> Author:     Eric W. Biederman <ebiederm@xxxxxxxxxxxx>
>>> AuthorDate: Sun Dec 2 00:33:17 2007 +1100
>>> Committer:  Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
>>> CommitDate: Sun Dec 2 00:33:17 2007 +1100
>>>
>>>     [NETNS]: Fix /proc/net breakage
>>>     
>>>     Well I clearly goofed when I added the initial network namespace support
>>> for /proc/net.  Currently things work but there are odd details visible to
>>>     user space, even when we have a single network namespace.
>>>     
>>>     Since we do not cache proc_dir_entry dentries at the moment we can just
>>>     modify ->lookup to return a different directory inode depending on the
>>>     network namespace of the process looking at /proc/net, replacing the
>>>     current technique of using a magic and fragile follow_link method.
>>>     
>>>     To accomplish that this patch:
>>>     - introduces a shadow_proc method to allow different dentries to
>>>       be returned from proc_lookup.
>>>     - Removes the old /proc/net follow_link magic
>>>     - Fixes a weakness in our not caching of proc generic dentries.
>>>     
>>> As shadow_proc uses a task struct to decided which dentry to return we can
>>> go back later and fix the proc generic caching without modifying any code
>>>     that uses the shadow_proc method.
>> 
>> This patch caused the binfmt_misc regression reported in
>> http://bugzilla.kernel.org/show_bug.cgi?id=9504
>
> This patch also doesn't allow to mount /proc/bus/usb

Agreed.

Strictly speaking the mounts work but we just can't find them.
It is equally bad either way.

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/