On Wed, 29 Oct 2025 at 19:08, Al Viro <[email protected]> wrote: > > On Tue, Oct 28, 2025 at 10:34:51PM +0100, Ard Biesheuvel wrote: > > > I'll let James respond to the specifics of your suggestion, but I'll > > just note that this code has a rather convoluted history, as we used > > to have two separate pseudo-filesystem drivers, up until a few years > > ago: the sysfs based 'efivars' and this efivarfs driver. Given that > > modifications in one needed to be visible in the other, they shared a > > linked list that shadowed the state of the underlying variable store. > > 'efivars' was removed years ago, but it was only recently that James > > replaced the linked list in this driver with the dentry cache as the > > shadow mechanism. > > Hmm... Another question about that code: is efivar_get_variable() > safe outside of efivar_lock()?
Not according to its kerneldoc /* * efivar_get_variable() - retrieve a variable identified by name/vendor * * Must be called with efivars_lock held. */ But actually, I'm not convinced this is accurate. The reason for locking at this level is mainly to ensure that a SetVariable() call does not interfere with an ongoing enumeration calling GetNextVariable() in a loop. The individual EFI runtime calls are still serialized at a lower level, given that the firmware is not reentrant, and so holding efivars_lock does not provide anything meaningful for a GetVariable() call.
