Linux-Fsdevel Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Al Viro <viro@zeniv.linux.org.uk>
To: Eric Biggers <ebiggers@kernel.org>
Cc: linux-fsdevel@vger.kernel.org, Daeho Jeong <daeho43@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] vfs: don't unnecessarily clone write access for writable fds
Date: Thu, 17 Sep 2020 01:54:41 +0100	[thread overview]
Message-ID: <20200917005441.GP3421308@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200916035914.GA825@sol.localdomain>

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 <ebiggers@google.com>
> > > 
> > > 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.

  reply	other threads:[~2020-09-17  0:54 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-11 16:05 Eric Biggers
2020-06-29 16:50 ` Eric Biggers
2020-09-16  3:59   ` Eric Biggers
2020-09-17  0:54     ` Al Viro [this message]
2020-09-22 16:41       ` Eric Biggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200917005441.GP3421308@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=daeho43@gmail.com \
    --cc=ebiggers@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH v2] vfs: don'\''t unnecessarily clone write access for writable fds' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).