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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 F0C94C43461 for ; Thu, 17 Sep 2020 00:54:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 9EFEE206CA for ; Thu, 17 Sep 2020 00:54:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726098AbgIQAyp (ORCPT ); Wed, 16 Sep 2020 20:54:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45584 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726043AbgIQAyo (ORCPT ); Wed, 16 Sep 2020 20:54:44 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BA9EC061756; Wed, 16 Sep 2020 17:54:43 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1kIiC9-0005iJ-Ia; Thu, 17 Sep 2020 00:54:41 +0000 Date: Thu, 17 Sep 2020 01:54:41 +0100 From: Al Viro To: Eric Biggers Cc: linux-fsdevel@vger.kernel.org, Daeho Jeong , linux-kernel@vger.kernel.org Subject: Re: [PATCH v2] vfs: don't unnecessarily clone write access for writable fds Message-ID: <20200917005441.GP3421308@ZenIV.linux.org.uk> References: <20200611160534.55042-1-ebiggers@kernel.org> <20200629165014.GA20492@sol.localdomain> <20200916035914.GA825@sol.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200916035914.GA825@sol.localdomain> Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org On Tue, Sep 15, 2020 at 08:59:14PM -0700, Eric Biggers wrote: > On Mon, Jun 29, 2020 at 09:50:14AM -0700, Eric Biggers wrote: > > On Thu, Jun 11, 2020 at 09:05:34AM -0700, Eric Biggers wrote: > > > From: Eric Biggers > > > > > > There's no need for mnt_want_write_file() to increment mnt_writers when > > > the file is already open for writing, provided that > > > mnt_drop_write_file() is changed to conditionally decrement it. > > > > > > We seem to have ended up in the current situation because > > > mnt_want_write_file() used to be paired with mnt_drop_write(), due to > > > mnt_drop_write_file() not having been added yet. So originally > > > mnt_want_write_file() had to always increment mnt_writers. > > > > > > But later mnt_drop_write_file() was added, and all callers of > > > mnt_want_write_file() were paired with it. This makes the compatibility > > > between mnt_want_write_file() and mnt_drop_write() no longer necessary. Umm... That really needs to be put into D/f/porting; this kind of rule changes (from "it used to work both ways" to "things quietly break if you use the old variant") should come with explicit statement in there. I'm certainly fine with unexporting mnt_clone_write() and making the damn thing static, but as for the rest I would put an explicit "don't pair mnt_drop_write() with mnt_want_write_file()" and wait for a cycle.