On Tuesday, 25 February 2025 at 12:59, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > Reading the code in the fix, it looks like you were creating a file in > EFI (which is naturally zero length), then closing it (because glib gio > specifically has an API for this), then clearing the immutable bit and > then writing to it to actually create a variable? Correct. > However, none of that dance is at all required. A newly created file > naturally allows writing on the file descriptor you used to create it. Yes, the original code was ported from libefivar iirc, hence why it's not exactly idiomatic. > It's only if you open it again that the entry becomes immutable. So > your update has the correct logic: if file exists clear immutable and > write otherwise add O_CREAT. Agree. > The change is rather embedded in a set of other fixes now. If we > wanted a temporary and quickly removable work around for the current > kernel, I think using i_size to signal whether the file is newly > created and not written (0) or failed a write (1) and only removing the > file if it failed a write might be a simple two line fix. That way we > still keep the benefit of cleanup on a failed write while not impacting > your pattern. > Can you confirm this has that effect? The fixup does seem to work so please feel free to add "Tested-by: Richard Hughes <richard@xxxxxxxxxxx>" -- you can revert it after a few months if you like. It'll certainly take the pressure off, and we have a "known issue" we can use on the LVFS for people reporting problems: https://github.com/fwupd/fwupd/wiki/LVFS-Triaged-Issue:-Linux-6.14-efivarfs-regression Thanks! Richard.
