Received: by 2002:a25:1506:0:0:0:0:0 with SMTP id 6csp1003960ybv; Thu, 13 Feb 2020 13:48:43 -0800 (PST) X-Google-Smtp-Source: APXvYqyC1/x5dnrS4m/+EjTWRkat60y0j8cTi3nwvnDuJSDkUX725+twkVbf+OutebEVZMCLcvJl X-Received: by 2002:a9d:51cc:: with SMTP id d12mr9020102oth.356.1581630523104; Thu, 13 Feb 2020 13:48:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1581630523; cv=none; d=google.com; s=arc-20160816; b=NY/iGcCLHRwo686zMvFPFz16MDRz+NmkIshMsFtBQiRSz3bDhfO/sAPedGPxyPM3ky 05LLmSc/6T0iAtqhvpa1yL22QJuHAMZivUs1ZSPdPAqrwLoi7rZeKZ6RZTigU7Ucgcqk Jy8S4asqNT6MdzCZL9xRsXpsUkj2FUCe+9Zn9Ld9QI5zCi5mlmd1T0Y11IGgqQJx68eJ 2WQlQDWhdvXnNX1yzefiuKMk3Axv0XpEGkanZnUtLGoVRw22ityOfa7FWdIlGCoFD0eH lVHJTxiFP3mPfNC6o85kVbGCR3uWyiKbNCXmsKkhlBJS7bvu2BYjEyLMyFcmS2wt5hSg qSug== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=yfXM82VfoqeRc90gxFVeIWXJ41itdUqMd3xA0dVgW2Y=; b=f0EEZ6lCVI25YBgv/CkARzvGcm7p3v7NO8URFcaEOh7xzjRJj8BkpC1PwV77Jneg70 YzrTHl4p1NmZFDgS1Xfk96FRmCUx90jjD2sWzGOdB0CQGSzLNIyIbFwS73I4UQg6UDPs mDb0fhJ1/uaxzEQKq5MyqFdNfpPnHgfHCb9fIRcedIxUNRiaGZXuHftyDSOoWcnZcCXZ oaCzmfAq7juapHERSKzCKBjlw4K/S/f1ZFxc5WNnees9nGupg1+M4ZEqZRJ/Gug1qd0c SC9SShMpz7plrHAVqNTbJfjh6lvUHZ3J3VYipmhG5pu5oMo+llLl1zngmOFZFOGERL5W tMBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=BawgSQbY; 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 o15si1736962otp.314.2020.02.13.13.48.31; Thu, 13 Feb 2020 13:48:43 -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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=BawgSQbY; 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 S1728113AbgBMVgz (ORCPT + 99 others); Thu, 13 Feb 2020 16:36:55 -0500 Received: from mail-ed1-f68.google.com ([209.85.208.68]:37019 "EHLO mail-ed1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727519AbgBMVgy (ORCPT ); Thu, 13 Feb 2020 16:36:54 -0500 Received: by mail-ed1-f68.google.com with SMTP id df17so1910233edb.4 for ; Thu, 13 Feb 2020 13:36:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yfXM82VfoqeRc90gxFVeIWXJ41itdUqMd3xA0dVgW2Y=; b=BawgSQbYq1TbwSpri2I8yt8BLdW+yFwAYoE8dMiMSbSBq331xObis6ZCTB17z/2+pu BJ/TFbcNqMRECulsFRMIiMTcM/ovFgWzkJQC0Q8GiR94lJcnmNpi+fvP6UvLQSDrJh9R cMZLEUQ8JhCaHYaouGQIdPmwtosqiphyKcUZs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yfXM82VfoqeRc90gxFVeIWXJ41itdUqMd3xA0dVgW2Y=; b=CEIhBZ61smOKyUM3Iwu2e5n/YH484luwfxautF/CP1ZXNfXNbPSlVuoy+sFe7tqoMp WIbMibPQ7Z6Ki25r8gwMk37UDP0Mv/EyJ66YcAppelPC18trHGA5ci00NMgB+nbgV7Ce fKhLWh6yQ5OAUO/G5s17pCSBUYIBYbFIOvoRj25dY88M6zobqnu+TMQugXRNsmTfgkiz DBDtPlNgxrutYpyX7oLu3Bg0erl7rL62/LHx4/SOd9PVfvJkuOrYDohJ4DN8mICC+Z9Z vjAATPyrVhmrDaPnRMvE6lwqbjhwkY6qyqn+RwfvElrv2RhbVLCndQSAqPnVcEhO+bfC l9Cw== X-Gm-Message-State: APjAAAUiHrGRGJThsBaWMpEOxgxo6fE5uG4DcmC9NLthSqlBfgxsnFxD 2sOqagT0YGLwjimRcx0vOfAvw9Z4vcI= X-Received: by 2002:a17:906:af8b:: with SMTP id mj11mr18311684ejb.168.1581629812770; Thu, 13 Feb 2020 13:36:52 -0800 (PST) Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com. [209.85.208.46]) by smtp.gmail.com with ESMTPSA id n10sm349718ejc.58.2020.02.13.13.36.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 Feb 2020 13:36:52 -0800 (PST) Received: by mail-ed1-f46.google.com with SMTP id e10so8639467edv.9 for ; Thu, 13 Feb 2020 13:36:52 -0800 (PST) X-Received: by 2002:a2e:580c:: with SMTP id m12mr12460727ljb.150.1581629427873; Thu, 13 Feb 2020 13:30:27 -0800 (PST) MIME-Version: 1.0 References: <87v9obipk9.fsf@x220.int.ebiederm.org> <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> <20200213055527.GS23230@ZenIV.linux.org.uk> In-Reply-To: <20200213055527.GS23230@ZenIV.linux.org.uk> From: Linus Torvalds Date: Thu, 13 Feb 2020 13:30:11 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v8 07/11] proc: flush task dcache entries from all procfs instances To: Al Viro 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 Content-Type: text/plain; charset="UTF-8" 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 9:55 PM Al Viro wrote: > > What I don't understand is the insistence on getting those dentries > via dcache lookups. I don't think that's an "insistence", it's more of a "historical behavior" together with "several changes over the years to deal with dentry-level cleanups and updates". > _IF_ we are willing to live with cacheline > contention (on ->d_lock of root dentry, if nothing else), why not > do the following: > * put all dentries of such directories ([0-9]* and [0-9]*/task/*) > into a list anchored in task_struct; have non-counting reference to > task_struct stored in them (might simplify part of get_proc_task() users, Hmm. Right now I don't think we actually create any dentries at all for the short-lived process case. Wouldn't your suggestion make fork/exit rather worse? Or would you create the dentries dynamically still at lookup time, and then attach them to the process at that point? What list would you use for the dentry chaining? Would you play games with the dentry hashing, and "hash" them off the process, and never hit in the lookup cache? Am I misunderstanding what you suggest? Linus