2005-04-17 06:20:36 +08:00
|
|
|
/*
|
2013-02-08 23:37:06 +08:00
|
|
|
* Originally from efivars.c
|
2005-04-17 06:20:36 +08:00
|
|
|
*
|
|
|
|
* Copyright (C) 2001,2003,2004 Dell <Matt_Domsch@dell.com>
|
|
|
|
* Copyright (C) 2004 Intel Corporation <matthew.e.tolentino@intel.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
*/
|
|
|
|
|
2006-01-12 04:17:46 +08:00
|
|
|
#include <linux/capability.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/errno.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/string.h>
|
|
|
|
#include <linux/smp.h>
|
|
|
|
#include <linux/efi.h>
|
|
|
|
#include <linux/sysfs.h>
|
|
|
|
#include <linux/device.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2013-02-01 03:02:03 +08:00
|
|
|
#include <linux/ctype.h>
|
2013-04-30 18:30:24 +08:00
|
|
|
#include <linux/ucs2_string.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-02-02 23:22:24 +08:00
|
|
|
/* Private pointer to registered efivars */
|
|
|
|
static struct efivars *__efivars;
|
2012-10-05 13:54:56 +08:00
|
|
|
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
static bool efivar_wq_enabled = true;
|
2013-02-08 23:37:06 +08:00
|
|
|
DECLARE_WORK(efivar_work, NULL);
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_work);
|
2013-02-13 05:04:41 +08:00
|
|
|
|
2012-05-01 04:11:30 +08:00
|
|
|
static bool
|
2014-03-17 18:57:00 +08:00
|
|
|
validate_device_path(efi_char16_t *var_name, int match, u8 *buffer,
|
2012-05-04 04:50:46 +08:00
|
|
|
unsigned long len)
|
2012-05-01 04:11:30 +08:00
|
|
|
{
|
|
|
|
struct efi_generic_dev_path *node;
|
|
|
|
int offset = 0;
|
|
|
|
|
|
|
|
node = (struct efi_generic_dev_path *)buffer;
|
|
|
|
|
2012-05-04 04:50:46 +08:00
|
|
|
if (len < sizeof(*node))
|
|
|
|
return false;
|
2012-05-01 04:11:30 +08:00
|
|
|
|
2012-05-04 04:50:46 +08:00
|
|
|
while (offset <= len - sizeof(*node) &&
|
|
|
|
node->length >= sizeof(*node) &&
|
|
|
|
node->length <= len - offset) {
|
|
|
|
offset += node->length;
|
2012-05-01 04:11:30 +08:00
|
|
|
|
|
|
|
if ((node->type == EFI_DEV_END_PATH ||
|
|
|
|
node->type == EFI_DEV_END_PATH2) &&
|
|
|
|
node->sub_type == EFI_DEV_END_ENTIRE)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
node = (struct efi_generic_dev_path *)(buffer + offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we're here then either node->length pointed past the end
|
|
|
|
* of the buffer or we reached the end of the buffer without
|
|
|
|
* finding a device path end node.
|
|
|
|
*/
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2014-03-17 18:57:00 +08:00
|
|
|
validate_boot_order(efi_char16_t *var_name, int match, u8 *buffer,
|
2012-05-04 04:50:46 +08:00
|
|
|
unsigned long len)
|
2012-05-01 04:11:30 +08:00
|
|
|
{
|
|
|
|
/* An array of 16-bit integers */
|
|
|
|
if ((len % 2) != 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2014-03-17 18:57:00 +08:00
|
|
|
validate_load_option(efi_char16_t *var_name, int match, u8 *buffer,
|
2012-05-04 04:50:46 +08:00
|
|
|
unsigned long len)
|
2012-05-01 04:11:30 +08:00
|
|
|
{
|
|
|
|
u16 filepathlength;
|
2012-05-04 04:50:46 +08:00
|
|
|
int i, desclength = 0, namelen;
|
|
|
|
|
2014-03-17 18:57:00 +08:00
|
|
|
namelen = ucs2_strnlen(var_name, EFI_VAR_NAME_LEN);
|
2012-05-01 04:11:30 +08:00
|
|
|
|
|
|
|
/* Either "Boot" or "Driver" followed by four digits of hex */
|
|
|
|
for (i = match; i < match+4; i++) {
|
2014-03-17 18:57:00 +08:00
|
|
|
if (var_name[i] > 127 ||
|
|
|
|
hex_to_bin(var_name[i] & 0xff) < 0)
|
2012-05-01 04:11:30 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2012-05-04 04:50:46 +08:00
|
|
|
/* Reject it if there's 4 digits of hex and then further content */
|
|
|
|
if (namelen > match + 4)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* A valid entry must be at least 8 bytes */
|
|
|
|
if (len < 8)
|
2012-05-01 04:11:30 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
filepathlength = buffer[4] | buffer[5] << 8;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* There's no stored length for the description, so it has to be
|
|
|
|
* found by hand
|
|
|
|
*/
|
2013-04-30 18:30:24 +08:00
|
|
|
desclength = ucs2_strsize((efi_char16_t *)(buffer + 6), len - 6) + 2;
|
2012-05-01 04:11:30 +08:00
|
|
|
|
|
|
|
/* Each boot entry must have a descriptor */
|
|
|
|
if (!desclength)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If the sum of the length of the description, the claimed filepath
|
|
|
|
* length and the original header are greater than the length of the
|
|
|
|
* variable, it's malformed
|
|
|
|
*/
|
|
|
|
if ((desclength + filepathlength + 6) > len)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* And, finally, check the filepath
|
|
|
|
*/
|
2014-03-17 18:57:00 +08:00
|
|
|
return validate_device_path(var_name, match, buffer + desclength + 6,
|
2012-05-01 04:11:30 +08:00
|
|
|
filepathlength);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2014-03-17 18:57:00 +08:00
|
|
|
validate_uint16(efi_char16_t *var_name, int match, u8 *buffer,
|
2012-05-04 04:50:46 +08:00
|
|
|
unsigned long len)
|
2012-05-01 04:11:30 +08:00
|
|
|
{
|
|
|
|
/* A single 16-bit integer */
|
|
|
|
if (len != 2)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2014-03-17 18:57:00 +08:00
|
|
|
validate_ascii_string(efi_char16_t *var_name, int match, u8 *buffer,
|
2012-05-04 04:50:46 +08:00
|
|
|
unsigned long len)
|
2012-05-01 04:11:30 +08:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < len; i++) {
|
|
|
|
if (buffer[i] > 127)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (buffer[i] == 0)
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct variable_validate {
|
|
|
|
char *name;
|
2014-03-17 18:57:00 +08:00
|
|
|
bool (*validate)(efi_char16_t *var_name, int match, u8 *data,
|
2012-05-04 04:50:46 +08:00
|
|
|
unsigned long len);
|
2012-05-01 04:11:30 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct variable_validate variable_validate[] = {
|
|
|
|
{ "BootNext", validate_uint16 },
|
|
|
|
{ "BootOrder", validate_boot_order },
|
|
|
|
{ "DriverOrder", validate_boot_order },
|
|
|
|
{ "Boot*", validate_load_option },
|
|
|
|
{ "Driver*", validate_load_option },
|
|
|
|
{ "ConIn", validate_device_path },
|
|
|
|
{ "ConInDev", validate_device_path },
|
|
|
|
{ "ConOut", validate_device_path },
|
|
|
|
{ "ConOutDev", validate_device_path },
|
|
|
|
{ "ErrOut", validate_device_path },
|
|
|
|
{ "ErrOutDev", validate_device_path },
|
|
|
|
{ "Timeout", validate_uint16 },
|
|
|
|
{ "Lang", validate_ascii_string },
|
|
|
|
{ "PlatformLang", validate_ascii_string },
|
|
|
|
{ "", NULL },
|
|
|
|
};
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
bool
|
2014-03-17 18:57:00 +08:00
|
|
|
efivar_validate(efi_char16_t *var_name, u8 *data, unsigned long len)
|
2012-05-01 04:11:30 +08:00
|
|
|
{
|
|
|
|
int i;
|
2014-03-17 18:57:00 +08:00
|
|
|
u16 *unicode_name = var_name;
|
2012-05-01 04:11:30 +08:00
|
|
|
|
|
|
|
for (i = 0; variable_validate[i].validate != NULL; i++) {
|
|
|
|
const char *name = variable_validate[i].name;
|
|
|
|
int match;
|
|
|
|
|
|
|
|
for (match = 0; ; match++) {
|
|
|
|
char c = name[match];
|
|
|
|
u16 u = unicode_name[match];
|
|
|
|
|
|
|
|
/* All special variables are plain ascii */
|
|
|
|
if (u > 127)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* Wildcard in the matching name means we've matched */
|
|
|
|
if (c == '*')
|
2014-03-17 18:57:00 +08:00
|
|
|
return variable_validate[i].validate(var_name,
|
2012-05-01 04:11:30 +08:00
|
|
|
match, data, len);
|
|
|
|
|
|
|
|
/* Case sensitive match */
|
|
|
|
if (c != u)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Reached the end of the string while matching */
|
|
|
|
if (!c)
|
2014-03-17 18:57:00 +08:00
|
|
|
return variable_validate[i].validate(var_name,
|
2012-05-01 04:11:30 +08:00
|
|
|
match, data, len);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
2013-02-04 04:16:40 +08:00
|
|
|
EXPORT_SYMBOL_GPL(efivar_validate);
|
2012-05-01 04:11:30 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static efi_status_t
|
2013-02-04 04:16:40 +08:00
|
|
|
check_var_size(u32 attributes, unsigned long size)
|
2013-03-03 08:40:17 +08:00
|
|
|
{
|
2013-02-04 04:16:40 +08:00
|
|
|
const struct efivar_operations *fops = __efivars->ops;
|
2013-03-03 08:40:17 +08:00
|
|
|
|
2013-04-30 18:30:24 +08:00
|
|
|
if (!fops->query_variable_store)
|
2013-03-03 08:40:17 +08:00
|
|
|
return EFI_UNSUPPORTED;
|
|
|
|
|
2013-04-30 18:30:24 +08:00
|
|
|
return fops->query_variable_store(attributes, size);
|
2013-03-03 08:40:17 +08:00
|
|
|
}
|
|
|
|
|
2012-10-16 22:58:07 +08:00
|
|
|
static int efi_status_to_err(efi_status_t status)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
|
|
|
switch (status) {
|
2013-02-04 04:16:40 +08:00
|
|
|
case EFI_SUCCESS:
|
|
|
|
err = 0;
|
|
|
|
break;
|
2012-10-16 22:58:07 +08:00
|
|
|
case EFI_INVALID_PARAMETER:
|
|
|
|
err = -EINVAL;
|
|
|
|
break;
|
|
|
|
case EFI_OUT_OF_RESOURCES:
|
|
|
|
err = -ENOSPC;
|
|
|
|
break;
|
|
|
|
case EFI_DEVICE_ERROR:
|
|
|
|
err = -EIO;
|
|
|
|
break;
|
|
|
|
case EFI_WRITE_PROTECTED:
|
|
|
|
err = -EROFS;
|
|
|
|
break;
|
|
|
|
case EFI_SECURITY_VIOLATION:
|
|
|
|
err = -EACCES;
|
|
|
|
break;
|
|
|
|
case EFI_NOT_FOUND:
|
2013-02-04 04:16:40 +08:00
|
|
|
err = -ENOENT;
|
2012-10-16 22:58:07 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
err = -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
static bool variable_is_present(efi_char16_t *variable_name, efi_guid_t *vendor,
|
|
|
|
struct list_head *head)
|
2013-02-13 05:04:41 +08:00
|
|
|
{
|
|
|
|
struct efivar_entry *entry, *n;
|
|
|
|
unsigned long strsize1, strsize2;
|
|
|
|
bool found = false;
|
|
|
|
|
2013-04-30 18:30:24 +08:00
|
|
|
strsize1 = ucs2_strsize(variable_name, 1024);
|
2013-02-04 04:16:40 +08:00
|
|
|
list_for_each_entry_safe(entry, n, head, list) {
|
2013-04-30 18:30:24 +08:00
|
|
|
strsize2 = ucs2_strsize(entry->var.VariableName, 1024);
|
2013-02-13 05:04:41 +08:00
|
|
|
if (strsize1 == strsize2 &&
|
|
|
|
!memcmp(variable_name, &(entry->var.VariableName),
|
|
|
|
strsize2) &&
|
|
|
|
!efi_guidcmp(entry->var.VendorGuid,
|
|
|
|
*vendor)) {
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return found;
|
|
|
|
}
|
|
|
|
|
2013-03-01 22:49:12 +08:00
|
|
|
/*
|
|
|
|
* Returns the size of variable_name, in bytes, including the
|
|
|
|
* terminating NULL character, or variable_name_size if no NULL
|
|
|
|
* character is found among the first variable_name_size bytes.
|
|
|
|
*/
|
|
|
|
static unsigned long var_name_strnsize(efi_char16_t *variable_name,
|
|
|
|
unsigned long variable_name_size)
|
|
|
|
{
|
|
|
|
unsigned long len;
|
|
|
|
efi_char16_t c;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The variable name is, by definition, a NULL-terminated
|
|
|
|
* string, so make absolutely sure that variable_name_size is
|
|
|
|
* the value we expect it to be. If not, return the real size.
|
|
|
|
*/
|
|
|
|
for (len = 2; len <= variable_name_size; len += sizeof(c)) {
|
|
|
|
c = variable_name[(len / sizeof(c)) - 1];
|
|
|
|
if (!c)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return min(len, variable_name_size);
|
|
|
|
}
|
|
|
|
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
/*
|
|
|
|
* Print a warning when duplicate EFI variables are encountered and
|
|
|
|
* disable the sysfs workqueue since the firmware is buggy.
|
|
|
|
*/
|
2014-09-06 21:02:53 +08:00
|
|
|
static void dup_variable_bug(efi_char16_t *str16, efi_guid_t *vendor_guid,
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
unsigned long len16)
|
|
|
|
{
|
|
|
|
size_t i, len8 = len16 / sizeof(efi_char16_t);
|
2014-09-06 21:02:53 +08:00
|
|
|
char *str8;
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Disable the workqueue since the algorithm it uses for
|
|
|
|
* detecting new variables won't work with this buggy
|
|
|
|
* implementation of GetNextVariableName().
|
|
|
|
*/
|
|
|
|
efivar_wq_enabled = false;
|
|
|
|
|
2014-09-06 21:02:53 +08:00
|
|
|
str8 = kzalloc(len8, GFP_KERNEL);
|
|
|
|
if (!str8)
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
for (i = 0; i < len8; i++)
|
2014-09-06 21:02:53 +08:00
|
|
|
str8[i] = str16[i];
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
|
|
|
|
printk(KERN_WARNING "efivars: duplicate variable: %s-%pUl\n",
|
2014-09-06 21:02:53 +08:00
|
|
|
str8, vendor_guid);
|
|
|
|
kfree(str8);
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
}
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
/**
|
|
|
|
* efivar_init - build the initial list of EFI variables
|
|
|
|
* @func: callback function to invoke for every variable
|
|
|
|
* @data: function-specific data to pass to @func
|
|
|
|
* @atomic: do we need to execute the @func-loop atomically?
|
|
|
|
* @duplicates: error if we encounter duplicates on @head?
|
|
|
|
* @head: initialised head of variable list
|
|
|
|
*
|
|
|
|
* Get every EFI variable from the firmware and invoke @func. @func
|
|
|
|
* should call efivar_entry_add() to build the list of variables.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, or a kernel error code on failure.
|
|
|
|
*/
|
|
|
|
int efivar_init(int (*func)(efi_char16_t *, efi_guid_t, unsigned long, void *),
|
|
|
|
void *data, bool atomic, bool duplicates,
|
|
|
|
struct list_head *head)
|
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
unsigned long variable_name_size = 1024;
|
|
|
|
efi_char16_t *variable_name;
|
|
|
|
efi_status_t status;
|
|
|
|
efi_guid_t vendor_guid;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
variable_name = kzalloc(variable_name_size, GFP_KERNEL);
|
|
|
|
if (!variable_name) {
|
|
|
|
printk(KERN_ERR "efivars: Memory allocation failed.\n");
|
|
|
|
return -ENOMEM;
|
2012-10-05 13:54:56 +08:00
|
|
|
}
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Per EFI spec, the maximum storage allocated for both
|
|
|
|
* the variable name and variable data is 1024 bytes.
|
|
|
|
*/
|
|
|
|
|
|
|
|
do {
|
|
|
|
variable_name_size = 1024;
|
|
|
|
|
2011-03-12 09:43:21 +08:00
|
|
|
status = ops->get_next_variable(&variable_name_size,
|
2005-04-17 06:20:36 +08:00
|
|
|
variable_name,
|
|
|
|
&vendor_guid);
|
|
|
|
switch (status) {
|
|
|
|
case EFI_SUCCESS:
|
2013-02-04 04:16:40 +08:00
|
|
|
if (!atomic)
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
|
2013-03-01 22:49:12 +08:00
|
|
|
variable_name_size = var_name_strnsize(variable_name,
|
|
|
|
variable_name_size);
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Some firmware implementations return the
|
|
|
|
* same variable name on multiple calls to
|
|
|
|
* get_next_variable(). Terminate the loop
|
|
|
|
* immediately as there is no guarantee that
|
|
|
|
* we'll ever see a different variable name,
|
|
|
|
* and may end up looping here forever.
|
|
|
|
*/
|
2013-02-04 04:16:40 +08:00
|
|
|
if (duplicates &&
|
|
|
|
variable_is_present(variable_name, &vendor_guid, head)) {
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
dup_variable_bug(variable_name, &vendor_guid,
|
|
|
|
variable_name_size);
|
2013-02-04 04:16:40 +08:00
|
|
|
if (!atomic)
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
|
efivars: Handle duplicate names from get_next_variable()
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-07 19:59:14 +08:00
|
|
|
status = EFI_NOT_FOUND;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
err = func(variable_name, vendor_guid, variable_name_size, data);
|
|
|
|
if (err)
|
|
|
|
status = EFI_NOT_FOUND;
|
|
|
|
|
|
|
|
if (!atomic)
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
break;
|
|
|
|
case EFI_NOT_FOUND:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
printk(KERN_WARNING "efivars: get_next_variable: status=%lx\n",
|
|
|
|
status);
|
|
|
|
status = EFI_NOT_FOUND;
|
|
|
|
break;
|
|
|
|
}
|
2013-02-04 04:16:40 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
} while (status != EFI_NOT_FOUND);
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
|
|
|
|
kfree(variable_name);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_init);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_add - add entry to variable list
|
|
|
|
* @entry: entry to add to list
|
|
|
|
* @head: list head
|
|
|
|
*/
|
|
|
|
void efivar_entry_add(struct efivar_entry *entry, struct list_head *head)
|
|
|
|
{
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
list_add(&entry->list, head);
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_add);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_remove - remove entry from variable list
|
|
|
|
* @entry: entry to remove from list
|
|
|
|
*/
|
|
|
|
void efivar_entry_remove(struct efivar_entry *entry)
|
|
|
|
{
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
list_del(&entry->list);
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_remove);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* efivar_entry_list_del_unlock - remove entry from variable list
|
|
|
|
* @entry: entry to remove
|
|
|
|
*
|
|
|
|
* Remove @entry from the variable list and release the list lock.
|
|
|
|
*
|
|
|
|
* NOTE: slightly weird locking semantics here - we expect to be
|
|
|
|
* called with the efivars lock already held, and we release it before
|
|
|
|
* returning. This is because this function is usually called after
|
|
|
|
* set_variable() while the lock is still held.
|
|
|
|
*/
|
|
|
|
static void efivar_entry_list_del_unlock(struct efivar_entry *entry)
|
|
|
|
{
|
2014-08-14 02:21:34 +08:00
|
|
|
lockdep_assert_held(&__efivars->lock);
|
2013-02-04 04:16:40 +08:00
|
|
|
|
|
|
|
list_del(&entry->list);
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __efivar_entry_delete - delete an EFI variable
|
|
|
|
* @entry: entry containing EFI variable to delete
|
|
|
|
*
|
2013-02-08 23:37:06 +08:00
|
|
|
* Delete the variable from the firmware but leave @entry on the
|
|
|
|
* variable list.
|
2013-02-04 04:16:40 +08:00
|
|
|
*
|
2013-02-08 23:37:06 +08:00
|
|
|
* This function differs from efivar_entry_delete() because it does
|
|
|
|
* not remove @entry from the variable list. Also, it is safe to be
|
|
|
|
* called from within a efivar_entry_iter_begin() and
|
2013-02-04 04:16:40 +08:00
|
|
|
* efivar_entry_iter_end() region, unlike efivar_entry_delete().
|
|
|
|
*
|
|
|
|
* Returns 0 on success, or a converted EFI status code if
|
2013-02-08 23:37:06 +08:00
|
|
|
* set_variable() fails.
|
2013-02-04 04:16:40 +08:00
|
|
|
*/
|
|
|
|
int __efivar_entry_delete(struct efivar_entry *entry)
|
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
efi_status_t status;
|
|
|
|
|
2014-08-14 02:21:34 +08:00
|
|
|
lockdep_assert_held(&__efivars->lock);
|
2013-02-04 04:16:40 +08:00
|
|
|
|
|
|
|
status = ops->set_variable(entry->var.VariableName,
|
|
|
|
&entry->var.VendorGuid,
|
|
|
|
0, 0, NULL);
|
|
|
|
|
2013-02-08 23:37:06 +08:00
|
|
|
return efi_status_to_err(status);
|
2013-02-04 04:16:40 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__efivar_entry_delete);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_delete - delete variable and remove entry from list
|
|
|
|
* @entry: entry containing variable to delete
|
|
|
|
*
|
|
|
|
* Delete the variable from the firmware and remove @entry from the
|
|
|
|
* variable list. It is the caller's responsibility to free @entry
|
|
|
|
* once we return.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, or a converted EFI status code if
|
|
|
|
* set_variable() fails.
|
|
|
|
*/
|
|
|
|
int efivar_entry_delete(struct efivar_entry *entry)
|
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
status = ops->set_variable(entry->var.VariableName,
|
|
|
|
&entry->var.VendorGuid,
|
|
|
|
0, 0, NULL);
|
|
|
|
if (!(status == EFI_SUCCESS || status == EFI_NOT_FOUND)) {
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
return efi_status_to_err(status);
|
|
|
|
}
|
|
|
|
|
|
|
|
efivar_entry_list_del_unlock(entry);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_delete);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_set - call set_variable()
|
|
|
|
* @entry: entry containing the EFI variable to write
|
|
|
|
* @attributes: variable attributes
|
|
|
|
* @size: size of @data buffer
|
|
|
|
* @data: buffer containing variable data
|
|
|
|
* @head: head of variable list
|
|
|
|
*
|
|
|
|
* Calls set_variable() for an EFI variable. If creating a new EFI
|
|
|
|
* variable, this function is usually followed by efivar_entry_add().
|
|
|
|
*
|
|
|
|
* Before writing the variable, the remaining EFI variable storage
|
|
|
|
* space is checked to ensure there is enough room available.
|
|
|
|
*
|
|
|
|
* If @head is not NULL a lookup is performed to determine whether
|
|
|
|
* the entry is already on the list.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -EEXIST if a lookup is performed and the entry
|
|
|
|
* already exists on the list, or a converted EFI status code if
|
|
|
|
* set_variable() fails.
|
|
|
|
*/
|
|
|
|
int efivar_entry_set(struct efivar_entry *entry, u32 attributes,
|
|
|
|
unsigned long size, void *data, struct list_head *head)
|
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
efi_status_t status;
|
|
|
|
efi_char16_t *name = entry->var.VariableName;
|
|
|
|
efi_guid_t vendor = entry->var.VendorGuid;
|
|
|
|
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
|
|
|
|
if (head && efivar_entry_find(name, vendor, head, false)) {
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
return -EEXIST;
|
|
|
|
}
|
|
|
|
|
2013-04-30 18:30:24 +08:00
|
|
|
status = check_var_size(attributes, size + ucs2_strsize(name, 1024));
|
2013-02-04 04:16:40 +08:00
|
|
|
if (status == EFI_SUCCESS || status == EFI_UNSUPPORTED)
|
|
|
|
status = ops->set_variable(name, &vendor,
|
|
|
|
attributes, size, data);
|
|
|
|
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
|
|
|
|
return efi_status_to_err(status);
|
2013-02-08 23:37:06 +08:00
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_set);
|
|
|
|
|
2014-10-01 04:58:52 +08:00
|
|
|
/*
|
|
|
|
* efivar_entry_set_nonblocking - call set_variable_nonblocking()
|
|
|
|
*
|
|
|
|
* This function is guaranteed to not block and is suitable for calling
|
|
|
|
* from crash/panic handlers.
|
|
|
|
*
|
|
|
|
* Crucially, this function will not block if it cannot acquire
|
|
|
|
* __efivars->lock. Instead, it returns -EBUSY.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
efivar_entry_set_nonblocking(efi_char16_t *name, efi_guid_t vendor,
|
|
|
|
u32 attributes, unsigned long size, void *data)
|
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
unsigned long flags;
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
if (!spin_trylock_irqsave(&__efivars->lock, flags))
|
|
|
|
return -EBUSY;
|
|
|
|
|
|
|
|
status = check_var_size(attributes, size + ucs2_strsize(name, 1024));
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
spin_unlock_irqrestore(&__efivars->lock, flags);
|
|
|
|
return -ENOSPC;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = ops->set_variable_nonblocking(name, &vendor, attributes,
|
|
|
|
size, data);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&__efivars->lock, flags);
|
|
|
|
return efi_status_to_err(status);
|
|
|
|
}
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
/**
|
|
|
|
* efivar_entry_set_safe - call set_variable() if enough space in firmware
|
|
|
|
* @name: buffer containing the variable name
|
|
|
|
* @vendor: variable vendor guid
|
|
|
|
* @attributes: variable attributes
|
|
|
|
* @block: can we block in this context?
|
|
|
|
* @size: size of @data buffer
|
|
|
|
* @data: buffer containing variable data
|
|
|
|
*
|
|
|
|
* Ensures there is enough free storage in the firmware for this variable, and
|
|
|
|
* if so, calls set_variable(). If creating a new EFI variable, this function
|
|
|
|
* is usually followed by efivar_entry_add().
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -ENOSPC if the firmware does not have enough
|
|
|
|
* space for set_variable() to succeed, or a converted EFI status code
|
|
|
|
* if set_variable() fails.
|
|
|
|
*/
|
|
|
|
int efivar_entry_set_safe(efi_char16_t *name, efi_guid_t vendor, u32 attributes,
|
|
|
|
bool block, unsigned long size, void *data)
|
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
unsigned long flags;
|
|
|
|
efi_status_t status;
|
|
|
|
|
2013-04-30 18:30:24 +08:00
|
|
|
if (!ops->query_variable_store)
|
2013-02-04 04:16:40 +08:00
|
|
|
return -ENOSYS;
|
|
|
|
|
2014-10-01 04:58:52 +08:00
|
|
|
/*
|
|
|
|
* If the EFI variable backend provides a non-blocking
|
|
|
|
* ->set_variable() operation and we're in a context where we
|
|
|
|
* cannot block, then we need to use it to avoid live-locks,
|
|
|
|
* since the implication is that the regular ->set_variable()
|
|
|
|
* will block.
|
|
|
|
*
|
|
|
|
* If no ->set_variable_nonblocking() is provided then
|
|
|
|
* ->set_variable() is assumed to be non-blocking.
|
|
|
|
*/
|
|
|
|
if (!block && ops->set_variable_nonblocking)
|
|
|
|
return efivar_entry_set_nonblocking(name, vendor, attributes,
|
|
|
|
size, data);
|
|
|
|
|
2013-04-30 15:43:12 +08:00
|
|
|
if (!block) {
|
|
|
|
if (!spin_trylock_irqsave(&__efivars->lock, flags))
|
|
|
|
return -EBUSY;
|
|
|
|
} else {
|
2013-02-04 04:16:40 +08:00
|
|
|
spin_lock_irqsave(&__efivars->lock, flags);
|
2013-04-30 15:43:12 +08:00
|
|
|
}
|
2013-02-04 04:16:40 +08:00
|
|
|
|
2013-04-30 18:30:24 +08:00
|
|
|
status = check_var_size(attributes, size + ucs2_strsize(name, 1024));
|
2013-02-04 04:16:40 +08:00
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
spin_unlock_irqrestore(&__efivars->lock, flags);
|
|
|
|
return -ENOSPC;
|
|
|
|
}
|
|
|
|
|
|
|
|
status = ops->set_variable(name, &vendor, attributes, size, data);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&__efivars->lock, flags);
|
|
|
|
|
|
|
|
return efi_status_to_err(status);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_set_safe);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_find - search for an entry
|
|
|
|
* @name: the EFI variable name
|
|
|
|
* @guid: the EFI variable vendor's guid
|
|
|
|
* @head: head of the variable list
|
|
|
|
* @remove: should we remove the entry from the list?
|
|
|
|
*
|
|
|
|
* Search for an entry on the variable list that has the EFI variable
|
|
|
|
* name @name and vendor guid @guid. If an entry is found on the list
|
|
|
|
* and @remove is true, the entry is removed from the list.
|
|
|
|
*
|
|
|
|
* The caller MUST call efivar_entry_iter_begin() and
|
|
|
|
* efivar_entry_iter_end() before and after the invocation of this
|
|
|
|
* function, respectively.
|
|
|
|
*
|
|
|
|
* Returns the entry if found on the list, %NULL otherwise.
|
|
|
|
*/
|
|
|
|
struct efivar_entry *efivar_entry_find(efi_char16_t *name, efi_guid_t guid,
|
|
|
|
struct list_head *head, bool remove)
|
|
|
|
{
|
|
|
|
struct efivar_entry *entry, *n;
|
|
|
|
int strsize1, strsize2;
|
|
|
|
bool found = false;
|
|
|
|
|
2014-08-14 02:21:34 +08:00
|
|
|
lockdep_assert_held(&__efivars->lock);
|
2013-02-04 04:16:40 +08:00
|
|
|
|
|
|
|
list_for_each_entry_safe(entry, n, head, list) {
|
2013-04-30 18:30:24 +08:00
|
|
|
strsize1 = ucs2_strsize(name, 1024);
|
|
|
|
strsize2 = ucs2_strsize(entry->var.VariableName, 1024);
|
2013-02-04 04:16:40 +08:00
|
|
|
if (strsize1 == strsize2 &&
|
|
|
|
!memcmp(name, &(entry->var.VariableName), strsize1) &&
|
|
|
|
!efi_guidcmp(guid, entry->var.VendorGuid)) {
|
|
|
|
found = true;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!found)
|
|
|
|
return NULL;
|
|
|
|
|
efivars, efi-pstore: Hold off deletion of sysfs entry until the scan is completed
Currently, when mounting pstore file system, a read callback of
efi_pstore driver runs mutiple times as below.
- In the first read callback, scan efivar_sysfs_list from head and pass
a kmsg buffer of a entry to an upper pstore layer.
- In the second read callback, rescan efivar_sysfs_list from the entry
and pass another kmsg buffer to it.
- Repeat the scan and pass until the end of efivar_sysfs_list.
In this process, an entry is read across the multiple read function
calls. To avoid race between the read and erasion, the whole process
above is protected by a spinlock, holding in open() and releasing in
close().
At the same time, kmemdup() is called to pass the buffer to pstore
filesystem during it. And then, it causes a following lockdep warning.
To make the dynamic memory allocation runnable without taking spinlock,
holding off a deletion of sysfs entry if it happens while scanning it
via efi_pstore, and deleting it after the scan is completed.
To implement it, this patch introduces two flags, scanning and deleting,
to efivar_entry.
On the code basis, it seems that all the scanning and deleting logic is
not needed because __efivars->lock are not dropped when reading from the
EFI variable store.
But, the scanning and deleting logic is still needed because an
efi-pstore and a pstore filesystem works as follows.
In case an entry(A) is found, the pointer is saved to psi->data. And
efi_pstore_read() passes the entry(A) to a pstore filesystem by
releasing __efivars->lock.
And then, the pstore filesystem calls efi_pstore_read() again and the
same entry(A), which is saved to psi->data, is used for resuming to scan
a sysfs-list.
So, to protect the entry(A), the logic is needed.
[ 1.143710] ------------[ cut here ]------------
[ 1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740 lockdep_trace_alloc+0x104/0x110()
[ 1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[ 1.144058] Modules linked in:
[ 1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2
[ 1.144058] 0000000000000009 ffff8800797e9ae0 ffffffff816614a5 ffff8800797e9b28
[ 1.144058] ffff8800797e9b18 ffffffff8105510d 0000000000000080 0000000000000046
[ 1.144058] 00000000000000d0 00000000000003af ffffffff81ccd0c0 ffff8800797e9b78
[ 1.144058] Call Trace:
[ 1.144058] [<ffffffff816614a5>] dump_stack+0x54/0x74
[ 1.144058] [<ffffffff8105510d>] warn_slowpath_common+0x7d/0xa0
[ 1.144058] [<ffffffff8105517c>] warn_slowpath_fmt+0x4c/0x50
[ 1.144058] [<ffffffff8131290f>] ? vsscanf+0x57f/0x7b0
[ 1.144058] [<ffffffff810bbd74>] lockdep_trace_alloc+0x104/0x110
[ 1.144058] [<ffffffff81192da0>] __kmalloc_track_caller+0x50/0x280
[ 1.144058] [<ffffffff815147bb>] ? efi_pstore_read_func.part.1+0x12b/0x170
[ 1.144058] [<ffffffff8115b260>] kmemdup+0x20/0x50
[ 1.144058] [<ffffffff815147bb>] efi_pstore_read_func.part.1+0x12b/0x170
[ 1.144058] [<ffffffff81514800>] ? efi_pstore_read_func.part.1+0x170/0x170
[ 1.144058] [<ffffffff815148b4>] efi_pstore_read_func+0xb4/0xe0
[ 1.144058] [<ffffffff81512b7b>] __efivar_entry_iter+0xfb/0x120
[ 1.144058] [<ffffffff8151428f>] efi_pstore_read+0x3f/0x50
[ 1.144058] [<ffffffff8128d7ba>] pstore_get_records+0x9a/0x150
[ 1.158207] [<ffffffff812af25c>] ? selinux_d_instantiate+0x1c/0x20
[ 1.158207] [<ffffffff8128ce30>] ? parse_options+0x80/0x80
[ 1.158207] [<ffffffff8128ced5>] pstore_fill_super+0xa5/0xc0
[ 1.158207] [<ffffffff811ae7d2>] mount_single+0xa2/0xd0
[ 1.158207] [<ffffffff8128ccf8>] pstore_mount+0x18/0x20
[ 1.158207] [<ffffffff811ae8b9>] mount_fs+0x39/0x1b0
[ 1.158207] [<ffffffff81160550>] ? __alloc_percpu+0x10/0x20
[ 1.158207] [<ffffffff811c9493>] vfs_kern_mount+0x63/0xf0
[ 1.158207] [<ffffffff811cbb0e>] do_mount+0x23e/0xa20
[ 1.158207] [<ffffffff8115b51b>] ? strndup_user+0x4b/0xf0
[ 1.158207] [<ffffffff811cc373>] SyS_mount+0x83/0xc0
[ 1.158207] [<ffffffff81673cc2>] system_call_fastpath+0x16/0x1b
[ 1.158207] ---[ end trace 61981bc62de9f6f4 ]---
Signed-off-by: Seiji Aguchi <seiji.aguchi@hds.com>
Tested-by: Madper Xie <cxie@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2013-10-31 03:27:26 +08:00
|
|
|
if (remove) {
|
|
|
|
if (entry->scanning) {
|
|
|
|
/*
|
|
|
|
* The entry will be deleted
|
|
|
|
* after scanning is completed.
|
|
|
|
*/
|
|
|
|
entry->deleting = true;
|
|
|
|
} else
|
|
|
|
list_del(&entry->list);
|
|
|
|
}
|
2013-02-04 04:16:40 +08:00
|
|
|
|
|
|
|
return entry;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_find);
|
|
|
|
|
|
|
|
/**
|
2013-04-30 03:08:02 +08:00
|
|
|
* efivar_entry_size - obtain the size of a variable
|
2013-02-04 04:16:40 +08:00
|
|
|
* @entry: entry for this variable
|
|
|
|
* @size: location to store the variable's size
|
|
|
|
*/
|
2013-04-30 03:08:02 +08:00
|
|
|
int efivar_entry_size(struct efivar_entry *entry, unsigned long *size)
|
2013-02-04 04:16:40 +08:00
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
*size = 0;
|
2013-04-30 03:08:02 +08:00
|
|
|
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
2013-02-04 04:16:40 +08:00
|
|
|
status = ops->get_variable(entry->var.VariableName,
|
|
|
|
&entry->var.VendorGuid, NULL, size, NULL);
|
2013-04-30 03:08:02 +08:00
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
if (status != EFI_BUFFER_TOO_SMALL)
|
|
|
|
return efi_status_to_err(status);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2013-04-30 03:08:02 +08:00
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_size);
|
2013-02-04 04:16:40 +08:00
|
|
|
|
|
|
|
/**
|
2013-04-30 03:08:02 +08:00
|
|
|
* __efivar_entry_get - call get_variable()
|
|
|
|
* @entry: read data for this variable
|
|
|
|
* @attributes: variable attributes
|
|
|
|
* @size: size of @data buffer
|
|
|
|
* @data: buffer to store variable data
|
|
|
|
*
|
|
|
|
* The caller MUST call efivar_entry_iter_begin() and
|
|
|
|
* efivar_entry_iter_end() before and after the invocation of this
|
|
|
|
* function, respectively.
|
2013-02-04 04:16:40 +08:00
|
|
|
*/
|
2013-04-30 03:08:02 +08:00
|
|
|
int __efivar_entry_get(struct efivar_entry *entry, u32 *attributes,
|
|
|
|
unsigned long *size, void *data)
|
2013-02-04 04:16:40 +08:00
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
efi_status_t status;
|
|
|
|
|
2014-08-14 02:21:34 +08:00
|
|
|
lockdep_assert_held(&__efivars->lock);
|
2013-02-04 04:16:40 +08:00
|
|
|
|
|
|
|
status = ops->get_variable(entry->var.VariableName,
|
2013-04-30 03:08:02 +08:00
|
|
|
&entry->var.VendorGuid,
|
|
|
|
attributes, size, data);
|
2013-02-04 04:16:40 +08:00
|
|
|
|
2013-04-30 03:08:02 +08:00
|
|
|
return efi_status_to_err(status);
|
2013-02-04 04:16:40 +08:00
|
|
|
}
|
2013-04-30 03:08:02 +08:00
|
|
|
EXPORT_SYMBOL_GPL(__efivar_entry_get);
|
2013-02-04 04:16:40 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_get - call get_variable()
|
|
|
|
* @entry: read data for this variable
|
|
|
|
* @attributes: variable attributes
|
|
|
|
* @size: size of @data buffer
|
|
|
|
* @data: buffer to store variable data
|
|
|
|
*/
|
|
|
|
int efivar_entry_get(struct efivar_entry *entry, u32 *attributes,
|
|
|
|
unsigned long *size, void *data)
|
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
efi_status_t status;
|
|
|
|
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
status = ops->get_variable(entry->var.VariableName,
|
|
|
|
&entry->var.VendorGuid,
|
|
|
|
attributes, size, data);
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
|
|
|
|
return efi_status_to_err(status);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_get);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_set_get_size - call set_variable() and get new size (atomic)
|
|
|
|
* @entry: entry containing variable to set and get
|
|
|
|
* @attributes: attributes of variable to be written
|
|
|
|
* @size: size of data buffer
|
|
|
|
* @data: buffer containing data to write
|
|
|
|
* @set: did the set_variable() call succeed?
|
|
|
|
*
|
|
|
|
* This is a pretty special (complex) function. See efivarfs_file_write().
|
|
|
|
*
|
|
|
|
* Atomically call set_variable() for @entry and if the call is
|
|
|
|
* successful, return the new size of the variable from get_variable()
|
|
|
|
* in @size. The success of set_variable() is indicated by @set.
|
|
|
|
*
|
|
|
|
* Returns 0 on success, -EINVAL if the variable data is invalid,
|
|
|
|
* -ENOSPC if the firmware does not have enough available space, or a
|
|
|
|
* converted EFI status code if either of set_variable() or
|
|
|
|
* get_variable() fail.
|
|
|
|
*
|
|
|
|
* If the EFI variable does not exist when calling set_variable()
|
|
|
|
* (EFI_NOT_FOUND), @entry is removed from the variable list.
|
|
|
|
*/
|
|
|
|
int efivar_entry_set_get_size(struct efivar_entry *entry, u32 attributes,
|
|
|
|
unsigned long *size, void *data, bool *set)
|
|
|
|
{
|
|
|
|
const struct efivar_operations *ops = __efivars->ops;
|
|
|
|
efi_char16_t *name = entry->var.VariableName;
|
|
|
|
efi_guid_t *vendor = &entry->var.VendorGuid;
|
|
|
|
efi_status_t status;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
*set = false;
|
|
|
|
|
2014-03-17 18:57:00 +08:00
|
|
|
if (efivar_validate(name, data, *size) == false)
|
2013-02-04 04:16:40 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The lock here protects the get_variable call, the conditional
|
|
|
|
* set_variable call, and removal of the variable from the efivars
|
|
|
|
* list (in the case of an authenticated delete).
|
|
|
|
*/
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure that the available space hasn't shrunk below the safe level
|
|
|
|
*/
|
2013-04-30 18:30:24 +08:00
|
|
|
status = check_var_size(attributes, *size + ucs2_strsize(name, 1024));
|
2013-02-04 04:16:40 +08:00
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
if (status != EFI_UNSUPPORTED) {
|
|
|
|
err = efi_status_to_err(status);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (*size > 65536) {
|
|
|
|
err = -ENOSPC;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
status = ops->set_variable(name, vendor, attributes, *size, data);
|
|
|
|
if (status != EFI_SUCCESS) {
|
|
|
|
err = efi_status_to_err(status);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
*set = true;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Writing to the variable may have caused a change in size (which
|
|
|
|
* could either be an append or an overwrite), or the variable to be
|
|
|
|
* deleted. Perform a GetVariable() so we can tell what actually
|
|
|
|
* happened.
|
|
|
|
*/
|
|
|
|
*size = 0;
|
|
|
|
status = ops->get_variable(entry->var.VariableName,
|
|
|
|
&entry->var.VendorGuid,
|
|
|
|
NULL, size, NULL);
|
|
|
|
|
|
|
|
if (status == EFI_NOT_FOUND)
|
|
|
|
efivar_entry_list_del_unlock(entry);
|
|
|
|
else
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
|
|
|
|
if (status && status != EFI_BUFFER_TOO_SMALL)
|
|
|
|
return efi_status_to_err(status);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out:
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
return err;
|
|
|
|
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_set_get_size);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_iter_begin - begin iterating the variable list
|
|
|
|
*
|
|
|
|
* Lock the variable list to prevent entry insertion and removal until
|
|
|
|
* efivar_entry_iter_end() is called. This function is usually used in
|
|
|
|
* conjunction with __efivar_entry_iter() or efivar_entry_iter().
|
|
|
|
*/
|
|
|
|
void efivar_entry_iter_begin(void)
|
|
|
|
{
|
|
|
|
spin_lock_irq(&__efivars->lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_iter_begin);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_iter_end - finish iterating the variable list
|
|
|
|
*
|
|
|
|
* Unlock the variable list and allow modifications to the list again.
|
|
|
|
*/
|
|
|
|
void efivar_entry_iter_end(void)
|
|
|
|
{
|
|
|
|
spin_unlock_irq(&__efivars->lock);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_iter_end);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __efivar_entry_iter - iterate over variable list
|
|
|
|
* @func: callback function
|
|
|
|
* @head: head of the variable list
|
|
|
|
* @data: function-specific data to pass to callback
|
|
|
|
* @prev: entry to begin iterating from
|
|
|
|
*
|
|
|
|
* Iterate over the list of EFI variables and call @func with every
|
|
|
|
* entry on the list. It is safe for @func to remove entries in the
|
|
|
|
* list via efivar_entry_delete().
|
|
|
|
*
|
|
|
|
* You MUST call efivar_enter_iter_begin() before this function, and
|
|
|
|
* efivar_entry_iter_end() afterwards.
|
|
|
|
*
|
|
|
|
* It is possible to begin iteration from an arbitrary entry within
|
|
|
|
* the list by passing @prev. @prev is updated on return to point to
|
|
|
|
* the last entry passed to @func. To begin iterating from the
|
|
|
|
* beginning of the list @prev must be %NULL.
|
|
|
|
*
|
|
|
|
* The restrictions for @func are the same as documented for
|
|
|
|
* efivar_entry_iter().
|
|
|
|
*/
|
|
|
|
int __efivar_entry_iter(int (*func)(struct efivar_entry *, void *),
|
|
|
|
struct list_head *head, void *data,
|
|
|
|
struct efivar_entry **prev)
|
|
|
|
{
|
|
|
|
struct efivar_entry *entry, *n;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
if (!prev || !*prev) {
|
|
|
|
list_for_each_entry_safe(entry, n, head, list) {
|
|
|
|
err = func(entry, data);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (prev)
|
|
|
|
*prev = entry;
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
list_for_each_entry_safe_continue((*prev), n, head, list) {
|
|
|
|
err = func(*prev, data);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__efivar_entry_iter);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivar_entry_iter - iterate over variable list
|
|
|
|
* @func: callback function
|
|
|
|
* @head: head of variable list
|
|
|
|
* @data: function-specific data to pass to callback
|
|
|
|
*
|
|
|
|
* Iterate over the list of EFI variables and call @func with every
|
|
|
|
* entry on the list. It is safe for @func to remove entries in the
|
|
|
|
* list via efivar_entry_delete() while iterating.
|
|
|
|
*
|
|
|
|
* Some notes for the callback function:
|
|
|
|
* - a non-zero return value indicates an error and terminates the loop
|
|
|
|
* - @func is called from atomic context
|
|
|
|
*/
|
|
|
|
int efivar_entry_iter(int (*func)(struct efivar_entry *, void *),
|
|
|
|
struct list_head *head, void *data)
|
|
|
|
{
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
efivar_entry_iter_begin();
|
|
|
|
err = __efivar_entry_iter(func, head, data, NULL);
|
|
|
|
efivar_entry_iter_end();
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_entry_iter);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* efivars_kobject - get the kobject for the registered efivars
|
|
|
|
*
|
|
|
|
* If efivars_register() has not been called we return NULL,
|
|
|
|
* otherwise return the kobject used at registration time.
|
|
|
|
*/
|
|
|
|
struct kobject *efivars_kobject(void)
|
|
|
|
{
|
|
|
|
if (!__efivars)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return __efivars->kobject;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivars_kobject);
|
|
|
|
|
2013-02-08 23:48:51 +08:00
|
|
|
/**
|
|
|
|
* efivar_run_worker - schedule the efivar worker thread
|
|
|
|
*/
|
|
|
|
void efivar_run_worker(void)
|
|
|
|
{
|
|
|
|
if (efivar_wq_enabled)
|
|
|
|
schedule_work(&efivar_work);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivar_run_worker);
|
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
/**
|
|
|
|
* efivars_register - register an efivars
|
|
|
|
* @efivars: efivars to register
|
|
|
|
* @ops: efivars operations
|
|
|
|
* @kobject: @efivars-specific kobject
|
|
|
|
*
|
|
|
|
* Only a single efivars can be registered at any time.
|
|
|
|
*/
|
|
|
|
int efivars_register(struct efivars *efivars,
|
|
|
|
const struct efivar_operations *ops,
|
|
|
|
struct kobject *kobject)
|
|
|
|
{
|
|
|
|
spin_lock_init(&efivars->lock);
|
|
|
|
efivars->ops = ops;
|
|
|
|
efivars->kobject = kobject;
|
|
|
|
|
|
|
|
__efivars = efivars;
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(efivars_register);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2013-02-04 04:16:40 +08:00
|
|
|
/**
|
|
|
|
* efivars_unregister - unregister an efivars
|
|
|
|
* @efivars: efivars to unregister
|
|
|
|
*
|
|
|
|
* The caller must have already removed every entry from the list,
|
|
|
|
* failure to do so is an error.
|
|
|
|
*/
|
|
|
|
int efivars_unregister(struct efivars *efivars)
|
|
|
|
{
|
|
|
|
int rv;
|
|
|
|
|
|
|
|
if (!__efivars) {
|
|
|
|
printk(KERN_ERR "efivars not registered\n");
|
|
|
|
rv = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (__efivars != efivars) {
|
|
|
|
rv = -EINVAL;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
|
|
|
__efivars = NULL;
|
|
|
|
|
|
|
|
rv = 0;
|
|
|
|
out:
|
|
|
|
return rv;
|
2011-03-12 09:43:16 +08:00
|
|
|
}
|
2013-02-04 04:16:40 +08:00
|
|
|
EXPORT_SYMBOL_GPL(efivars_unregister);
|