[PATCH v2 22/50] convert efivarfs

[James Bottomley]

On Wed, 2025-10-29 at 19:37 +0000, Al Viro wrote:
> On Wed, Oct 29, 2025 at 02:57:51PM -0400, James Bottomley wrote:
> 
> > I think this all looks OK.  The reason for the convolution is that
> > simple_start/done_creating() didn't exist when I did the conversion
> > ... although if they had, I'm not sure I'd have thought of
> > reworking efivarfs_create_dentry to use them.  I tried to update
> > some redundant bits, but it wasn't the focus of what I was trying
> > to fix.
> > 
> > So I think the cleanup works and looks nice.
> > 
> > > 
> > > Relying on the -EEXIST return value to detect duplicates, and
> > > combining the two callbacks seem like neat optimizations to me,
> > > so
> > > 
> > > Acked-by: Ard Biesheuvel <ardb at kernel.org>
> > > 
> > > but I have to confess I am slightly out of my depth when it comes
> > > to
> > > VFS stuff.
> > 
> > Yes, ack too.
> 
> 	Umm...  FWIW, I've got a few more followups on top of that
> (see
> #untested.efivarfs, current head at 36051c773015).  Not sure what
> would be the best way to deal with that stuff - I hope to get the
> main series stabilized and merged in the coming window.

Unless there's a bug lurking somewhere, I think think the cleanups are
great, but can wait for stabilization of the main series.

>   Right now I'm collecting feedback (acked-by, etc.), and there's a
> couple of outright bugfixes in front of the series, so I'd expect at
> least a rebase to -rc4...
> 
> Hell knows - one variant would be a never-rebased branch containing
> the introduction of simple_done_creating() + variant of efivarfs
> patch (as posted) ported on top of that (with d_instantiate()+dget()
> in place of d_make_persistent()), then have both #work.persistency
> and efivarfs followups pulling that branch...  Or I could simply hold
> them back until the next cycle.  Up to you - the main series is what
> I really want to get out of the way ASAP, especially considering the
> potential for conflicts with the stuff Neil Brown is playing with.

git log fs/efivarfs

will tell you were not a high patch throughput subsystem, so I'd guess
we won't need a stable base to work from because we can just wait ...
however, if a sudden unexpected flood of patches did come in, this
choice could be revisited, so it's probably the best one to start with.

Regards,

James