On Thu, Sep 17, 2020 at 01:54:41AM +0100, Al Viro wrote: > 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. Is there any point in waiting a cycle between adding the note to Documentation/filesystems/porting.rst and making the behavior change? It seems that all the other notes just get added at the same time the change is made. - Eric
