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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 07A29C352A3 for ; Thu, 13 Feb 2020 21:36:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C89AF206B6 for ; Thu, 13 Feb 2020 21:36:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1581629815; bh=ItnnmxoRJ5gT+30BziuxUd+qlmmx1CXkUL9ZfYPGf/k=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=OFkmHtDk2YNHBvWLJ8P9h7H9qPuuCpqBIbITdvw1dAP8/AbddyUDG+FX6UJ+vA1LX oNyhczYUKN6BQssex6D58Ycc1fpteMmehuzAxGdrjSrMa0+gY/yD62CU2TdG43yzu6 W5QyLXHqvwTTs/9xTF3g69KGT6c7O3o8lxvVbPOA= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728168AbgBMVgz (ORCPT ); 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-Google-Smtp-Source: APXvYqyV9ZL+0P2LlkQ//Oy6KPbhMWgZ6lS3uZE6gUpHQ2mkyrSt7UT+e5xDm+sTDaTkJa/fvVrvSA== 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 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=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 7E0BCC352A3 for ; Thu, 13 Feb 2020 21:37:28 +0000 (UTC) Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by mail.kernel.org (Postfix) with SMTP id 777192168B for ; Thu, 13 Feb 2020 21:37:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="BawgSQbY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 777192168B Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kernel-hardening-return-17815-kernel-hardening=archiver.kernel.org@lists.openwall.com Received: (qmail 5972 invoked by uid 550); 13 Feb 2020 21:30:44 -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 5952 invoked from network); 13 Feb 2020 21:30:44 -0000 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=Pqe4nIS0Fy/hCTPc9N2MHmkQVYG89x4xb9znDez9xtCk++W1WkfzRGf0TJEWczoi92 VXnWRZc22jd1AWg8JiY5gIh/nBulsCxrKL1mAF8/hbbW8YXC7vFGSwPGXf1r1iYhBTN+ fHRm0yvyJRYaZUNxq8u7VXR5Q54SVjb+3XRNmC77b9cIPtE8/QrBIv2pQZ/1MMQJEFJ9 VvZpITCdrMIeLh32X9Yxnswz1QvYA1mNpf4ONnymQ/Mle1BGWH3gQyl22CPo4Lbz1pIR dz21xBGCehhw1MmKLtxqfWNIfEXCr/JSO9KLqLEX9WfMwPQp+CsJIJTnB/z12Cv6rdDB XELA== X-Gm-Message-State: APjAAAXHt/6MFmX8Y4E874z6VFNs1X4nRfO2q5oEszwOWLgXAt+kUgbT 5fsFr/k57TWZTpIhFy/Ya7CSd0TfwvM= X-Google-Smtp-Source: APXvYqxg38nEtkN2LFB+a8NeTnW5hH3GP8YuHkbAhdBqoO2YbE5eP7jN//GpNV3iKOVhRmDVgorbAA== X-Received: by 2002:a2e:809a:: with SMTP id i26mr12658486ljg.108.1581629431247; Thu, 13 Feb 2020 13:30:31 -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" 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