From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Weizhao Ouyang <o451686892@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>, Jeremy Kerr <jk@ozlabs.org>,
Ard Biesheuvel <ardb@kernel.org>,
Tim Schumacher <timschumi@gmx.de>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-efi@vger.kernel.org
Subject: Re: [RFC PATCH] efivarfs: Introduce efivarfs refresh remount
Date: Wed, 15 Jan 2025 09:58:12 -0500 [thread overview]
Message-ID: <ff67e26af366013478b0acab5e9ddd49316c605d.camel@HansenPartnership.com> (raw)
In-Reply-To: <CAHk0HovnRgxrKu0uoj1x3XSB1vrTaGtMn-7iaoSR5Fs+=EYd5g@mail.gmail.com>
On Wed, 2025-01-15 at 22:49 +0800, Weizhao Ouyang wrote:
> On Wed, Jan 15, 2025 at 10:34 PM James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> >
> > On Wed, 2025-01-15 at 22:14 +0800, Weizhao Ouyang wrote:
> > > Currently, when setting efi variables through the runtime
> > > service, efivarfs cannot sync variable updates properly.
> > > Introduce efivarfs refresh remount to support efivarfs
> > > information updates from other sources.
> >
> > What other sources could there possibly be? While the Linux kernel
> > has sole possession of the EFI RT interface after ExitBootServices
> > has been called, nothing else should be able to update the
> > variables except efivarfs. This is a guarantee from UEFI so why do
> > you think we can't rely on it?
>
> One route that may exist is: drivers/firmware/efi/test/efi_test.c
> holds some ioctls to call runtime service.
That's not supposed to be used for anything other than direct testing
using the firmware test suite, which shouldn't impact production use of
efivarfs because it's defined to be N in Kconfig. However, if we
suddenly decided there was a use case for production systems running
the test suite, the way forwards would be a notifier that tells
efivarfs about successful updates to variables as they occur without
having to remount.
Regards,
James
next prev parent reply other threads:[~2025-01-15 14:58 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-01-15 14:14 [RFC PATCH] efivarfs: Introduce efivarfs refresh remount Weizhao Ouyang
2025-01-15 14:33 ` James Bottomley
2025-01-15 14:49 ` Weizhao Ouyang
2025-01-15 14:58 ` James Bottomley [this message]
2025-01-15 15:00 ` Ard Biesheuvel
2025-01-15 15:17 ` Weizhao Ouyang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ff67e26af366013478b0acab5e9ddd49316c605d.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=ardb@kernel.org \
--cc=corbet@lwn.net \
--cc=jk@ozlabs.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=o451686892@gmail.com \
--cc=timschumi@gmx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox