|
Message-ID: <87mu9c7ruf.fsf@x220.int.ebiederm.org> Date: Thu, 20 Feb 2020 17:37:44 -0600 From: ebiederm@...ssion.com (Eric W. Biederman) To: Al Viro <viro@...iv.linux.org.uk> Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 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 0/7] proc: Dentry flushing without proc_mnt Al Viro <viro@...iv.linux.org.uk> writes: > 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 >> <ebiederm@...ssion.com> 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? > > 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... I saw that was possible. If the broad strokes look correct I don't have a problem at all with optimizing for the case where many of the entries are for inodes on the same superblock. I just had enough other details on my mind I was afraid if I got a little more clever I would have introduced a typo somewhere. I wish I could limit the sysctl parts to just directories, but unfortunately the sysctl tables don't always give a guarantee that a directory is what will be removed. But sysctls do have one name per inode invarant like fat. There is no way to express a sysctl table that doesn't have that invariant. As for d_find_alias/d_invalidate. Just for completeness I wanted to write a loop: while (dentry = d_find_alias(inode)) { d_invalidate(dentry); dput(dentry); } Unfortunately that breaks on directories, because for directories d_find_alias turns into d_find_any_alias, and continues to return aliases even when they are unhashed. It might be nice to write a cousin of d_prune_aliases call it d_invalidate_aliases that just does that loop the correct way in dcache.c 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.