Re: [RFC PATCH v6 4/9] vfs: lookup_open(): move setting FMODE_CREATED up when calling create()

[Jori Koolstra]

> Op 02-06-2026 15:41 CEST schreef Christian Brauner <brauner@xxxxxxxxxx>:
> 
>  
> On Mon, Jun 01, 2026 at 12:34:40PM +1000, NeilBrown wrote:
> > On Mon, 01 Jun 2026, Jori Koolstra wrote:
> > > In preparation for using vfs_create_no_perm() in lookup_open() we need
> > > to move setting FMODE_CREATED on the file mode to either before or after
> > > that call, as currently it is in the middle. If try_break_deleg() fails
> > > it is currently not set, but vfs_create_no_perm() includes a
> > > try_break_deleg().
> > > 
> > > Going up the call chain of lookup_open() we see that it is only used in
> > > open_last_lookups() if no error is returned from lookup_open(), so we
> > > can safely move it to after the filesystem create() call. This also
> > > makes more sense when reading the code as you don't have to wonder what
> > > the implications are of setting FMODE_CREATED before the create() call.
> > 
> > It seemed a bit odd to me that we set FMODE_CREATED before actually
> > creating.
> 
> Plus, we kinda-sorta-maybe do expose that as uapi - even though it's
> broken on networking filesystems... which I didn't know in that detail
> back then. So be prepared to whack me over the head with:
> 
> 820a185896b77814557302b981b092a9e7b36814
> 
> 
> > It doesn't matter as FMODE_CREATED is only meaningful if no error has
> > been reported, and if create doesn't end up happening, then there must
> > be an error.
> > 
> > So I like this improvement.
> 
> Agreed.

Let's also just fix this in O_CREAT|O_DIR branch. If somehow that doesn't
make it, we can salvage these pieces and apply them. There is not hurry to
fix this, I think.