[PATCH v2 22/50] convert efivarfs

[James Bottomley]

On Wed, 2025-11-05 at 12:47 +0100, Christian Brauner wrote:
> On Thu, Oct 30, 2025 at 02:35:51PM +0100, Ard Biesheuvel wrote:
[...]
> > commit 0e4f9483959b785f65a36120bb0e4cf1407e492c
> > Author: Christian Brauner <brauner at kernel.org>
> > Date:   Mon Mar 31 14:42:12 2025 +0200
> > 
> >     efivarfs: support freeze/thaw
> > 
> > actually broke James's implementation of the post-resume sync with
> > the underlying variable store.
> > 
> > So I wonder what the point is of all this complexity if it does not
> > work for the use case where it is the most important, i.e., resume
> > from hibernation, where the system goes through an ordinary cold
> > boot and so the EFI variable store may have gotten out of sync with
> > the hibernated kernel's view of it.
> > 
> > If no freeze/thaw support in the suspend/resume path is
> > forthcoming, would it be better to just revert that change? That
> > would badly conflict with your changes, though, so I'd like to
> > resolve this before 
> > going further down this path.
> 
> So first of all, this works. I've tested it extensively. If it
> doesn't work there's a regression.

I haven't yet got around to finding the test image I used for this, but
I'll try to do that and get a test running this week.

> And suspend/resume works just fine with freeze/thaw. See commit
> eacfbf74196f ("power: freeze filesystems during suspend/resume")
> which implements exactly that.
> 
> The reason this didn't work for you is very likely:
> 
> cat /sys/power/freeze_filesystems
> 0
> 
> which you must set to 1.

Actually, no, that's not correct.  The efivarfs freeze/thaw logic must
run unconditionally regardless of this setting to fix the systemd bug,
so all the variable resyncing is done in the thaw call, which isn't
conditioned on the above (or at least it shouldn't be).

> Second, that "complexity" replaces your way more complex blocking
> notifier implementation for this thing which simply deadlocked the
> system as I reported and showed earlier this year.
> 
> That blocking notifier thing had to use vfs_kern_mount() which had to
> come up with it's own internal private vfs mount to pin efivarfs
> because it's called out-of-band and then walk the list of variables
> and resync. Problem is that leads to completely untenable locking
> problems. So if you want to go back to that be my guest.

Let's figure out if we have a problem first (and if so, where) before
we get into possible solutions.

Regards,

James