# Re: \[PATCH v8 07/11\] proc: flush task dcache entries from all procfs instances

- From: Linus Torvalds \<torvalds@linux-foundation.org\>
- Date: 2020-02-12 19:50:20 
- List: linux-security-module
- Page: https://ratatoskr.run/linux-security-module/2020/02/172655
- Thread: https://ratatoskr.run/linux-api/2020/02/172639/t.md

```text
On Wed, Feb 12, 2020 at 11:18 AM Eric W. Biederman
[ref] wrote:
>
> > So it's just fs_info that needs to be rcu-delayed because it contains
> > that list. Or is there something else?
>
> The fundamental dcache thing we are playing with is:
>
>         dentry = d_hash_and_lookup(proc_root, &name);
>         if (dentry) {
>                 d_invalidate(dentry);
>                 dput(dentry);
>         }

Ahh. And we can't do that part under the RCU read lock. So it's not
the freeing, it's the list traversal itself.

Fair enough.

Hmm.

I wonder if we could split up d_invalidate(). It already ends up being
two phases: first the unhashing under the d_lock, and then the
recursive shrinking of parents and children.

The recursive shrinking of the parent isn't actually interesting for
the proc shrinking case: we just looked up one child, after all. So we
only care about the d_walk of the children.

So if we only did the first part under the RCU lock, and just
collected the dentries (can we perhaps then re-use the hash list to
collect them to another list?) and then did the child d_walk
afterwards?

             Linus
```