Re: efi: be more paranoid about available space when creating variables

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Commit 68d929862e29 'efi: be more paranoid about available space when
creating variables' caused a regression on my EFI-booting desktop.
(I'm actually testing on 3.2.41 with several more fixes backported, but
this shouldn't matter.)

The meaningful DMI IDs for this system are:

/sys/devices/virtual/dmi/id/bios_date:08/22/2012
/sys/devices/virtual/dmi/id/bios_vendor:American Megatrends Inc.
/sys/devices/virtual/dmi/id/bios_version:4003
/sys/devices/virtual/dmi/id/board_name:P8Z68-V LX
/sys/devices/virtual/dmi/id/board_vendor:ASUSTeK Computer INC.

It is no longer possible to write any variables; this always fails with
-ENOSPC.  (It also wasn't possible to delete variables - but I
introduced that bug in backporting.)  With some extra debug logging I
found that query_variable_information yielded:

storage_size = 65536
remaining_size = 23760
max_size = 23734

This is not full enough to trigger garbage collection; in fact
remaining_size and max_size continue to drop by 36 bytes after each
reboot as the BIOS is updating the variable
MonotonicCounter-8be4df61-93ca-11d2-aa0d-00e098032b8c.

13 reboots later I had:

remaining_size = 23292

I removed the size check and triggered a panic, which uses about 12K in
dump variables.  After rebooting I had:

remaining_size = 39879

So the trigger for garbage collection on this system is somewhere
between about 10K and 23K remaining out of the total of 64K.

efivars absolutely must allow writing until the point at which garbage
collection is triggered.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, about L-Space IRC channel #afp

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]