Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp4039987ybl; Mon, 27 Jan 2020 15:25:37 -0800 (PST) X-Google-Smtp-Source: APXvYqxmBTbO4wVYNYxtfHYegM2LnGKet8F8rhiMnjInsJGSTa1QLGdbAcXcv3svBRKQ18L+Pf3F X-Received: by 2002:aca:2210:: with SMTP id b16mr1077249oic.32.1580167536947; Mon, 27 Jan 2020 15:25:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1580167536; cv=none; d=google.com; s=arc-20160816; b=tQ4W6C7s/G8BF47u1Ahr4D9BLSJevZE7iaIKkvEgbmnBhcMUjYCPVI2B8rAUJo3eiE vzLbAXYMePWIeqBgyh351T/pPaEYa/45GhNs8baVZm/jpYW+sPSlVXkCMK5hpAWTa3KC Me8jSknlHCPOCOQ5dMdmSz2seW2Y6z3hTVedtFjgGAN051oLnyYFIQfpu32gmWyWDuGe d9XGZM1G/3x+Ka1/3ZTjZgzP2tjMfiTuZi4ak/6cY4y4cVvcUcsERfJXdB115EwOBl15 vEAGuCmUJEJSN4dw3MTLYTyYZPmpWPFgMA419KkeBSsLR1t15f5W43QXjtTi8j4kVZgt fhvA== 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-transfer-encoding :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date; bh=HmEk1oRCJHdAAV2dbqHIzfY3fWSyRyt/qUKpCQED60E=; b=Ja1o2pihEsLR742uGvKm43oV2lprg6uJp2L/h1aVZOiFZxL5TkCorPykEXhB98Y1JW 7QrFTovjdRxg3nGhw+uffrZcCVrY8mU5wc0/a+WqwClk3upXNKdFU6vM4cc1DiqN7e/I vAHL97ylToZnrvTjtdczz2SPDH8KV6wqXQrhs1Oc64+HMvq3S6gJXLilXafQk9RmNaXZ 3J6Ct2m3ejEFB4b3DPGo+JHuDh5YqEghc4WJyKCTWztAMMZCYqy41yedlyl+XAdyqvHq +4+V+rcgqxuNzoI++dvJK+7FzjDJNrnL/L6i2WgHu+PLYupiF2JiJ/Y0G7y8WluF3BQo 0rvQ== 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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p25si7781558oto.191.2020.01.27.15.25.18; Mon, 27 Jan 2020 15:25:36 -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; dmarc=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726240AbgA0XYC (ORCPT + 99 others); Mon, 27 Jan 2020 18:24:02 -0500 Received: from monster.unsafe.ru ([5.9.28.80]:59724 "EHLO mail.unsafe.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725955AbgA0XYC (ORCPT ); Mon, 27 Jan 2020 18:24:02 -0500 Received: from comp-core-i7-2640m-0182e6 (ip-89-102-33-211.net.upcbroadband.cz [89.102.33.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.unsafe.ru (Postfix) with ESMTPSA id B5A60C61B0E; Mon, 27 Jan 2020 23:23:54 +0000 (UTC) Date: Tue, 28 Jan 2020 00:23:53 +0100 From: Alexey Gladkov To: Linus Torvalds Cc: LKML , Kernel Hardening , Linux API , Linux FS Devel , Linux Security Module , Akinobu Mita , Alexander Viro , Alexey Dobriyan , Andrew Morton , Andy Lutomirski , Daniel Micay , Djalal Harouni , "Dmitry V . Levin" , "Eric W . Biederman" , Greg Kroah-Hartman , Ingo Molnar , "J . Bruce Fields" , Jeff Layton , Jonathan Corbet , Kees Cook , Oleg Nesterov , Solar Designer , Stephen Rothwell Subject: Re: [PATCH v7 07/11] proc: flush task dcache entries from all procfs instances Message-ID: <20200127232352.s3mvvfkrta3i5h7w@comp-core-i7-2640m-0182e6> Mail-Followup-To: Linus Torvalds , LKML , Kernel Hardening , Linux API , Linux FS Devel , Linux Security Module , Akinobu Mita , Alexander Viro , Alexey Dobriyan , Andrew Morton , Andy Lutomirski , Daniel Micay , Djalal Harouni , "Dmitry V . Levin" , "Eric W . Biederman" , Greg Kroah-Hartman , Ingo Molnar , "J . Bruce Fields" , Jeff Layton , Jonathan Corbet , Kees Cook , Oleg Nesterov , Solar Designer , Stephen Rothwell References: <20200125130541.450409-1-gladkov.alexey@gmail.com> <20200125130541.450409-8-gladkov.alexey@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Jan 25, 2020 at 10:45:25AM -0800, Linus Torvalds wrote: > On Sat, Jan 25, 2020 at 5:06 AM Alexey Gladkov wrote: > > > > This allows to flush dcache entries of a task on multiple procfs mounts > > per pid namespace. > > From a quick read-through, this is the only one I really react negatively to. > > The locking looks odd. It only seems to protect the new proc_mounts > list, but then it's a whole big rwsem, and it's taken over all of > proc_flush_task_mnt(), and the locking is exported to all over as a > result of that - including the dummy functions for "there is no proc" > case. > > And proc_flush_task_mnt() itself should need no locking over any of > it, so it's all just for the silly looping over the list. Thank you, I will rework this part. > So > > (a) this looks fishy and feels wrong - I get a very strong feeling > that the locking is wrong to begin with, and could/should have been > done differently > > (b) all the locking should have been internal to /proc, and those > wrappers shouldn't exist in a common header file (and certainly not > for the non-proc case). > > Yes, (a) is just a feeling, and I don't have any great suggestions. > Maybe make it an RCU list and use a spinlock for updating it? I’m thinking, is it possible to get rid of proc_flush_task at all ? Maybe we can try to flush dcache during readdir for example. > But (b) is pretty much a non-starter in this form. Those wrappers > shouldn't be in a globally exported core header file. No way. > > Linus > -- Rgrds, legion