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 <[email protected]> > > > > > > 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
