Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp1878888ybl; Sat, 25 Jan 2020 10:48:06 -0800 (PST) X-Google-Smtp-Source: APXvYqxQ57DA4DvnufKaXQ7qNTBUuzqEZwAinJRhficJlDYnGZ1ykp5SK0SGLOO7ZsVb/jSNe0cn X-Received: by 2002:aca:fd16:: with SMTP id b22mr3094864oii.73.1579978086221; Sat, 25 Jan 2020 10:48:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1579978086; cv=none; d=google.com; s=arc-20160816; b=PE06maBZUrftdkQqPZTbfsF6YWIsiHRPfuAZJHxnPLbsH1bePb4M8WEo2aPnd2MVPV PFKXsrHIhljGMD1/I00HFkrwC/qjLcaboAnWLs2CLeP5hnXn/lSlYnc3p7U9rivmdCJu 4TuoCMs/yrt4jv3PMBUBenhEFsE6dwIh6S7Z62qWAISO1yAJEBniieit/sak6o7wg2JL 451vo/bk1GQkLIXUz8u8TGepm7X1mZ5G6pKvjTAme6dkdfmZOO1K0xij1kSIcAPQJZsl iBND4QEVUp7TvSsvs3ZnCZhSYJ3KEjuZoHEOxgiNk7JUrz2CYUQZUVB9TZZVwCcDb7vs PDQQ== 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=agKBgndk3wOWKqvCTJf0yLyX2bJKGsFMAU50Ri7/n9U=; b=qAZZDaHTpqBihSOPYDUrbdwPACTJCUx2T1e2pXACDWvYJrbtT4zIws0497waIdyxXn uCmUeUBM5ZUonkCJN5i8mhaOYnnLUZsNyRKwRWIVlbrKGVnjxvVwd74Q6WNWXAPBtb+H cZL4KMh7us2uBBCuIUMcUzub8JMUq1hsueuz9RdrbC7DtiU2mVAxNXYncgWXeiG4LV58 aOs/bn1CGndmMg5pa38yJH+qZwuQzxfXFgMHp+8r3o5/8uy36ZJJ8sc5X07bUz+dSKJ8 SC5ia0Xi2JiEjSWvczVhvqr49q0F6AOIKR/BYXkK8xuKX3t3uXfudaVkwhjmx/IuDMlU 499Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=ebrkpC8l; 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 d28si929520otc.123.2020.01.25.10.47.52; Sat, 25 Jan 2020 10:48:06 -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=ebrkpC8l; 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 S1726657AbgAYSpq (ORCPT + 99 others); Sat, 25 Jan 2020 13:45:46 -0500 Received: from mail-lj1-f195.google.com ([209.85.208.195]:40683 "EHLO mail-lj1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726327AbgAYSpp (ORCPT ); Sat, 25 Jan 2020 13:45:45 -0500 Received: by mail-lj1-f195.google.com with SMTP id n18so6279686ljo.7 for ; Sat, 25 Jan 2020 10:45:44 -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=agKBgndk3wOWKqvCTJf0yLyX2bJKGsFMAU50Ri7/n9U=; b=ebrkpC8lWGHzj/TTwQVlGmpfBj+LMhP3xc48s3IkdXLpfPBkmBQH8glAibN3NZzhJ7 eaX+oPyIl6RK4Fcu/p33lei0jipvUcU+PHgqX1Ir4aJDuHlpLIX4SbceygCECD/xiFMl QwEsuOsJJnKRw8LKLW82q3yqXp++TF+4Q343k= 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=agKBgndk3wOWKqvCTJf0yLyX2bJKGsFMAU50Ri7/n9U=; b=gjVVxc156CJZmaqKbkyVD/I5yNy+phhXY5hMxZaI5C0RQ130Up83oZmPufzKL1BSJn h5k5A8H4rK3X2YfmGDjkLOi63OiMu1GpdqzQapyTlaWLhSwxIgGASXcDkG4hbATgYhZW /MBMwYM6BTGj2dDhFwTCNMi7k0PxTIqECwC2hWCaXQ8XojfBdlFb9psy2AtGyzDIo9gj 9cafVswsQIzNKsg9iH2mF+fnIXK5d6ivDhUY9z5EaemM0e7Ah4ZbxCdgZSk+vMAQ3rue Pwj2Sw5xjw2r2mUm+WTshudYfOOXhjt+H0yno6/mkq4Zpw3YEyeKBBWhxK/uJVBKJRDJ g5jQ== X-Gm-Message-State: APjAAAW8YLIslZN9VAo+NdYrM4ILPwXFktjA3TUwdy+z+H/pIz3IUSh0 f7EPS+eiKDX+zRpL9Kepf+sEWxNd4RI= X-Received: by 2002:a2e:7311:: with SMTP id o17mr5729144ljc.197.1579977942957; Sat, 25 Jan 2020 10:45:42 -0800 (PST) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id s9sm6312144ljh.90.2020.01.25.10.45.41 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Jan 2020 10:45:42 -0800 (PST) Received: by mail-lj1-f175.google.com with SMTP id h23so6266918ljc.8 for ; Sat, 25 Jan 2020 10:45:41 -0800 (PST) X-Received: by 2002:a05:651c:ce:: with SMTP id 14mr2080983ljr.241.1579977941361; Sat, 25 Jan 2020 10:45:41 -0800 (PST) MIME-Version: 1.0 References: <20200125130541.450409-1-gladkov.alexey@gmail.com> <20200125130541.450409-8-gladkov.alexey@gmail.com> In-Reply-To: <20200125130541.450409-8-gladkov.alexey@gmail.com> From: Linus Torvalds Date: Sat, 25 Jan 2020 10:45:25 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v7 07/11] proc: flush task dcache entries from all procfs instances To: Alexey Gladkov 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 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 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. 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? 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