summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2013-09-12firmware/dmi_scan: drop OOM messagesJean Delvare1-17/+6
As reported by Joe Perches: OOM messages generally aren't useful. dmi_alloc is either a trivial front-end to kzalloc, and kzalloc already does a dump_stack() when OOM, or for x86, dmi_alloc uses extend_brk which BUGs when unsuccessful. So we can remove all 6 such log messages in the dmi_scan driver, to shrink the binary size (by 528 bytes on x86_64.) Signed-off-by: Jean Delvare <jdelvare@suse.de> Reported-by: Joe Perches <joe@perches.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-12firmware/dmi_scan: constify stringsJean Delvare1-5/+5
Add const to all DMI string pointers where this is possible. This fixes a checkpatch warning. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Joe Perches <joe@perches.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-12firmware/dmi_scan: fix most checkpatch errors and warningsJean Delvare1-23/+24
Fix all errors and trivial warnings reported by checkpatch for file drivers/firmware/dmi_scan.c. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Joe Perches <joe@perches.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-12firmware/dmi_scan: drop obsolete commentJean Delvare1-5/+0
This comment predates the introduction of early_ioremap. Since then the missing calls to dmi_iounmap have been added by Ingo and Yinghai in commits 0d64484f7ea1 ("x86: fix DMI ioremap leak") and 3212bff370c2 ("x86: left over fix for leak of early_ioremp in dmi_scan") . That was over 5 years ago so it is about time to drop this now misleading comment. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Joe Perches <joe@perches.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-12drivers/firmware/google/gsmi.c: replace strict_strtoul() with kstrtoul()Jingoo Han1-1/+1
The use of strict_strtoul() is not preferred, because strict_strtoul() is obsolete. Thus, kstrtoul() should be used. Signed-off-by: Jingoo Han <jg1.han@samsung.com> Cc: Matt Fleming <matt.fleming@intel.com> Cc: Tom Gundersen <teg@jklm.no> Cc: Mike Waychison <mikew@google.com> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-09-04Merge tag 'please-pull-pstore' of ↵Linus Torvalds1-6/+21
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux Pull pstore changes from Tony Luck: "A big part of this is the addition of compression to the generic pstore layer so that all backends can use the pitiful amounts of storage they control more effectively. Three other small fixes/cleanups too. * tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux: pstore/ram: (really) fix undefined usage of rounddown_pow_of_two pstore/ram: Read and write to the 'compressed' flag of pstore efi-pstore: Read and write to the 'compressed' flag of pstore erst: Read and write to the 'compressed' flag of pstore powerpc/pseries: Read and write to the 'compressed' flag of pstore pstore: Add file extension to pstore file if compressed pstore: Add decompression support to pstore pstore: Introduce new argument 'compressed' in the read callback pstore: Add compression support to pstore pstore/Kconfig: Select ZLIB_DEFLATE and ZLIB_INFLATE when PSTORE is selected pstore: Add new argument 'compressed' in pstore write callback powerpc/pseries: Remove (de)compression in nvram with pstore enabled pstore: d_alloc_name() doesn't return an ERR_PTR acpi/apei/erst: Add missing iounmap() on error in erst_exec_move_data()
2013-09-03Merge tag 'driver-core-3.12-rc1' of ↵Linus Torvalds1-17/+2
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core patches from Greg KH: "Here's the big driver core pull request for 3.12-rc1. Lots of tiny changes here fixing up the way sysfs attributes are created, to try to make drivers simpler, and fix a whole class race conditions with creations of device attributes after the device was announced to userspace. All the various pieces are acked by the different subsystem maintainers" * tag 'driver-core-3.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (119 commits) firmware loader: fix pending_fw_head list corruption drivers/base/memory.c: introduce help macro to_memory_block dynamic debug: line queries failing due to uninitialized local variable sysfs: sysfs_create_groups returns a value. debugfs: provide debugfs_create_x64() when disabled rbd: convert bus code to use bus_groups firmware: dcdbas: use binary attribute groups sysfs: add sysfs_create/remove_groups for when SYSFS is not enabled driver core: add #include <linux/sysfs.h> to core files. HID: convert bus code to use dev_groups Input: serio: convert bus code to use drv_groups Input: gameport: convert bus code to use drv_groups driver core: firmware: use __ATTR_RW() driver core: core: use DEVICE_ATTR_RO driver core: bus: use DRIVER_ATTR_WO() driver core: create write-only attribute macros for devices and drivers sysfs: create __ATTR_WO() driver-core: platform: convert bus code to use dev_groups workqueue: convert bus code to use dev_groups MEI: convert bus code to use dev_groups ...
2013-08-28firmware: dcdbas: use binary attribute groupsGreg KH1-17/+2
The dcdbas code was "hand rolling" a binary attribute group, which the driver core now supports automatically. So remove the "create the files by hand" logic, and just set the proper field in the attribute group structure, saving lots of code and headache. Cc: Doug Warzecha <Douglas_Warzecha@dell.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> -- Doug, I can take this through my driver-core tree if you don't object. drivers/firmware/dcdbas.c | 19 ++----------------- 1 file changed, 2 insertions(+), 17 deletions(-)
2013-08-19efi-pstore: Read and write to the 'compressed' flag of pstoreAruna Balakrishnaiah1-4/+18
In pstore write, Efi will add a character 'C'(compressed) or D'(decompressed) in its header while writing to persistent store. In pstore read, read the header and update the 'compressed' flag accordingly. Signed-off-by: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-08-19pstore: Introduce new argument 'compressed' in the read callbackAruna Balakrishnaiah1-1/+2
Backends will set the flag 'compressed' after reading the log from persistent store to indicate the data being returned to pstore is compressed or not. Signed-off-by: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-08-19pstore: Add new argument 'compressed' in pstore write callbackAruna Balakrishnaiah1-1/+1
Addition of new argument 'compressed' in the write call back will help the backend to know if the data passed from pstore is compressed or not (In case where compression fails.). If compressed, the backend can add a tag indicating the data is compressed while writing to persistent store. Signed-off-by: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-08-01dmi_scan: add comments on dmi_present() and the loop in dmi_scan_machine()Ben Hutchings1-0/+14
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 <ben@decadent.org.uk> Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com> Cc: Jean Delvare <jdelvare@suse.de> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-11efivars: check for EFI_RUNTIME_SERVICESMatt Fleming1-0/+3
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 <dyoung@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-07-04Merge branch 'next' of ↵Linus Torvalds1-1/+1
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc 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 ...
2013-07-04Merge branch 'akpm' (updates from Andrew Morton)Linus Torvalds1-3/+9
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 <akpm@linux-foundation.org>: (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 ...
2013-07-04dmi: add support for exact DMI matches in addition to substring matchingJani Nikula1-3/+9
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 <jani.nikula@intel.com> Cc: <annndddrr@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Cornel Panceac <cpanceac@gmail.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-07-03Merge tag 'please-pull-pstore' of ↵Linus Torvalds1-3/+6
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux 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"
2013-07-01pstore: Pass header size in the pstore write callbackAruna Balakrishnaiah1-1/+1
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 <aruna@linux.vnet.ibm.com> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
2013-06-29efivars: If pstore_register fails, free unneeded pstore bufferLenny Szubowicz1-1/+5
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 <lszubowi@redhat.com> Reported-by: Naotaka Hamaguchi <n.hamaguchi@jp.fujitsu.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-06-18Merge 3.10-rc6 into driver-core-nextGreg Kroah-Hartman1-5/+3
We want these fixes here too. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-06-04efi, pstore: Cocci spatch "memdup.spatch"Thomas Meyer1-2/+1
Change a kmalloc() + memcpy() pair for a single kmemdup() call. Signed-off-by: Thomas Meyer <thomas@m3y3r.de> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Tony Luck <tony.luck@intel.com>
2013-06-04dell_rbu: Select CONFIG_FW_LOADER_USER_HELPER explicitlyTakashi Iwai1-0/+1
The usermode helper is mandatory for this driver. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2013-05-13efivar: fix oops in efivar_update_sysfs_entries() caused by memory reuseSeiji Aguchi1-5/+3
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: [<ffffffff8142f81f>] 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:[<ffffffff8142f81f>] [<ffffffff8142f81f>] 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: [<ffffffff81254371>] ? idr_get_empty_slot+0x131/0x240 [<ffffffff8125b6d2>] ? put_dec+0x72/0x90 [<ffffffff81158e40>] ? cache_alloc_refill+0x170/0x2f0 [<ffffffff81430420>] efivar_update_sysfs_entry+0x150/0x220 [<ffffffff8103dd29>] ? efi_call2+0x9/0x70 [<ffffffff8103d787>] ? virt_efi_get_next_variable+0x47/0x1b0 [<ffffffff8115a8df>] ? kmem_cache_alloc_trace+0x1af/0x1c0 [<ffffffff81430033>] efivar_init+0x2c3/0x380 [<ffffffff814302d0>] ? efivar_delete+0xd0/0xd0 [<ffffffff8143111f>] efivar_update_sysfs_entries+0x6f/0x90 [<ffffffff810605f3>] process_one_work+0x183/0x490 [<ffffffff81061780>] worker_thread+0x120/0x3a0 [<ffffffff81061660>] ? manage_workers+0x160/0x160 [<ffffffff8106752e>] kthread+0xce/0xe0 [<ffffffff81067460>] ? kthread_freezable_should_stop+0x70/0x70 [<ffffffff81543c5c>] ret_from_fork+0x7c/0xb0 [<ffffffff81067460>] ? 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 [<ffffffff8142f81f>] efivar_entry_find+0x14f/0x2d0 RSP <ffff88019413fa48> CR2: 0000000000000000 ---[ end trace ba4907d5c519d112 ]--- Cc: James Bottomley <James.Bottomley@HansenPartnership.com> Cc: Tomoki Sekiyama <tomoki.sekiyama@hds.com> Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-05-02Merge branch 'for-linus' of ↵Linus Torvalds2-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs 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 ...
2013-05-02Merge branch 'x86-efi-for-linus' of ↵Linus Torvalds10-2171/+2103
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip 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()
2013-05-01dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()Ben Hutchings1-43/+37
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 <ben@decadent.org.uk> Reported-by: Tim McGrath <tmhikaru@gmail.com> Tested-by: Tim Mcgrath <tmhikaru@gmail.com> Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com> Signed-off-by: Artem Savkov <artem.savkov@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-01dump_stack: implement arch-specific hardware description in task dumpsTejun Heo1-0/+13
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: [<ffffffff81c614dc>] dump_stack+0x19/0x1b [<ffffffff8108f500>] warn_slowpath_common+0x70/0xa0 [<ffffffff8108f54a>] warn_slowpath_null+0x1a/0x20 [<ffffffff8234a0c3>] 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 <tj@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: David S. Miller <davem@davemloft.net> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-05-01dmi: morph dmi_dump_ids() into dmi_format_ids() which formats into a bufferTejun Heo1-17/+27
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 <tj@kernel.org> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: David S. Miller <davem@davemloft.net> Cc: Fengguang Wu <fengguang.wu@intel.com> Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Mike Frysinger <vapier@gentoo.org> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30efi: remove "kfree(NULL)"Dan Carpenter1-3/+1
No need to free a NULL pointer. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-30efi: locking fix in efivar_entry_set_safe()Dan Carpenter1-3/+5
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 <dan.carpenter@oracle.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-30efi, pstore: Read data from variable store before memcpy()Matt Fleming2-23/+28
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 <seiji.aguchi@hds.com> Tested-by: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-30efi, pstore: Remove entry from list when erasingMatt Fleming1-0/+2
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: [<ffffffff8142ea0f>] __efivar_entry_iter+0xcf/0x120 PGD 19483f067 PUD 195426067 PMD 0 Oops: 0000 [#1] SMP [...] Call Trace: [<ffffffff81430ebf>] efi_pstore_erase+0xef/0x140 [<ffffffff81003138>] ? math_error+0x288/0x2d0 [<ffffffff811ea491>] pstore_unlink+0x41/0x60 [<ffffffff811741ff>] vfs_unlink+0x9f/0x110 [<ffffffff8117813b>] do_unlinkat+0x18b/0x280 [<ffffffff8116d7e6>] ? sys_newfstatat+0x36/0x50 [<ffffffff81178472>] sys_unlinkat+0x22/0x40 [<ffffffff81543282>] system_call_fastpath+0x16/0x1b Reported-by: Seiji Aguchi <seiji.aguchi@hds.com> Tested-by: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-30efi, pstore: Initialise 'entry' before iteratingMatt Fleming1-1/+1
Seiji reports hitting the following crash when erasing pstore dump variables, BUG: unable to handle kernel NULL pointer dereference at 0000000000000fa4 IP: [<ffffffff8142dadf>] __efivar_entry_iter+0x2f/0x120 PGD 18482a067 PUD 190724067 PMD 0 Oops: 0000 [#1] SMP [...] Call Trace: [<ffffffff8143001f>] efi_pstore_erase+0xdf/0x130 [<ffffffff81200038>] ? cap_socket_create+0x8/0x10 [<ffffffff811ea491>] pstore_unlink+0x41/0x60 [<ffffffff811741ff>] vfs_unlink+0x9f/0x110 [<ffffffff8117813b>] do_unlinkat+0x18b/0x280 [<ffffffff81178472>] sys_unlinkat+0x22/0x40 [<ffffffff81542402>] 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 <seiji.aguchi@hds.com> Tested-by: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Matthew Garrett <matthew.garrett@nebula.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-30Merge tag 'v3.9' into efi-for-tip2Matt Fleming5-35/+27
Resolve conflicts for Ingo. Conflicts: drivers/firmware/Kconfig drivers/firmware/efivars.c Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-30firmware, memmap: fix firmware_map_entry leakYasuaki Ishimatsu1-6/+3
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 leaks release_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 <isimatu.yasuaki@jp.fujitsu.com> Reviewed-by: Wanpeng Li <liwanp@linux.vnet.ibm.com> Reviewed-by: Tang Chen <tangchen@cn.fujitsu.com> Acked-by: Toshi Kani <toshi.kani@hp.com> Cc: Wen Congyang <wency@cn.fujitsu.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-29Include missing linux/magic.h inclusionsDavid Howells1-0/+1
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 <dhowells@redhat.com> cc: linux-efi@vger.kernel.org Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2013-04-26efivars: only check for duplicates on the registered listMatt Fleming1-5/+7
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/0x170 The 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 <walken@google.com> Tested-by: Michel Lespinasse <walken@google.com> Cc: Mike Waychison <mikew@google.com> Cc: Matthew Garrett <matthew.garrett@nebula.com> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-17efi: split efisubsystem from efivarsTom Gundersen5-758/+765
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 <seiji.aguchi@hds.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Cc: Kay Sievers <kay@vrfy.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Chun-Yi Lee <jlee@suse.com> Cc: Andy Whitcroft <apw@canonical.com> Cc: Tobias Powalowski <tpowa@archlinux.org> Signed-off-by: Tom Gundersen <teg@jklm.no> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-17efivarfs: Move to fs/efivarfsMatt Fleming1-496/+0
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 <matthew.garrett@nebula.com> Cc: Jeremy Kerr <jk@ozlabs.org> Reviewed-by: Tom Gundersen <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-17efivars: Move pstore code into the new EFI directoryMatt Fleming6-300/+301
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 <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Anton Vorontsov <cbouatmailru@gmail.com> Cc: Colin Cross <ccross@android.com> Cc: Kees Cook <keescook@chromium.org> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Tony Luck <tony.luck@intel.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-17efivars: efivar_entry APIMatt Fleming2-723/+1107
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 <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Jeremy Kerr <jk@ozlabs.org> Cc: Tony Luck <tony.luck@intel.com> Cc: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-17efivars: Keep a private global pointer to efivarsMatt Fleming1-34/+46
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 <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Acked-by: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-17efi: move utf16 string functions to efi.hMatt Fleming2-32/+4
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 <teg@jklm.no> Tested-by: Tom Gundersen <teg@jklm.no> Reviewed-by: Mike Waychison <mikew@google.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-16Move utf16 functions to kernel core and renameMatthew Garrett2-62/+19
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 <matthew.garrett@nebula.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-04-09x86, efivars: firmware bug workarounds should be in platform codeMatt Fleming1-15/+3
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 <hpa@zytor.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-03-23efivars: Fix check for CONFIG_EFI_VARS_PSTORE_DEFAULT_DISABLEBen Hutchings1-1/+1
The 'CONFIG_' prefix is not implicit in IS_ENABLED(). Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Seth Forshee <seth.forshee@canonical.com> Cc: <stable@vger.kernel.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-03-21efivars: Handle duplicate names from get_next_variable()Matt Fleming1-1/+47
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] [<ffffffff81208954>] ? sysfs_add_one+0xd4/0x100 [ 0.591861] [<ffffffff810587bf>] warn_slowpath_common+0x7f/0xc0 [ 0.592650] [<ffffffff810588bc>] warn_slowpath_fmt+0x4c/0x50 [ 0.593429] [<ffffffff8134dd85>] ? strlcat+0x65/0x80 [ 0.594203] [<ffffffff81208954>] sysfs_add_one+0xd4/0x100 [ 0.594979] [<ffffffff81208b78>] create_dir+0x78/0xd0 [ 0.595753] [<ffffffff81208ec6>] sysfs_create_dir+0x86/0xe0 [ 0.596532] [<ffffffff81347e4c>] kobject_add_internal+0x9c/0x220 [ 0.597310] [<ffffffff81348307>] kobject_init_and_add+0x67/0x90 [ 0.598083] [<ffffffff81584a71>] ? efivar_create_sysfs_entry+0x61/0x1c0 [ 0.598859] [<ffffffff81584b2b>] efivar_create_sysfs_entry+0x11b/0x1c0 [ 0.599631] [<ffffffff8158517e>] register_efivars+0xde/0x420 [ 0.600395] [<ffffffff81d430a7>] ? edd_init+0x2f5/0x2f5 [ 0.601150] [<ffffffff81d4315f>] efivars_init+0xb8/0x104 [ 0.601903] [<ffffffff8100215a>] do_one_initcall+0x12a/0x180 [ 0.602659] [<ffffffff81d05d80>] kernel_init_freeable+0x13e/0x1c6 [ 0.603418] [<ffffffff81d05586>] ? loglevel+0x31/0x31 [ 0.604183] [<ffffffff816a6530>] ? rest_init+0x80/0x80 [ 0.604936] [<ffffffff816a653e>] kernel_init+0xe/0xf0 [ 0.605681] [<ffffffff816ce7ec>] ret_from_fork+0x7c/0xb0 [ 0.606414] [<ffffffff816a6530>] ? 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 <a.heider@gmail.com> Reported-by: Lingzhu Xiang <lxiang@redhat.com> Tested-by: Lingzhu Xiang <lxiang@redhat.com> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: <stable@vger.kernel.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-03-21efivars: explicitly calculate length of VariableNameMatt Fleming1-1/+31
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-00e098032b8c The 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 <fcrozat@suse.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Michael Schroeder <mls@suse.com> Cc: Lee, Chun-Yi <jlee@suse.com> Cc: Lingzhu Xiang <lxiang@redhat.com> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-03-21efivars: Add module parameter to disable use as a pstore backendSeth Forshee2-1/+16
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 <seth.forshee@canonical.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Tony Luck <tony.luck@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-03-21efivars: Allow disabling use as a pstore backendSeth Forshee2-44/+29
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 <seth.forshee@canonical.com> Cc: Josh Boyer <jwboyer@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Cc: Tony Luck <tony.luck@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>