[PATCH v2 22/50] convert efivarfs

Al Viro viro at zeniv.linux.org.uk
Thu Oct 30 06:37:55 AEDT 2025


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


More information about the Linuxppc-dev mailing list