Thread (4 messages) 4 messages, 4 authors, 2020-02-12

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

flat view

From: Al Viro <viro@zeniv.linux.org.uk>
Date: 2020-02-12 19:47:42
Also in: linux-fsdevel, linux-security-module, lkml

On Wed, Feb 12, 2020 at 10:45:06AM -0800, Linus Torvalds wrote:
On Wed, Feb 12, 2020 at 7:01 AM Eric W. Biederman [off-list ref] wrote:
quoted
Fundamentally proc_flush_task is an optimization.  Just getting rid of
dentries earlier.  At least at one point it was an important
optimization because the old process dentries would just sit around
doing nothing for anyone.
I'm pretty sure it's still important. It's very easy to generate a
_ton_ of dentries with /proc.
quoted
I wonder if instead of invalidating specific dentries we could instead
fire wake up a shrinker and point it at one or more instances of proc.
It shouldn't be the dentries themselves that are a freeing problem.
They're being RCU-free'd anyway because of lookup. It's the
proc_mounts list that is the problem, isn't it?

So it's just fs_info that needs to be rcu-delayed because it contains
that list. Or is there something else?
Large part of the headache is the possibility that some joker has
done something like mounting tmpfs on /proc/<pid>/map_files, or
binding /dev/null on top of /proc/<pid>/syscall, etc.

IOW, that d_invalidate() can very well have to grab namespace_sem.
And possibly do a full-blown fs shutdown of something NFS-mounted,
etc...
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help