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@xxxxxxxxxx> > > > > > > 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.
