Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1189339ybv; Thu, 20 Feb 2020 15:08:24 -0800 (PST) X-Google-Smtp-Source: APXvYqxyl9RI6JeFuQNthwqOoGEsZaP+yiXOC7+3/BL06+VQQzDXDYGlSB2L9Cc0X6QpgGFB+Zgs X-Received: by 2002:aca:c7ca:: with SMTP id x193mr3881857oif.70.1582240104675; Thu, 20 Feb 2020 15:08:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1582240104; cv=none; d=google.com; s=arc-20160816; b=VEDF0Lksr4XqNjb/TPYkugnKXdnfpfDX7c3Edqme7Kbvq00m2ejflVLvzr9PZvF2aZ THFby1f04etrlXsQxyI9JrIs9hbw1V9rQ9Yaara0WhTEMMJubSlIPkw1wz5CSbr46gwu jUKqevqgb7fl97D1+GNTuVaV47UwrsjHn0BWhlh/yDyYybLIBpJ7hCgUcWtQcDDlbkDR b1fLu2gNRBv6kHnYarRxHU+jkA5+7eZpEhm8J+q1aDdhphui2ezb0RqMY3rK8I0bQWHH B/exVrlDdt7MAwZeyHViiJdwPpH/sV3shIFK9uD3Bs36nHOzylzJW4xzKeZGvIqv7a+K cA1w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=2MyC5egWmo7UpfRFyCVY0Ozi/ed+m32/Ndk0FpyCNlE=; b=dy70j3KsTF8SgqPXHAQsO0/rgJcsZddrhA0VrWXexc02M0xkwte7vAKTqwFS7wJR/e XOayAfiDhfNrEnXoPJ92sO1VwarGU22OusN57Rnb+JeLxeqiyqfFYUV/KtHa7BRbrGlf wWT/LvpLuDzLaUZguED0Ajlcr2eiBFO2Zh1O2MLR9pRRB1Nef0VVq6FdjC0WcqkfoegQ WvLpov5AZ4VpeKBHTVpS9+hpfu64hMkOlnSrN6r50k1riMyZHb3d04gu4uwn10LO+Nme QEhKDtyO22Fyu4jwtQGD51Wxg9wp9tf4gqLwJ2ifhnTkGlzH3yrad9vboZBga6IvWKI9 0iyQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f3si374224oia.264.2020.02.20.15.08.11; Thu, 20 Feb 2020 15:08:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729344AbgBTXIE (ORCPT + 99 others); Thu, 20 Feb 2020 18:08:04 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:41396 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729027AbgBTXID (ORCPT ); Thu, 20 Feb 2020 18:08:03 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1j4uvG-00G29s-Jo; Thu, 20 Feb 2020 23:07:58 +0000 Date: Thu, 20 Feb 2020 23:07:58 +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 0/7] proc: Dentry flushing without proc_mnt Message-ID: <20200220230758.GT23230@ZenIV.linux.org.uk> References: <20200212200335.GO23230@ZenIV.linux.org.uk> <20200212203833.GQ23230@ZenIV.linux.org.uk> <20200212204124.GR23230@ZenIV.linux.org.uk> <87lfp7h422.fsf@x220.int.ebiederm.org> <87pnejf6fz.fsf@x220.int.ebiederm.org> <871rqpaswu.fsf_-_@x220.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > 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...