Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp6416579ybv; Wed, 12 Feb 2020 11:47:55 -0800 (PST) X-Google-Smtp-Source: APXvYqxdmXH7d9Vx+AQNoNgLdpD5QBuP2H0gb5Nnb6zps7moeLZDYonY20iD1sUpjlqdkAp57n/D X-Received: by 2002:aca:1c0d:: with SMTP id c13mr486299oic.44.1581536875843; Wed, 12 Feb 2020 11:47:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581536875; cv=none; d=google.com; s=arc-20160816; b=gwRblPY3R/eQeij+9xpCgSdZD2L6QWBgUjVgaZEktIFNpxbSEYrd3xkPSiGhiLwzCP 2OdgPbd53ZSXA8lV3wrIFsXvczI4uYIlv6eqmJdeoKEfwDle3kS6Kpmo34cXfAYkKRSn 2az5jUnT5DYSHrsOsf4Y6fsyAQqTfbo3tMTV39sdQSGa48L8drwdeWlJfz/Tl4kdiEJm dMSZzlNi/nZOy2fn6NQ06pXNRIvGApn++fm0x8PyC6zUZezzjcZUN7WvIqjSKobnNT3I BldechW1HweINYJ1vWAhoIDePonJaTup9SfApfE9UQ/LCoVQu7T3xloYMc5Xs2afBw4n CLkA== 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=j/md6ANwo8jAghzwBPWbpr1mbjGvwChWn3k5RsiFe64=; b=yGhzFwBI/xqxFpXXCHNymVa9cpBZwxdH1kDyef05PB/cD0HcNVw7py7JaMgXBDf8Cx wGNeqEhdYx8w9S6BipE/sIVeO8bUL906AbppNuxbjlzySNaVEO7gewCU0pOXrn8hvJen /w8v/9t0Jdc0uydv5vyTnZLaMa3gZPHPMBNQf4tfW1NHNzvgWLr3OELe6Ybm2Nmn3diE Zi4PI6bzZ40uZN6o/xTI70mBqUHfZWdzcWgMJMMRZQRkmfcxqBMkfwk5/tCl13rzrsjY 90P1yrYouolHYbrvj0jdokorEUQP4CCe4I1OLa7ghMVshSyDJ4hoVaLECTworINZilqx WbWg== 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 t127si54489oih.45.2020.02.12.11.47.41; Wed, 12 Feb 2020 11:47:55 -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 S1728959AbgBLTri (ORCPT + 99 others); Wed, 12 Feb 2020 14:47:38 -0500 Received: from zeniv.linux.org.uk ([195.92.253.2]:42782 "EHLO ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727439AbgBLTri (ORCPT ); Wed, 12 Feb 2020 14:47:38 -0500 Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1j1xyq-00BZ9b-9X; Wed, 12 Feb 2020 19:47:28 +0000 Date: Wed, 12 Feb 2020 19:47:28 +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: <20200212194728.GM23230@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> 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 Wed, Feb 12, 2020 at 10:45:06AM -0800, Linus Torvalds wrote: > On Wed, Feb 12, 2020 at 7:01 AM Eric W. Biederman wrote: > > > > Fundamentally proc_flush_task is an optimization. Just getting rid of > > dentries earlier. At least at one point it was an important > > optimization because the old process dentries would just sit around > > doing nothing for anyone. > > I'm pretty sure it's still important. It's very easy to generate a > _ton_ of dentries with /proc. > > > I wonder if instead of invalidating specific dentries we could instead > > fire wake up a shrinker and point it at one or more instances of proc. > > It shouldn't be the dentries themselves that are a freeing problem. > They're being RCU-free'd anyway because of lookup. It's the > proc_mounts list that is the problem, isn't it? > > So it's just fs_info that needs to be rcu-delayed because it contains > that list. Or is there something else? Large part of the headache is the possibility that some joker has done something like mounting tmpfs on /proc//map_files, or binding /dev/null on top of /proc//syscall, etc. IOW, that d_invalidate() can very well have to grab namespace_sem. And possibly do a full-blown fs shutdown of something NFS-mounted, etc...