Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 25 6月, 2022 7 次提交
    • A
      efi: vars: Switch to new wrapper layer · bbc6d2c6
      由 Ard Biesheuvel 提交于 
      Switch the caching linked-list efivars layer implementation to the newly
introduced efivar get/set variable wrappers, instead of accessing the
lock and the ops pointer directly. This will permit us to move this code
out of the public efivars API, and into efivarfs once the obsolete sysfs
access method is finally removed.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      bbc6d2c6
    • A
      efi: vars: Remove deprecated 'efivars' sysfs interface · 0f5b2c69
      由 Ard Biesheuvel 提交于 
      Commit 5d9db883 ("efi: Add support for a UEFI variable filesystem")
dated Oct 5, 2012, introduced a new efivarfs pseudo-filesystem to
replace the efivars sysfs interface that was used up to that point to
expose EFI variables to user space.

The main problem with the sysfs interface was that it only supported up
to 1024 bytes of payload per file, whereas the underlying variables
themselves are only bounded by a platform specific per-variable and
global limit that is typically much higher than 1024 bytes.

The deprecated sysfs interface is only enabled on x86 and Itanium, other
EFI enabled architectures only support the efivarfs pseudo-filesystem.

So let's finally rip off the band aid, and drop the old interface
entirely. This will make it easier to refactor and clean up the
underlying infrastructure that is shared between efivars, efivarfs and
efi-pstore, and is long overdue for a makeover.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      0f5b2c69
    • A
      efi: vars: Drop __efivar_entry_iter() helper which is no longer used · 5ac94136
      由 Ard Biesheuvel 提交于 
      __efivar_entry_iter() uses a list iterator in a dubious way, i.e., it
assumes that the iteration variable always points to an object of the
appropriate type, even if the list traversal exhausts the list
completely, in which case it will point somewhere in the vicinity of the
list's anchor instead.

Fortunately, we no longer use this function so we can just get rid of it
entirely.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      5ac94136
    • A
      efi: vars: Use locking version to iterate over efivars linked lists · 3a75f9f2
      由 Ard Biesheuvel 提交于 
      Both efivars and efivarfs uses __efivar_entry_iter() to go over the
linked list that shadows the list of EFI variables held by the firmware,
but fail to call the begin/end helpers that are documented as a
prerequisite.

So switch to the proper version, which is efivar_entry_iter(). Given
that in both cases, efivar_entry_remove() is invoked with the lock held
already, don't take the lock there anymore.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      3a75f9f2
    • A
      efi: pstore: Omit efivars caching EFI varstore access layer · 85974825
      由 Ard Biesheuvel 提交于 
      Avoid the efivars layer and simply call the newly introduced EFI
varstore helpers instead. This simplifies the code substantially, and
also allows us to remove some hacks in the shared efivars layer that
were added for efi-pstore specifically.

In order to be able to delete the EFI variable associated with a record,
store the UTF-16 name of the variable in the pstore record's priv field.
That way, we don't have to make guesses regarding which variable the
record may have been loaded from.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      85974825
    • A
      efi: vars: Add thin wrapper around EFI get/set variable interface · 472831d4
      由 Ard Biesheuvel 提交于 
      The current efivars layer is a jumble of list iterators, shadow data
structures and safe variable manipulation helpers that really belong in
the efivarfs pseudo file system once the obsolete sysfs access method to
EFI variables is removed.

So split off a minimal efivar get/set variable API that reuses the
existing efivars_lock semaphore to mediate access to the various runtime
services, primarily to ensure that performing a SetVariable() on one CPU
while another is calling GetNextVariable() in a loop to enumerate the
contents of the EFI variable store does not result in surprises.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      472831d4
    • A
      efi: vars: Don't drop lock in the middle of efivar_init() · ec3507b2
      由 Ard Biesheuvel 提交于 
      Even though the efivars_lock lock is documented as protecting the
efivars->ops pointer (among other things), efivar_init() happily
releases and reacquires the lock for every EFI variable that it
enumerates. This used to be needed because the lock was originally a
spinlock, which prevented the callback that is invoked for every
variable from being able to sleep. However, releasing the lock could
potentially invalidate the ops pointer, but more importantly, it might
allow a SetVariable() runtime service call to take place concurrently,
and the UEFI spec does not define how this affects an enumeration that
is running in parallel using the GetNextVariable() runtime service,
which is what efivar_init() uses.

In the meantime, the lock has been converted into a semaphore, and the
only reason we need to drop the lock is because the efivarfs pseudo
filesystem driver will otherwise deadlock when it invokes the efivars
API from the callback to create the efivar_entry items and insert them
into the linked list. (EFI pstore is affected in a similar way)

So let's switch to helpers that can be used while the lock is already
taken. This way, we can hold on to the lock throughout the enumeration.
Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      ec3507b2
  3. 24 6月, 2022 1 次提交
  5. 20 6月, 2022 5 次提交
  7. 15 6月, 2022 2 次提交
  9. 06 6月, 2022 1 次提交
  11. 04 6月, 2022 5 次提交
  13. 03 6月, 2022 8 次提交
  15. 02 6月, 2022 11 次提交