Re: 2.6.24-rc3: find complains about /proc/net

Pavel Emelyanov [off-list ref] writes:

Rafael J. Wysocki wrote:

quoted

On Monday, 19 of November 2007, Pavel Machek wrote:

quoted

Hi!

I think that this worked before:

root@amd:/proc# find . -name "timer_info"
find: WARNING: Hard link count is wrong for ./net: this may be a bug
in your filesystem driver.  Automatically turning on find's -noleaf
option.  Earlier results may have failed to include directories that
should have been searched.
root@amd:/proc#

I'm seeing that too.

I have a better things with 2.6.24-rc3 ;)

# cd /proc/net
# ls ..
ls: reading directory ..: Not a directory

Ok.  That part is truly a bug.
Looks like you have tracked down the cause.
Grumble you are getting the wrong .. :(

and this

# cd /proc
# find
...
./net
find: . changed during execution of find
# find net
find: net changed during execution of find
# find net/
<this works ok however>

Moreover. Program that opens /proc/net and dumps the /proc/self/fd
files produces the following:

# cd /
# a.out /proc/net
...
lr-x------  1 root root 64 Nov 20 18:02 3 -> /proc/net/net (deleted)
...
# cd /proc/net
# a.out .
...
lr-x------  1 root root 64 Nov 20 18:03 3 -> /proc/net/net (deleted)
...

# a.out ..
...
lr-x------  1 root root 64 Nov 20 18:03 3 -> /proc/net
...

Yes all of those are nasty.  So much for my clever way of implementing
these things.  Grr. Simple hacks that almost work!

This all is somehow related to the shadow proc files.
E.g. the first problem (with -ENOTDIR) is due to the shadow /proc/net
dentry doesn't implement the .readdir method:

static const struct file_operations proc_net_dir_operations = {
        .read                   = generic_read_dir,
};

And I haven't managed to find out why the rest problems
occur...

Eric, do you have fixes for it?

Not exactly.  It is tricky.  I have known there are issues but so far
the difficulty of a better solution has been higher then my annoyance
level with this problem.

A special solution for !CONFIG_NET_NS may be practical for 2.6.24.

The only way I know of to really solve this problem cleanly and
completely is to make /proc/net an explicit symlink to /proc/self/net
and make /proc/<pid>/net a magic mountpoint (ala nfs automounts) that
mounts a per network namespace filesystem.  Al Viro wasn't to happy
when I suggested it (mostly because he was convinced such a solution
was likely to be full of races).

The half assed clean solution is to ensure nothing under /proc/net
gets cached and ensure the dentry tree is built properly, for the
current reader of /proc.

A third option is to fix .. in /proc/net.  Although I'm a bit
dubious if that will do more then fix a few symptoms with the
current solution.

Eric

* Eric W. Biederman [off-list ref] wrote:

quoted

lr-x------  1 root root 64 Nov 20 18:03 3 -> /proc/net
...

Yes all of those are nasty.  So much for my clever way of implementing 
these things.  Grr. Simple hacks that almost work!

btw., in case you feel inclined, i recently did some userspace coding 
and found to my surprise that /proc/self points to the parent task, not 
the thread itself (giving threads no real way to examine themselves). If 
you are hacking in this area, would it be a big trouble to add something 
like /proc/self-task/ or something like that? I had to use a raw gettid 
syscall to figure out the TID to get to /proc/*/tasks/TID/sched 
instrumentation info - which is quite a PITA.

	Ingo