01 Aug, 2013
1 commit
-
My previous refactoring in commit 79bae42d51a5 ("dmi_scan: refactor
dmi_scan_machine(), {smbios,dmi}_present()") resulted in slightly tricky
code (though I think it's more elegant). Explain what it's doing.Signed-off-by: Ben Hutchings
Cc: Zhenzhong Duan
Cc: Jean Delvare
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
11 Jul, 2013
1 commit
-
The efivars code requires EFI runtime services to function, so check
that they are enabled.This fixes a crash when booting with the "noefi" kernel parameter, and
also when mixing kernel and firmware "bitness", e.g. 32-bit kernel with
64-bit firmware.Tested-by: Dave Young
Signed-off-by: Matt Fleming
05 Jul, 2013
1 commit
-
Pull powerpc updates from Ben Herrenschmidt:
"This is the powerpc changes for the 3.11 merge window. In addition to
the usual bug fixes and small updates, the main highlights are:- Support for transparent huge pages by Aneesh Kumar for 64-bit
server processors. This allows the use of 16M pages as transparent
huge pages on kernels compiled with a 64K base page size.- Base VFIO support for KVM on power by Alexey Kardashevskiy
- Wiring up of our nvram to the pstore infrastructure, including
putting compressed oopses in there by Aruna Balakrishnaiah- Move, rework and improve our "EEH" (basically PCI error handling
and recovery) infrastructure. It is no longer specific to pseries
but is now usable by the new "powernv" platform as well (no
hypervisor) by Gavin Shan.- I fixed some bugs in our math-emu instruction decoding and made it
usable to emulate some optional FP instructions on processors with
hard FP that lack them (such as fsqrt on Freescale embedded
processors).- Support for Power8 "Event Based Branch" facility by Michael
Ellerman. This facility allows what is basically "userspace
interrupts" for performance monitor events.- A bunch of Transactional Memory vs. Signals bug fixes and HW
breakpoint/watchpoint fixes by Michael Neuling.And more ... I appologize in advance if I've failed to highlight
something that somebody deemed worth it."* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc: (156 commits)
pstore: Add hsize argument in write_buf call of pstore_ftrace_call
powerpc/fsl: add MPIC timer wakeup support
powerpc/mpic: create mpic subsystem object
powerpc/mpic: add global timer support
powerpc/mpic: add irq_set_wake support
powerpc/85xx: enable coreint for all the 64bit boards
powerpc/8xx: Erroneous double irq_eoi() on CPM IRQ in MPC8xx
powerpc/fsl: Enable CONFIG_E1000E in mpc85xx_smp_defconfig
powerpc/mpic: Add get_version API both for internal and external use
powerpc: Handle both new style and old style reserve maps
powerpc/hw_brk: Fix off by one error when validating DAWR region end
powerpc/pseries: Support compression of oops text via pstore
powerpc/pseries: Re-organise the oops compression code
pstore: Pass header size in the pstore write callback
powerpc/powernv: Fix iommu initialization again
powerpc/pseries: Inform the hypervisor we are using EBB regs
powerpc/perf: Add power8 EBB support
powerpc/perf: Core EBB support for 64-bit book3s
powerpc/perf: Drop MMCRA from thread_struct
powerpc/perf: Don't enable if we have zero events
...
04 Jul, 2013
3 commits
-
Merge first patch-bomb from Andrew Morton:
- various misc bits
- I'm been patchmonkeying ocfs2 for a while, as Joel and Mark have been
distracted. There has been quite a bit of activity.
- About half the MM queue
- Some backlight bits
- Various lib/ updates
- checkpatch updates
- zillions more little rtc patches
- ptrace
- signals
- exec
- procfs
- rapidio
- nbd
- aoe
- pps
- memstick
- tools/testing/selftests updates* emailed patches from Andrew Morton : (445 commits)
tools/testing/selftests: don't assume the x bit is set on scripts
selftests: add .gitignore for kcmp
selftests: fix clean target in kcmp Makefile
selftests: add .gitignore for vm
selftests: add hugetlbfstest
self-test: fix make clean
selftests: exit 1 on failure
kernel/resource.c: remove the unneeded assignment in function __find_resource
aio: fix wrong comment in aio_complete()
drivers/w1/slaves/w1_ds2408.c: add magic sequence to disable P0 test mode
drivers/memstick/host/r592.c: convert to module_pci_driver
drivers/memstick/host/jmb38x_ms: convert to module_pci_driver
pps-gpio: add device-tree binding and support
drivers/pps/clients/pps-gpio.c: convert to module_platform_driver
drivers/pps/clients/pps-gpio.c: convert to devm_* helpers
drivers/parport/share.c: use kzalloc
Documentation/accounting/getdelays.c: avoid strncpy in accounting tool
aoe: update internal version number to v83
aoe: update copyright date
aoe: perform I/O completions in parallel
... -
dmi_match() considers a substring match to be a successful match. This is
not always sufficient to distinguish between DMI data for different
systems. Add support for exact string matching using strcmp() in addition
to the substring matching using strstr().The specific use case in the i915 driver is to allow us to use an exact
match for D510MO, without also incorrectly matching D510MOV:{
.ident = "Intel D510MO",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Intel"),
DMI_EXACT_MATCH(DMI_BOARD_NAME, "D510MO"),
},
}Signed-off-by: Jani Nikula
Cc:
Cc: Chris Wilson
Cc: Cornel Panceac
Acked-by: Daniel Vetter
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Pull pstore update from Tony Luck:
"Fixes for pstore for 3.11 merge window"* tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux:
efivars: If pstore_register fails, free unneeded pstore buffer
acpi: Eliminate console msg if pstore.backend excludes ERST
pstore: Return unique error if backend registration excluded by kernel param
pstore: Fail to unlink if a driver has not defined pstore_erase
pstore/ram: remove the power of buffer size limitation
pstore/ram: avoid atomic accesses for ioremapped regions
efi, pstore: Cocci spatch "memdup.spatch"
01 Jul, 2013
1 commit
-
Header size is needed to distinguish between header and the dump data.
Incorporate the addition of new argument (hsize) in the pstore write
callback.Signed-off-by: Aruna Balakrishnaiah
Acked-by: Kees Cook
Signed-off-by: Benjamin Herrenschmidt
29 Jun, 2013
1 commit
-
This is patch 3/3 of a patch set that cleans up pstore_register failure paths.
If efivars fails to register with pstore, there is no point to keeping
the 4 KB buffer around. It's only used by the pstore read/write routines.Signed-off-by: Lenny Szubowicz
Reported-by: Naotaka Hamaguchi
Signed-off-by: Tony Luck
18 Jun, 2013
1 commit
-
We want these fixes here too.
Signed-off-by: Greg Kroah-Hartman
04 Jun, 2013
2 commits
-
Change a kmalloc() + memcpy() pair for a single kmemdup() call.
Signed-off-by: Thomas Meyer
Acked-by: Kees Cook
Signed-off-by: Tony Luck -
The usermode helper is mandatory for this driver.
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman
14 May, 2013
1 commit
-
The loop in efivar_update_sysfs_entries() reuses the same allocation for
entries each time it calls efivar_create_sysfs_entry(entry). This is
wrong because efivar_create_sysfs_entry() expects to keep the memory it
was passed, so the caller may not free it (and may not pass the same
memory in multiple times). This leads to the oops below. Fix by
getting a new allocation each time we go around the loop.---[ end trace ba4907d5c519d111 ]---
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] efivar_entry_find+0x14f/0x2d0
PGD 0
Oops: 0000 [#2] SMP
Modules linked in: oops(OF+) ebtable_nat ebtables xt_CHECKSUM [...]
CPU: 0 PID: 301 Comm: kworker/0:2 Tainted: GF D O 3.9.0+ #1
Hardware name: LENOVO 4291EV7/4291EV7, BIOS 8DET52WW (1.22 ) 09/15/2011
Workqueue: events efivar_update_sysfs_entries
task: ffff8801955920c0 ti: ffff88019413e000 task.ti: ffff88019413e000
RIP: 0010:[] [] efivar_entry_find+0x14f/0x2d0
RSP: 0018:ffff88019413fa48 EFLAGS: 00010006
RAX: 0000000000000000 RBX: ffff880195d87c00 RCX: ffffffff81ab6f60
RDX: ffff88019413fb88 RSI: 0000000000000400 RDI: ffff880196254000
RBP: ffff88019413fbd8 R08: 0000000000000000 R09: ffff8800dad99037
R10: ffff880195d87c00 R11: 0000000000000430 R12: ffffffff81ab6f60
R13: fffffffffffff7d8 R14: ffff880196254000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff88019e200000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000407f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
ffff88019413fb78 ffff88019413fb88 ffffffff81e85d60 03000000972b5c00
ffff88019413fa29 ffffffff81e85d60 ffff88019413fbfb 0000000197087280
00000000000000fe 0000000000000001 ffffffff81e85dd9 ffff880197087280
Call Trace:
[] ? idr_get_empty_slot+0x131/0x240
[] ? put_dec+0x72/0x90
[] ? cache_alloc_refill+0x170/0x2f0
[] efivar_update_sysfs_entry+0x150/0x220
[] ? efi_call2+0x9/0x70
[] ? virt_efi_get_next_variable+0x47/0x1b0
[] ? kmem_cache_alloc_trace+0x1af/0x1c0
[] efivar_init+0x2c3/0x380
[] ? efivar_delete+0xd0/0xd0
[] efivar_update_sysfs_entries+0x6f/0x90
[] process_one_work+0x183/0x490
[] worker_thread+0x120/0x3a0
[] ? manage_workers+0x160/0x160
[] kthread+0xce/0xe0
[] ? kthread_freezable_should_stop+0x70/0x70
[] ret_from_fork+0x7c/0xb0
[] ? kthread_freezable_should_stop+0x70/0x70
Code: 8d 55 b0 48 8d 45 a0 49 81 ed 28 08 00 00 48 89 95 78 fe [...]
RIP [] efivar_entry_find+0x14f/0x2d0
RSP
CR2: 0000000000000000
---[ end trace ba4907d5c519d112 ]---Cc: James Bottomley
Cc: Tomoki Sekiyama
Signed-off-by: Seiji Aguchi
Signed-off-by: Matt Fleming
02 May, 2013
2 commits
-
Pull VFS updates from Al Viro,
Misc cleanups all over the place, mainly wrt /proc interfaces (switch
create_proc_entry to proc_create(), get rid of the deprecated
create_proc_read_entry() in favor of using proc_create_data() and
seq_file etc).7kloc removed.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (204 commits)
don't bother with deferred freeing of fdtables
proc: Move non-public stuff from linux/proc_fs.h to fs/proc/internal.h
proc: Make the PROC_I() and PDE() macros internal to procfs
proc: Supply a function to remove a proc entry by PDE
take cgroup_open() and cpuset_open() to fs/proc/base.c
ppc: Clean up scanlog
ppc: Clean up rtas_flash driver somewhat
hostap: proc: Use remove_proc_subtree()
drm: proc: Use remove_proc_subtree()
drm: proc: Use minor->index to label things, not PDE->name
drm: Constify drm_proc_list[]
zoran: Don't print proc_dir_entry data in debug
reiserfs: Don't access the proc_dir_entry in r_open(), r_start() r_show()
proc: Supply an accessor for getting the data from a PDE's parent
airo: Use remove_proc_subtree()
rtl8192u: Don't need to save device proc dir PDE
rtl8187se: Use a dir under /proc/net/r8180/
proc: Add proc_mkdir_data()
proc: Move some bits from linux/proc_fs.h to linux/{of.h,signal.h,tty.h}
proc: Move PDE_NET() to fs/proc/proc_net.c
... -
Pull x86/efi changes from Peter Anvin:
"The bulk of these changes are cleaning up the efivars handling and
breaking it up into a tree of files. There are a number of fixes as
well.The entire changeset is pretty big, but most of it is code movement.
Several of these commits are quite new; the history got very messed up
due to a mismerge with the urgent changes for rc8 which completely
broke IA64, and so Ingo requested that we rebase it to straighten it
out."* 'x86-efi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
efi: remove "kfree(NULL)"
efi: locking fix in efivar_entry_set_safe()
efi, pstore: Read data from variable store before memcpy()
efi, pstore: Remove entry from list when erasing
efi, pstore: Initialise 'entry' before iterating
efi: split efisubsystem from efivars
efivarfs: Move to fs/efivarfs
efivars: Move pstore code into the new EFI directory
efivars: efivar_entry API
efivars: Keep a private global pointer to efivars
efi: move utf16 string functions to efi.h
x86, efi: Make efi_memblock_x86_reserve_range more readable
efivarfs: convert to use simple_open()
01 May, 2013
3 commits
-
Move the calls to memcpy_fromio() up into the loop in
dmi_scan_machine(), and move the signature checks back down into
dmi_decode(). We need to check at 16-byte intervals but keep a 32-byte
buffer for an SMBIOS entry, so shift the buffer after each iteration.Merge smbios_present() into dmi_present(), so we look for an SMBIOS
signature at the beginning of the given buffer and then for a DMI
signature at an offset of 16 bytes.[artem.savkov@gmail.com: use proper buf type in dmi_present()]
Signed-off-by: Ben Hutchings
Reported-by: Tim McGrath
Tested-by: Tim Mcgrath
Cc: Zhenzhong Duan
Signed-off-by: Artem Savkov
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
x86 and ia64 can acquire extra hardware identification information
from DMI and print it along with task dumps; however, the usage isn't
consistent.* x86 show_regs() collects vendor, product and board strings and print
them out with PID, comm and utsname. Some of the information is
printed again later in the same dump.* warn_slowpath_common() explicitly accesses the DMI board and prints
it out with "Hardware name:" label. This applies to both x86 and
ia64 but is irrelevant on all other archs.* ia64 doesn't show DMI information on other non-WARN dumps.
This patch introduces arch-specific hardware description used by
dump_stack(). It can be set by calling dump_stack_set_arch_desc()
during boot and, if exists, printed out in a separate line with
"Hardware name:" label.dmi_set_dump_stack_arch_desc() is added which sets arch-specific
description from DMI data. It uses dmi_ids_string[] which is set from
dmi_present() used for DMI debug message. It is superset of the
information x86 show_regs() is using. The function is called from x86
and ia64 boot code right after dmi_scan_machine().This makes the explicit DMI handling in warn_slowpath_common()
unnecessary. Removed.show_regs() isn't yet converted to use generic debug information
printing and this patch doesn't remove the duplicate DMI handling in
x86 show_regs(). The next patch will unify show_regs() handling and
remove the duplication.An example WARN dump follows.
WARNING: at kernel/workqueue.c:4841 init_workqueues+0x35/0x505()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0-rc1-work+ #3
Hardware name: empty empty/S3992, BIOS 080011 10/26/2007
0000000000000009 ffff88007c861e08 ffffffff81c614dc ffff88007c861e48
ffffffff8108f500 ffffffff82228240 0000000000000040 ffffffff8234a08e
0000000000000000 0000000000000000 0000000000000000 ffff88007c861e58
Call Trace:
[] dump_stack+0x19/0x1b
[] warn_slowpath_common+0x70/0xa0
[] warn_slowpath_null+0x1a/0x20
[] init_workqueues+0x35/0x505
...v2: Use the same string as the debug message from dmi_present() which
also contains BIOS information. Move hardware name into its own
line as warn_slowpath_common() did. This change was suggested by
Bjorn Helgaas.Signed-off-by: Tejun Heo
Cc: Bjorn Helgaas
Cc: David S. Miller
Cc: Fengguang Wu
Cc: Heiko Carstens
Cc: Jesper Nilsson
Cc: Martin Schwidefsky
Cc: Mike Frysinger
Cc: Vineet Gupta
Cc: Sam Ravnborg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
We're goning to use DMI identification for other purposes too. Morph
dmi_dump_ids() which is used to print DMI identification as a debug
message during boot into dmi_format_ids() which formats the same
information sans the leading "DMI:" tag into a string buffer.dmi_present() is updated to format the information into dmi_ids_string[]
using the new function and print it with "DMI:" prefix.dmi_ids_string[] will be used for another purpose by a future patch.
Signed-off-by: Tejun Heo
Cc: Bjorn Helgaas
Cc: David S. Miller
Cc: Fengguang Wu
Cc: Heiko Carstens
Cc: Jesper Nilsson
Cc: Martin Schwidefsky
Cc: Mike Frysinger
Cc: Vineet Gupta
Cc: Sam Ravnborg
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
30 Apr, 2013
8 commits
-
No need to free a NULL pointer.
Signed-off-by: Dan Carpenter
Signed-off-by: Matt Fleming -
The intent is that if we aren't allowed to block because we're in an
NMI or an emergency then we only take the lock if it is uncontended.Part of the problem is the test is reversed so we return -EBUSY if we
acquire the lock.Signed-off-by: Dan Carpenter
Signed-off-by: Matt Fleming -
Seiji reported getting empty dmesg-* files, because the data was never
actually read in efi_pstore_read_func(), and so the memcpy() was copying
garbage data.This patch necessitated adding __efivar_entry_get() which is callable
between efivar_entry_iter_{begin,end}(). We can also delete
__efivar_entry_size() because efi_pstore_read_func() was the only
caller.Reported-by: Seiji Aguchi
Tested-by: Seiji Aguchi
Cc: Tony Luck
Cc: Matthew Garrett
Signed-off-by: Matt Fleming -
We need to remove the entry from the EFI variable list before we erase
it from the variable store and free the associated state, otherwise it's
possible to hit the following crash,BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [] __efivar_entry_iter+0xcf/0x120
PGD 19483f067 PUD 195426067 PMD 0
Oops: 0000 [#1] SMP
[...]
Call Trace:
[] efi_pstore_erase+0xef/0x140
[] ? math_error+0x288/0x2d0
[] pstore_unlink+0x41/0x60
[] vfs_unlink+0x9f/0x110
[] do_unlinkat+0x18b/0x280
[] ? sys_newfstatat+0x36/0x50
[] sys_unlinkat+0x22/0x40
[] system_call_fastpath+0x16/0x1bReported-by: Seiji Aguchi
Tested-by: Seiji Aguchi
Cc: Tony Luck
Cc: Matthew Garrett
Signed-off-by: Matt Fleming -
Seiji reports hitting the following crash when erasing pstore dump
variables,BUG: unable to handle kernel NULL pointer dereference at 0000000000000fa4
IP: [] __efivar_entry_iter+0x2f/0x120
PGD 18482a067 PUD 190724067 PMD 0
Oops: 0000 [#1] SMP
[...]
Call Trace:
[] efi_pstore_erase+0xdf/0x130
[] ? cap_socket_create+0x8/0x10
[] pstore_unlink+0x41/0x60
[] vfs_unlink+0x9f/0x110
[] do_unlinkat+0x18b/0x280
[] sys_unlinkat+0x22/0x40
[] system_call_fastpath+0x16/0x1b'entry' needs to be initialised in efi_pstore_erase() when iterating
with __efivar_entry_iter(), otherwise the garbage pointer will be
dereferenced, leading to crashes like the above.Reported-by: Seiji Aguchi
Tested-by: Seiji Aguchi
Cc: Tony Luck
Cc: Matthew Garrett
Signed-off-by: Matt Fleming -
Resolve conflicts for Ingo.
Conflicts:
drivers/firmware/Kconfig
drivers/firmware/efivars.cSigned-off-by: Matt Fleming
-
When hot removing memory, a firmware_map_entry which has memory range of
the memory is released by release_firmware_map_entry(). If the entry is
allocated by bootmem, release_firmware_map_entry() adds the entry to
map_entires_bootmem list when firmware_map_find_entry() finds the entry
from map_entries list. But firmware_map_find_entry never find the entry
sicne map_entires list does not have the entry. So the entry just
leaks.Here are steps of leaking firmware_map_entry:
firmware_map_remove()
-> firmware_map_find_entry()
Find released entry from map_entries list
-> firmware_map_remove_entry()
Delete the entry from map_entries list
-> remove_sysfs_fw_map_entry()
...
-> release_firmware_map_entry()
-> firmware_map_find_entry()
Find the entry from map_entries list but the entry has been
deleted from map_entries list. So the entry is not added
to map_entries_bootmem. Thus the entry leaksrelease_firmware_map_entry() should not call firmware_map_find_entry()
since releaed entry has been deleted from map_entries list. So the
patch delete firmware_map_find_entry() from releae_firmware_map_entry()Signed-off-by: Yasuaki Ishimatsu
Reviewed-by: Wanpeng Li
Reviewed-by: Tang Chen
Acked-by: Toshi Kani
Cc: Wen Congyang
Cc: Greg KH
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Include missing linux/magic.h inclusions where the source file is currently
expecting to get magic numbers through linux/proc_fs.h.Signed-off-by: David Howells
cc: linux-efi@vger.kernel.org
Signed-off-by: Al Viro
26 Apr, 2013
1 commit
-
variable_is_present() accesses '__efivars' directly, but when called via
gsmi_init() Michel reports observing the following crash,BUG: unable to handle kernel NULL pointer dereference at (null)
IP: variable_is_present+0x55/0x170
Call Trace:
register_efivars+0x106/0x370
gsmi_init+0x2ad/0x3da
do_one_initcall+0x3f/0x170The reason for the crash is that '__efivars' hasn't been initialised nor
has it been registered with register_efivars() by the time the google
EFI SMI driver runs. The gsmi code uses its own struct efivars, and
therefore, a different variable list. Fix the above crash by passing
the registered struct efivars to variable_is_present(), so that we
traverse the correct list.Reported-by: Michel Lespinasse
Tested-by: Michel Lespinasse
Cc: Mike Waychison
Cc: Matthew Garrett
Cc: Seiji Aguchi
Signed-off-by: Matt Fleming
Signed-off-by: Linus Torvalds
17 Apr, 2013
6 commits
-
This registers /sys/firmware/efi/{,systab,efivars/} whenever EFI is enabled
and the system is booted with EFI.This allows
*) userspace to check for the existence of /sys/firmware/efi as a way
to determine whether or it is running on an EFI system.
*) 'mount -t efivarfs none /sys/firmware/efi/efivars' without manually
loading any modules.[ Also, move the efivar API into vars.c and unconditionally compile it.
This allows us to move efivars.c, which now only contains the sysfs
variable code, into the firmware/efi directory. Note that the efivars.c
filename is kept to maintain backwards compatability with the old
efivars.ko module. With this patch it is now possible for efivarfs
to be built without CONFIG_EFI_VARS - Matt ]Cc: Seiji Aguchi
Cc: Tony Luck
Cc: Mike Waychison
Cc: Kay Sievers
Cc: Jeremy Kerr
Cc: Matthew Garrett
Cc: Chun-Yi Lee
Cc: Andy Whitcroft
Cc: Tobias Powalowski
Signed-off-by: Tom Gundersen
Signed-off-by: Matt Fleming -
Now that efivarfs uses the efivar API, move it out of efivars.c and
into fs/efivarfs where it belongs. This move will eventually allow us
to enable the efivarfs code without having to also enable
CONFIG_EFI_VARS built, and vice versa.Furthermore, things like,
mount -t efivarfs none /sys/firmware/efi/efivars
will now work if efivarfs is built as a module without requiring the
use of MODULE_ALIAS(), which would have been necessary when the
efivarfs code was part of efivars.c.Cc: Matthew Garrett
Cc: Jeremy Kerr
Reviewed-by: Tom Gundersen
Tested-by: Tom Gundersen
Signed-off-by: Matt Fleming -
efivars.c has grown far too large and needs to be divided up. Create a
new directory and move the persistence storage code to efi-pstore.c now
that it uses the new efivar API. This helps us to greatly reduce the
size of efivars.c and paves the way for moving other code out of
efivars.c.Note that because CONFIG_EFI_VARS can be built as a module efi-pstore
must also include support for building as a module.Reviewed-by: Tom Gundersen
Tested-by: Tom Gundersen
Cc: Seiji Aguchi
Cc: Anton Vorontsov
Cc: Colin Cross
Cc: Kees Cook
Cc: Matthew Garrett
Cc: Tony Luck
Signed-off-by: Matt Fleming -
There isn't really a formal interface for dealing with EFI variables
or struct efivar_entry. Historically, this has led to various bits of
code directly accessing the generic EFI variable ops, which inherently
ties it to specific EFI variable operations instead of indirectly
using whatever ops were registered with register_efivars(). This lead
to the efivarfs code only working with the generic EFI variable ops
and not CONFIG_GOOGLE_SMI.Encapsulate everything that needs to access '__efivars' inside an
efivar_entry_* API and use the new API in the pstore, sysfs and
efivarfs code.Much of the efivars code had to be rewritten to use this new API. For
instance, it is now up to the users of the API to build the initial
list of EFI variables in their efivar_init() callback function. The
variable list needs to be passed to efivar_init() which allows us to
keep work arounds for things like implementation bugs in
GetNextVariable() in a central location.Allowing users of the API to use a callback function to build the list
greatly benefits the efivarfs code which needs to allocate inodes and
dentries for every variable. It previously did this in a racy way
because the code ran without holding the variable spinlock. Both the
sysfs and efivarfs code maintain their own lists which means the two
interfaces can be running simultaneously without interference, though
it should be noted that because no synchronisation is performed it is
very easy to create inconsistencies. efibootmgr doesn't currently use
efivarfs and users are likely to also require the old sysfs interface,
so it makes sense to allow both to be built.Reviewed-by: Tom Gundersen
Tested-by: Tom Gundersen
Cc: Seiji Aguchi
Cc: Matthew Garrett
Cc: Jeremy Kerr
Cc: Tony Luck
Cc: Mike Waychison
Signed-off-by: Matt Fleming -
Some machines have an EFI variable interface that does not conform to
the UEFI specification, e.g. CONFIG_GOOGLE_SMI. Add the necessary code
so that it's only possible to use one implementation of EFI variable
operations at runtime. This allows us to keep a single (file-scope)
global pointer 'struct efivars', which simplifies access. This will
hopefully dissuade developers from accessing the generic operations
struct directly in the future, as was done in the efivarfs and pstore
code, thereby allowing future code to work with both the generic efivar
ops and the google SMI ops.This may seem like a step backwards in terms of modularity, but we don't
need to track more than one 'struct efivars' at one time. There is no
synchronisation done between multiple EFI variable operations, and
according to Mike no one is using both the generic EFI var ops and
CONFIG_GOOGLE_SMI simultaneously, though a single kernel build _does_
need to able to support both. It also helps to clearly highlight which
functions form the core of the efivars interface - those that require
access to __efivars.Reviewed-by: Tom Gundersen
Tested-by: Tom Gundersen
Acked-by: Mike Waychison
Signed-off-by: Matt Fleming -
There are currently two implementations of the utf16 string functions.
Somewhat confusingly, they've got different names.Centralise the functions in efi.h.
Reviewed-by: Tom Gundersen
Tested-by: Tom Gundersen
Reviewed-by: Mike Waychison
Signed-off-by: Matt Fleming
16 Apr, 2013
1 commit
-
We want to be able to use the utf16 functions that are currently present
in the EFI variables code in platform-specific code as well. Move them to
the kernel core, and in the process rename them to accurately describe what
they do - they don't handle UTF16, only UCS2.Signed-off-by: Matthew Garrett
Signed-off-by: Matt Fleming
09 Apr, 2013
1 commit
-
Let's not burden ia64 with checks in the common efivars code that we're not
writing too much data to the variable store. That kind of thing is an x86
firmware bug, plain and simple.efi_query_variable_store() provides platforms with a wrapper in which they can
perform checks and workarounds for EFI variable storage bugs.Cc: H. Peter Anvin
Cc: Matthew Garrett
Signed-off-by: Matt Fleming
23 Mar, 2013
1 commit
-
The 'CONFIG_' prefix is not implicit in IS_ENABLED().
Signed-off-by: Ben Hutchings
Cc: Seth Forshee
Cc:
Signed-off-by: Matt Fleming
21 Mar, 2013
4 commits
-
Some firmware exhibits a bug where the same VariableName and
VendorGuid values are returned on multiple invocations of
GetNextVariableName(). See,https://bugzilla.kernel.org/show_bug.cgi?id=47631
As a consequence of such a bug, Andre reports hitting the following
WARN_ON() in the sysfs code after updating the BIOS on his, "Gigabyte
Technology Co., Ltd. To be filled by O.E.M./Z77X-UD3H, BIOS F19e
11/21/2012)" machine,[ 0.581554] EFI Variables Facility v0.08 2004-May-17
[ 0.584914] ------------[ cut here ]------------
[ 0.585639] WARNING: at /home/andre/linux/fs/sysfs/dir.c:536 sysfs_add_one+0xd4/0x100()
[ 0.586381] Hardware name: To be filled by O.E.M.
[ 0.587123] sysfs: cannot create duplicate filename '/firmware/efi/vars/SbAslBufferPtrVar-01f33c25-764d-43ea-aeea-6b5a41f3f3e8'
[ 0.588694] Modules linked in:
[ 0.589484] Pid: 1, comm: swapper/0 Not tainted 3.8.0+ #7
[ 0.590280] Call Trace:
[ 0.591066] [] ? sysfs_add_one+0xd4/0x100
[ 0.591861] [] warn_slowpath_common+0x7f/0xc0
[ 0.592650] [] warn_slowpath_fmt+0x4c/0x50
[ 0.593429] [] ? strlcat+0x65/0x80
[ 0.594203] [] sysfs_add_one+0xd4/0x100
[ 0.594979] [] create_dir+0x78/0xd0
[ 0.595753] [] sysfs_create_dir+0x86/0xe0
[ 0.596532] [] kobject_add_internal+0x9c/0x220
[ 0.597310] [] kobject_init_and_add+0x67/0x90
[ 0.598083] [] ? efivar_create_sysfs_entry+0x61/0x1c0
[ 0.598859] [] efivar_create_sysfs_entry+0x11b/0x1c0
[ 0.599631] [] register_efivars+0xde/0x420
[ 0.600395] [] ? edd_init+0x2f5/0x2f5
[ 0.601150] [] efivars_init+0xb8/0x104
[ 0.601903] [] do_one_initcall+0x12a/0x180
[ 0.602659] [] kernel_init_freeable+0x13e/0x1c6
[ 0.603418] [] ? loglevel+0x31/0x31
[ 0.604183] [] ? rest_init+0x80/0x80
[ 0.604936] [] kernel_init+0xe/0xf0
[ 0.605681] [] ret_from_fork+0x7c/0xb0
[ 0.606414] [] ? rest_init+0x80/0x80
[ 0.607143] ---[ end trace 1609741ab737eb29 ]---There's not much we can do to work around and keep traversing the
variable list once we hit this firmware bug. Our only solution is to
terminate the loop because, as Lingzhu reports, some machines get
stuck when they encounter duplicate names,> I had an IBM System x3100 M4 and x3850 X5 on which kernel would
> get stuck in infinite loop creating duplicate sysfs files because,
> for some reason, there are several duplicate boot entries in nvram
> getting GetNextVariableName into a circle of iteration (with
> period > 2).Also disable the workqueue, as efivar_update_sysfs_entries() uses
GetNextVariableName() to figure out which variables have been created
since the last iteration. That algorithm isn't going to work if
GetNextVariableName() returns duplicates. Note that we don't disable
EFI variable creation completely on the affected machines, it's just
that any pstore dump-* files won't appear in sysfs until the next
boot.Reported-by: Andre Heider
Reported-by: Lingzhu Xiang
Tested-by: Lingzhu Xiang
Cc: Seiji Aguchi
Cc:
Signed-off-by: Matt Fleming -
It's not wise to assume VariableNameSize represents the length of
VariableName, as not all firmware updates VariableNameSize in the same
way (some don't update it at all if EFI_SUCCESS is returned). There
are even implementations out there that update VariableNameSize with
values that are both larger than the string returned in VariableName
and smaller than the buffer passed to GetNextVariableName(), which
resulted in the following bug report from Michael Schroeder,> On HP z220 system (firmware version 1.54), some EFI variables are
> incorrectly named :
>
> ls -d /sys/firmware/efi/vars/*8be4d* | grep -v -- -8be returns
> /sys/firmware/efi/vars/dbxDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
> /sys/firmware/efi/vars/KEKDefault-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
> /sys/firmware/efi/vars/SecureBoot-pport8be4df61-93ca-11d2-aa0d-00e098032b8c
> /sys/firmware/efi/vars/SetupMode-Information8be4df61-93ca-11d2-aa0d-00e098032b8cThe issue here is that because we blindly use VariableNameSize without
verifying its value, we can potentially read garbage values from the
buffer containing VariableName if VariableNameSize is larger than the
length of VariableName.Since VariableName is a string, we can calculate its size by searching
for the terminating NULL character.Reported-by: Frederic Crozat
Cc: Matthew Garrett
Cc: Josh Boyer
Cc: Michael Schroeder
Cc: Lee, Chun-Yi
Cc: Lingzhu Xiang
Cc: Seiji Aguchi
Signed-off-by: Matt Fleming -
We know that with some firmware implementations writing too much data to
UEFI variables can lead to bricking machines. Recent changes attempt to
address this issue, but for some it may still be prudent to avoid
writing large amounts of data until the solution has been proven on a
wide variety of hardware.Crash dumps or other data from pstore can potentially be a large data
source. Add a pstore_module parameter to efivars to allow disabling its
use as a backend for pstore. Also add a config option,
CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLE, to allow setting the default
value of this paramter to true (i.e. disabled by default).Signed-off-by: Seth Forshee
Cc: Josh Boyer
Cc: Matthew Garrett
Cc: Seiji Aguchi
Cc: Tony Luck
Cc:
Signed-off-by: Matt Fleming -
Add a new option, CONFIG_EFI_VARS_PSTORE, which can be set to N to
avoid using efivars as a backend to pstore, as some users may want to
compile out the code completely.Set the default to Y to maintain backwards compatability, since this
feature has always been enabled until now.Signed-off-by: Seth Forshee
Cc: Josh Boyer
Cc: Matthew Garrett
Cc: Seiji Aguchi
Cc: Tony Luck
Cc:
Signed-off-by: Matt Fleming
10 Mar, 2013
1 commit
-
Pull namespace bugfixes from Eric Biederman:
"This is three simple fixes against 3.9-rc1. I have tested each of
these fixes and verified they work correctly.The userns oops in key_change_session_keyring and the BUG_ON triggered
by proc_ns_follow_link were found by Dave Jones.I am including the enhancement for mount to only trigger requests of
filesystem modules here instead of delaying this for the 3.10 merge
window because it is both trivial and the kind of change that tends to
bit-rot if left untouched for two months."* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
proc: Use nd_jump_link in proc_ns_follow_link
fs: Limit sys_mount to only request filesystem modules (Part 2).
fs: Limit sys_mount to only request filesystem modules.
userns: Stop oopsing in key_change_session_keyring