[PATCH 0/7] proc: Dentry flushing without proc_mnt

Just because it is less of a fundamental change and less testing I went
and looked at updating proc_flush_task to use a list as Al suggested.

If we can stand an sget/deactivate_super pair for every dentry we want
to invalidate I think I have something.

Comments from anyone will be appreciated I gave this some light testing
and the code is based on something similar already present in proc so
I think there is a high chance this code is correct but I could easily
be wrong.

Linus, does this approach look like something you can stand?

Eric

Eric W. Biederman (7):
      proc: Rename in proc_inode rename sysctl_inodes sibling_inodes
      proc: Generalize proc_sys_prune_dcache into proc_prune_siblings_dcache
      proc: Mov rcu_read_(lock|unlock) in proc_prune_siblings_dcache
      proc: Use d_invalidate in proc_prune_siblings_dcache
      proc: Clear the pieces of proc_inode that proc_evict_inode cares about
      proc: Use a list of inodes to flush from proc
      proc: Ensure we see the exit of each process tid exactly once

 fs/exec.c               |   5 +--
 fs/proc/base.c          | 111 ++++++++++++++++--------------------------------
 fs/proc/inode.c         |  60 +++++++++++++++++++++++---
 fs/proc/internal.h      |   4 +-
 fs/proc/proc_sysctl.c   |  45 +++-----------------
 include/linux/pid.h     |   2 +
 include/linux/proc_fs.h |   4 +-
 kernel/exit.c           |   4 +-
 kernel/pid.c            |  16 +++++++
 9 files changed, 124 insertions(+), 127 deletions(-)

On Thu, Feb 20, 2020 at 12:48 PM Eric W. Biederman
[off-list ref] wrote:

Linus, does this approach look like something you can stand?

A couple of worries, although one of them seem to have already been
resolved by Al.

I think the real gatekeeper should be Al in general.  But other than
the small comments I had, I think this might work just fine.

Al?

           Linus

On Thu, Feb 20, 2020 at 03:02:22PM -0800, Linus Torvalds wrote:

On Thu, Feb 20, 2020 at 12:48 PM Eric W. Biederman
[off-list ref] wrote:

quoted

Linus, does this approach look like something you can stand?

A couple of worries, although one of them seem to have already been
resolved by Al.

I think the real gatekeeper should be Al in general.  But other than
the small comments I had, I think this might work just fine.

Al?

I'll need to finish RTFS there; I have initially misread that patch,
actually - Eric _is_ using that thing both for those directories
and for sysctl inodes.  And the prototype for that machinery (the
one he'd pulled from proc_sysctl.c) is playing with pinning superblocks
way too much; for per-pid directories that's not an issue, but
for sysctl table removal you are very likely to hit a bunch of
evictees on the same superblock...