David Miller a écrit :

It turns out that while procfs uses a different "mechanism", those
procfs symlinks do point to the real socket dentry, so when you
readlink() on it you do d_path() on the real socket dentry.

Al Viro just suggested a way around this to me:

1) Just mark the dentry HASHED by hand in the dentry flags, but don't
   actually hash it.

2) Create a special dentry->d_deleted method for sockets that returns
   0 and clears by hand the HASHED flag bit in the dentry (see what
   dput() does when this happens).

It's an abuse but it will work.

Thank you David and Al for the feedback.

Here is a new version of the patch with your suggestions included.

If necessary, I could split this patch in 3 elementary patches. I chose to
sent it as one patch for ease of discussion.

[RFC, PATCH] dont insert sockets/pipes dentries into dentry_hashtable.

We currently insert sockets/pipes dentries into the global dentry hashtable.
This is *useless* because there is currently no way these entries can be used
for a lookup(). (/proc/xxx/fd/xxx uses a different mechanism)

Machines with a lot of sockets/pipes might suffer from longer chains in dentry
hashtable.

Since dentries an unhashed dentry means __dpath() adds a " (deleted)", the 
trick for socket/pipe dentries is to :

- Right after d_alloc(), pretend they are hashed by clearing the 
DCACHE_UNHASHED bit. __dpath() & friends work as intended.

- Call d_instantiate() instead of d_add() : dentry is not inserted in hash table.

- Once dput() must clear the dentry, setting again DCACHE_UNHASHED bit inside 
the custom d_delete() function provided by socket/pipe code.


[patch 1/3] Small optimization to bypass RCU freeing in d_free() for dentries 
that were never hashed (like sockets and pipes). Such dentries dont have to 
wait a RCU grace period.

[patch 2/3] Change socket code to use d_instantiate() instead of d_add()

[patch 3/3] Change pipe code to use d_instantiate() instead of d_add()

Signed-off-by: Eric Dumazet <redacted>