From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79829C352A4 for ; Wed, 12 Feb 2020 20:04:00 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id D777621739 for ; Wed, 12 Feb 2020 20:03:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D777621739 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=zeniv.linux.org.uk Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17802-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 10191 invoked by uid 550); 12 Feb 2020 20:03:53 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 10149 invoked from network); 12 Feb 2020 20:03:53 -0000 Date: Wed, 12 Feb 2020 20:03:35 +0000 From: Al Viro To: Linus Torvalds Cc: "Eric W. Biederman" , LKML , Kernel Hardening , Linux API , Linux FS Devel , Linux Security Module , Akinobu Mita , 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 Message-ID: <20200212200335.GO23230@ZenIV.linux.org.uk> References: <20200210150519.538333-1-gladkov.alexey@gmail.com> <20200210150519.538333-8-gladkov.alexey@gmail.com> <87v9odlxbr.fsf@x220.int.ebiederm.org> <20200212144921.sykucj4mekcziicz@comp-core-i7-2640m-0182e6> <87tv3vkg1a.fsf@x220.int.ebiederm.org> <87v9obipk9.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro On Wed, Feb 12, 2020 at 11:49:58AM -0800, Linus Torvalds wrote: > 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 > afterwards? What's to prevent racing with fs shutdown while you are doing the second part? We could, after all, just have them[*] on procfs-private list (anchored in task_struct) from the very beginning; evict on ->d_prune(), walk the list on exit... How do you make sure the fs instance won't go away right under you while you are doing the real work? Suppose you are looking at one of those dentries and you've found something blocking to do. You can't pin that dentry; you can pin ->s_active on its superblock (if it's already zero, you can skip it - fs shutdown already in progress will take care of the damn thing), but that will lead to quite a bit of cacheline pingpong... [*] only /proc/ and /proc/*/task/ dentries, obviously. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Viro Subject: Re: [PATCH v8 07/11] proc: flush task dcache entries from all procfs instances Date: Wed, 12 Feb 2020 20:03:35 +0000 Message-ID: <20200212200335.GO23230@ZenIV.linux.org.uk> References: <20200210150519.538333-1-gladkov.alexey@gmail.com> <20200210150519.538333-8-gladkov.alexey@gmail.com> <87v9odlxbr.fsf@x220.int.ebiederm.org> <20200212144921.sykucj4mekcziicz@comp-core-i7-2640m-0182e6> <87tv3vkg1a.fsf@x220.int.ebiederm.org> <87v9obipk9.fsf@x220.int.ebiederm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: owner-linux-security-module@vger.kernel.org To: Linus Torvalds Cc: "Eric W. Biederman" , LKML , Kernel Hardening , Linux API , Linux FS Devel , Linux Security Module , Akinobu Mita , 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 List-Id: linux-api@vger.kernel.org On Wed, Feb 12, 2020 at 11:49:58AM -0800, Linus Torvalds wrote: > 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 > afterwards? What's to prevent racing with fs shutdown while you are doing the second part? We could, after all, just have them[*] on procfs-private list (anchored in task_struct) from the very beginning; evict on ->d_prune(), walk the list on exit... How do you make sure the fs instance won't go away right under you while you are doing the real work? Suppose you are looking at one of those dentries and you've found something blocking to do. You can't pin that dentry; you can pin ->s_active on its superblock (if it's already zero, you can skip it - fs shutdown already in progress will take care of the damn thing), but that will lead to quite a bit of cacheline pingpong... [*] only /proc/ and /proc/*/task/ dentries, obviously.