Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 12 Feb 2020 11:49:58 -0800
From: Linus Torvalds <>
To: "Eric W. Biederman" <>
Cc: LKML <>, 
	Kernel Hardening <>, Linux API <>, 
	Linux FS Devel <>, 
	Linux Security Module <>, 
	Akinobu Mita <>, Alexander Viro <>, 
	Alexey Dobriyan <>, Andrew Morton <>, 
	Andy Lutomirski <>, Daniel Micay <>, 
	Djalal Harouni <>, "Dmitry V . Levin" <>, 
	Greg Kroah-Hartman <>, Ingo Molnar <>, 
	"J . Bruce Fields" <>, Jeff Layton <>, 
	Jonathan Corbet <>, Kees Cook <>, Oleg Nesterov <>, 
	Solar Designer <>
Subject: Re: [PATCH v8 07/11] proc: flush task dcache entries from all procfs instances

On Wed, Feb 12, 2020 at 11:18 AM Eric W. Biederman
<> 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.


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


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.