lkml.org 
[lkml]   [2020]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2] vfs: don't unnecessarily clone write access for writable fds
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.

\
 
 \ /
  Last update: 2020-09-17 02:55    [W:0.032 / U:6.600 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site