[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 14 Feb 2020 08:15:16 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Al Viro <viro@...iv.linux.org.uk>, LKML <linux-kernel@...r.kernel.org>, Kernel Hardening <kernel-hardening@...ts.openwall.com>, Linux API <linux-api@...r.kernel.org>, Linux FS Devel <linux-fsdevel@...r.kernel.org>, Linux Security Module <linux-security-module@...r.kernel.org>, Akinobu Mita <akinobu.mita@...il.com>, Alexey Dobriyan <adobriyan@...il.com>, Andrew Morton <akpm@...ux-foundation.org>, Andy Lutomirski <luto@...nel.org>, Daniel Micay <danielmicay@...il.com>, Djalal Harouni <tixxdz@...il.com>, "Dmitry V . Levin" <ldv@...linux.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Ingo Molnar <mingo@...nel.org>, "J . Bruce Fields" <bfields@...ldses.org>, Jeff Layton <jlayton@...chiereds.net>, Jonathan Corbet <corbet@....net>, Kees Cook <keescook@...omium.org>, Oleg Nesterov <oleg@...hat.com>, Solar Designer <solar@...nwall.com>
Subject: Re: [PATCH v8 07/11] proc: flush task dcache entries from all procfs instances
Linus Torvalds <torvalds@...ux-foundation.org> writes:
> I guess a lot of readdir users end up doing a stat on it immediately
> afterwards. I think right now we do it to get the inode number, and
> maybe that is a basic requirement (even if I don't think it's really
> stable - an inode could be evicted and then the ino changes, no?)
All I know is proc_fill_cache seemed like a good idea at the time.
I may have been to clever.
While I think proc_fill_cache probably exacerbates the issue
it isn't the reason we have the flushing logic. The proc
flushing logic was introduced in around 2.5.9 much earlier
than the other proc things.
commit 0030633355db2bba32d97655df73b04215018ab9
Author: Alexander Viro <viro@...h.psu.edu>
Date: Sun Apr 21 23:03:37 2002 -0700
[PATCH] (3/5) sane procfs/dcache interaction
- sane dentry retention. Namely, we don't kill /proc/<pid> dentries at the
first opportunity (as the current tree does). Instead we do the following:
* ->d_delete() kills it only if process is already dead.
* all ->lookup() in proc/base.c end with checking if process is still
alive and unhash if it isn't.
* proc_pid_lookup() (lookup for /proc/<pid>) caches reference to dentry
in task_struct. It's _not_ counted in ->d_count.
* ->d_iput() resets said reference to NULL.
* release_task() (burying a zombie) checks if there is a cached
reference and if there is - shrinks the subtree.
* tasklist_lock is used for exclusion.
That way we are guaranteed that after release_task() all dentries in
/proc/<pid> will go away as soon as possible; OTOH, before release_task()
we have normal retention policy - they go away under memory pressure with
the same rules as for dentries on any other fs.
Tracking down when this logic was introduced I also see that this code
has broken again and again any time proc changes (like now). So it is
definitely subtle and fragile.
Eric
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.
