Re: [PATCH v4] efivarfs: add nostatfs mount option to skip QueryVariableInfo()

["Ard Biesheuvel" <ardb@kernel.org>]

Hi Sebastian,

Thanks for taking a look.

On Tue, 29 Sep 2026, at 09:43, Sebastian Andrzej Siewior wrote:
> On 2026-09-28 13:34:45 [-0700], Prashant Singh wrote:
>> QueryVariableInfo() is an EFI runtime service that, on some firmware,
>> takes tens of milliseconds and runs with preemption disabled, stalling
>> the CPU that services it. efivarfs_statfs() calls it (rate-limited since
>> commit b2326338dc68 ("efivarfs: Rate limit statfs() handler")) to report
>> the variable-store used/available capacity, so any statfs(2) -- e.g.
>> every "df" -- can inject that stall into unrelated latency-sensitive
>> workloads on the same CPU.
>> 
>> Add a negatable "nostatfs" mount option: with nostatfs, statfs(2) skips
>> QueryVariableInfo() and reports zero used/available; with statfs it
>> reports the capacity as before. It defaults to nostatfs on
>> CONFIG_PREEMPT_RT so real-time kernels do not take the stall out of the
>> box, but statfs can be passed there to force reporting back on -- e.g.
>> for tools such as fwupd that need the efivars free space to update Secure
>> Boot key databases.
>> 
>> The option can also be toggled on a live mount via remount, so reporting
>> can be enabled only for the duration of a firmware update without
>> unmounting the boot-time efivarfs mount:
>> 
>>   mount -o remount,statfs   /sys/firmware/efi/efivars   # reporting on
>>   mount -o remount,nostatfs /sys/firmware/efi/efivars   # reporting off
>> 
>> Tested on an Intel Xeon E5-2628L v4, 6.12 kernel, via
>> "strace -T -e trace=statfs df" on the efivarfs mount.
>
> This until the end looks extremely verbose. Even if that statfs takes
> ages, that important part is that it does so with disables preemption.
> There has been also the introduction of the efi_runtime workqueue which
> can be pinned to a single CPU. I guess this doesn't work for you or the
> EFI firmware takes all other CPUs down until the all completes.
>

Yeah the most severe issue is that entering SMM requires a rendez-vous
of all the cores, and so whether preemption is enabled or not is
actually kind of irrelevant, given that all the other cores just
disappear.


...
>> diff --git a/Documentation/filesystems/efivarfs.rst b/Documentation/filesystems/efivarfs.rst
>> index f646c3f0980f..cd81ee84115b 100644
>> --- a/Documentation/filesystems/efivarfs.rst
>> +++ b/Documentation/filesystems/efivarfs.rst
>> @@ -37,6 +37,22 @@ accidentally.
>>            |4_bytes_of_attributes + efivar_data|
>>            +-----------------------------------+
>>  
>> +Mount options
>> +=============
>> +
>> +statfs / nostatfs
>> +      Control whether ``statfs(2)`` reports the variable-store used/available
>> +      capacity. Obtaining it requires the ``QueryVariableInfo()`` EFI runtime
>> +      service, which on some firmware takes tens of milliseconds and runs with
>> +      preemption disabled, stalling the calling CPU. With ``nostatfs`` the call
>> +      is skipped and ``statfs(2)`` reports zero. The default is to report,
>> +      except on ``CONFIG_PREEMPT_RT`` where it defaults to ``nostatfs``; pass
>> +      ``statfs`` there to force reporting back on (e.g. for tools such as fwupd
>> +      that need the free space for firmware updates). The option can also be
>> +      flipped on a live mount with ``mount -o remount,statfs`` /
>> +      ``mount -o remount,nostatfs``, so reporting can be enabled only for the
>> +      duration of a firmware update without unmounting efivarfs.
>
> could this be, I don't know something smaller not including the
> commandline where I would expect that people know how to use it.
>
> ===================     
> =========================================================
> (no)statfs		Control whether ``statfs(2)`` reports the variable-store
> 			used/ available. Disabling it skips the EFI runtime 
> 			service call, which might block the CPU for a few milliseconds,
> 			reporting 0 for used and capacity. Enabled by default on
> 			PREEMPT_RT.
> ===================     
> =========================================================
>

+1

> It might make sense to add this knob to 
> Documentation/core-api/real-time/hardware.rst.
> I am not sure yet but slowly we are getting more knobs that I have
> expected.
>
>> +
>>  *See also:*
>>  
>>  - Documentation/admin-guide/acpi/ssdt-overlays.rst
>> diff --git a/fs/efivarfs/internal.h b/fs/efivarfs/internal.h
>> index f913b6824289..0cb053884b4b 100644
>> --- a/fs/efivarfs/internal.h
>> +++ b/fs/efivarfs/internal.h
>> @@ -11,6 +11,7 @@
>>  struct efivarfs_mount_opts {
>>  	kuid_t uid;
>>  	kgid_t gid;
>> +	bool nostatfs;		/* skip QueryVariableInfo() in statfs() */
> Here and below you add a comment to every change you make. What about
> focusing on the important parts, that deserve an explanation why a
> change has been made. For instance why nostatfs has the READ_ONCE/
> WRITE_ONCE accessors and sometimes it does not.
>

AIUI the READ_ONCE/WRITE_ONCE were added because Sashiko warned about
potential KCSAN splats? It would be nice to mention that.

In any case, KCSAN is runtime instrumentation, and efi_reboot_required()
is only called after all other CPUs have been brought down. So if anything,
this should just wrap the read on the reboot path in a data_race() so
that we don't trigger any instrumentation inadvertently on the way down.