1. 29 Nov, 2013 1 commit
  2. 13 May, 2013 1 commit
    • Seiji Aguchi's avatar
      efivar: fix oops in efivar_update_sysfs_entries() caused by memory reuse · d51df2c5
      Seiji Aguchi authored
      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: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      d51df2c5
  3. 01 May, 2013 3 commits
    • Ben Hutchings's avatar
      dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present() · 79bae42d
      Ben Hutchings authored
      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: default avatarBen Hutchings <ben@decadent.org.uk>
      Reported-by: default avatarTim McGrath <tmhikaru@gmail.com>
      Tested-by: default avatarTim Mcgrath <tmhikaru@gmail.com>
      Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
      Signed-off-by: default avatarArtem Savkov <artem.savkov@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      79bae42d
    • Tejun Heo's avatar
      dump_stack: implement arch-specific hardware description in task dumps · 98e5e1bf
      Tejun Heo authored
      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: default avatarTejun 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      98e5e1bf
    • Tejun Heo's avatar
      dmi: morph dmi_dump_ids() into dmi_format_ids() which formats into a buffer · c90fe6bc
      Tejun Heo authored
      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: default avatarTejun 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: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c90fe6bc
  4. 30 Apr, 2013 5 commits
  5. 29 Apr, 2013 2 commits
  6. 26 Apr, 2013 1 commit
    • Matt Fleming's avatar
      efivars: only check for duplicates on the registered list · f464246d
      Matt Fleming authored
      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: default avatarMichel Lespinasse <walken@google.com>
      Tested-by: default avatarMichel 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: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f464246d
  7. 17 Apr, 2013 6 commits
    • Tom Gundersen's avatar
      efi: split efisubsystem from efivars · a9499fa7
      Tom Gundersen authored
      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: default avatarTom Gundersen <teg@jklm.no>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      a9499fa7
    • Matt Fleming's avatar
      efivarfs: Move to fs/efivarfs · d68772b7
      Matt Fleming authored
      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: default avatarTom Gundersen <teg@jklm.no>
      Tested-by: default avatarTom Gundersen <teg@jklm.no>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      d68772b7
    • Matt Fleming's avatar
      efivars: Move pstore code into the new EFI directory · 04851772
      Matt Fleming authored
      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: default avatarTom Gundersen <teg@jklm.no>
      Tested-by: default avatarTom 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: default avatarMatt Fleming <matt.fleming@intel.com>
      04851772
    • Matt Fleming's avatar
      efivars: efivar_entry API · e14ab23d
      Matt Fleming authored
      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: default avatarTom Gundersen <teg@jklm.no>
      Tested-by: default avatarTom 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: default avatarMatt Fleming <matt.fleming@intel.com>
      e14ab23d
    • Matt Fleming's avatar
      efivars: Keep a private global pointer to efivars · 4423d779
      Matt Fleming authored
      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: default avatarTom Gundersen <teg@jklm.no>
      Tested-by: default avatarTom Gundersen <teg@jklm.no>
      Acked-by: default avatarMike Waychison <mikew@google.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      4423d779
    • Matt Fleming's avatar
      efi: move utf16 string functions to efi.h · d5abc7c1
      Matt Fleming authored
      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: default avatarTom Gundersen <teg@jklm.no>
      Tested-by: default avatarTom Gundersen <teg@jklm.no>
      Reviewed-by: default avatarMike Waychison <mikew@google.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      d5abc7c1
  8. 15 Apr, 2013 1 commit
  9. 09 Apr, 2013 1 commit
    • Matt Fleming's avatar
      x86, efivars: firmware bug workarounds should be in platform code · a6e4d5a0
      Matt Fleming authored
      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: default avatarMatt Fleming <matt.fleming@intel.com>
      a6e4d5a0
  10. 22 Mar, 2013 1 commit
  11. 21 Mar, 2013 4 commits
    • Matt Fleming's avatar
      efivars: Handle duplicate names from get_next_variable() · e971318b
      Matt Fleming authored
      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: default avatarAndre Heider <a.heider@gmail.com>
      Reported-by: default avatarLingzhu Xiang <lxiang@redhat.com>
      Tested-by: default avatarLingzhu Xiang <lxiang@redhat.com>
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      e971318b
    • Matt Fleming's avatar
      efivars: explicitly calculate length of VariableName · ec50bd32
      Matt Fleming authored
      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: default avatarFrederic 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: default avatarMatt Fleming <matt.fleming@intel.com>
      ec50bd32
    • Seth Forshee's avatar
      efivars: Add module parameter to disable use as a pstore backend · ec0971ba
      Seth Forshee authored
      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: default avatarSeth 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: default avatarMatt Fleming <matt.fleming@intel.com>
      ec0971ba
    • Seth Forshee's avatar
      efivars: Allow disabling use as a pstore backend · ed9dc8ce
      Seth Forshee authored
      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: default avatarSeth 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: default avatarMatt Fleming <matt.fleming@intel.com>
      ed9dc8ce
  12. 08 Mar, 2013 1 commit
  13. 06 Mar, 2013 3 commits
    • Matt Fleming's avatar
      efivarfs: return accurate error code in efivarfs_fill_super() · feff5dc4
      Matt Fleming authored
      Joseph was hitting a failure case when mounting efivarfs which
      resulted in an incorrect error message,
      
        $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory
      
      triggered when efivarfs_valid_name() returned -EINVAL.
      
      Make sure we pass accurate return values up the stack if
      efivarfs_fill_super() fails to build inodes for EFI variables.
      Reported-by: default avatarJoseph Yasi <joe.yasi@gmail.com>
      Reported-by: default avatarLingzhu Xiang <lxiang@redhat.com>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: <stable@vger.kernel.org> # v3.8
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      feff5dc4
    • Matt Fleming's avatar
      efivars: efivarfs_valid_name() should handle pstore syntax · 123abd76
      Matt Fleming authored
      Stricter validation was introduced with commit da27a243
      ("efivarfs: guid part of filenames are case-insensitive") and commit
      47f531e8 ("efivarfs: Validate filenames much more aggressively"),
      which is necessary for the guid portion of efivarfs filenames, but we
      don't need to be so strict with the first part, the variable name. The
      UEFI specification doesn't impose any constraints on variable names
      other than they be a NULL-terminated string.
      
      The above commits caused a regression that resulted in users seeing
      the following message,
      
        $ sudo mount -v /sys/firmware/efi/efivars mount: Cannot allocate memory
      
      whenever pstore EFI variables were present in the variable store,
      since their variable names failed to pass the following check,
      
          /* GUID should be right after the first '-' */
          if (s - 1 != strchr(str, '-'))
      
      as a typical pstore filename is of the form, dump-type0-10-1-<guid>.
      The fix is trivial since the guid portion of the filename is GUID_LEN
      bytes, we can use (len - GUID_LEN) to ensure the '-' character is
      where we expect it to be.
      
      (The bogus ENOMEM error value will be fixed in a separate patch.)
      Reported-by: default avatarJoseph Yasi <joe.yasi@gmail.com>
      Tested-by: default avatarJoseph Yasi <joe.yasi@gmail.com>
      Reported-by: default avatarLingzhu Xiang <lxiang@redhat.com>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: Jeremy Kerr <jk@ozlabs.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: <stable@vger.kernel.org> # v3.8
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      123abd76
    • Matthew Garrett's avatar
      efi: be more paranoid about available space when creating variables · 68d92986
      Matthew Garrett authored
      UEFI variables are typically stored in flash. For various reasons, avaiable
      space is typically not reclaimed immediately upon the deletion of a
      variable - instead, the system will garbage collect during initialisation
      after a reboot.
      
      Some systems appear to handle this garbage collection extremely poorly,
      failing if more than 50% of the system flash is in use. This can result in
      the machine refusing to boot. The safest thing to do for the moment is to
      forbid writes if they'd end up using more than half of the storage space.
      We can make this more finegrained later if we come up with a method for
      identifying the broken machines.
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Cc: Josh Boyer <jwboyer@redhat.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      68d92986
  14. 04 Mar, 2013 1 commit
    • Eric W. Biederman's avatar
      fs: Limit sys_mount to only request filesystem modules. · 7f78e035
      Eric W. Biederman authored
      Modify the request_module to prefix the file system type with "fs-"
      and add aliases to all of the filesystems that can be built as modules
      to match.
      
      A common practice is to build all of the kernel code and leave code
      that is not commonly needed as modules, with the result that many
      users are exposed to any bug anywhere in the kernel.
      
      Looking for filesystems with a fs- prefix limits the pool of possible
      modules that can be loaded by mount to just filesystems trivially
      making things safer with no real cost.
      
      Using aliases means user space can control the policy of which
      filesystem modules are auto-loaded by editing /etc/modprobe.d/*.conf
      with blacklist and alias directives.  Allowing simple, safe,
      well understood work-arounds to known problematic software.
      
      This also addresses a rare but unfortunate problem where the filesystem
      name is not the same as it's module name and module auto-loading
      would not work.  While writing this patch I saw a handful of such
      cases.  The most significant being autofs that lives in the module
      autofs4.
      
      This is relevant to user namespaces because we can reach the request
      module in get_fs_type() without having any special permissions, and
      people get uncomfortable when a user specified string (in this case
      the filesystem type) goes all of the way to request_module.
      
      After having looked at this issue I don't think there is any
      particular reason to perform any filtering or permission checks beyond
      making it clear in the module request that we want a filesystem
      module.  The common pattern in the kernel is to call request_module()
      without regards to the users permissions.  In general all a filesystem
      module does once loaded is call register_filesystem() and go to sleep.
      Which means there is not much attack surface exposed by loading a
      filesytem module unless the filesystem is mounted.  In a user
      namespace filesystems are not mounted unless .fs_flags = FS_USERNS_MOUNT,
      which most filesystems do not set today.
      Acked-by: default avatarSerge Hallyn <serge.hallyn@canonical.com>
      Acked-by: default avatarKees Cook <keescook@chromium.org>
      Reported-by: default avatarKees Cook <keescook@google.com>
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      7f78e035
  15. 01 Mar, 2013 1 commit
  16. 24 Feb, 2013 1 commit
    • Yasuaki Ishimatsu's avatar
      memory-hotplug: remove /sys/firmware/memmap/X sysfs · 46c66c4b
      Yasuaki Ishimatsu authored
      When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start,
      type} sysfs files are created.  But there is no code to remove these
      files.  This patch implements the function to remove them.
      
      We cannot free firmware_map_entry which is allocated by bootmem because
      there is no way to do so when the system is up.  But we can at least
      remember the address of that memory and reuse the storage when the
      memory is added next time.
      
      This patch also introduces a new list map_entries_bootmem to link the
      map entries allocated by bootmem when they are removed, and a lock to
      protect it.  And these entries will be reused when the memory is
      hot-added again.
      
      The idea is suggestted by Andrew Morton.
      
      NOTE: It is unsafe to return an entry pointer and release the
            map_entries_lock.  So we should not hold the map_entries_lock
            separately in firmware_map_find_entry() and
            firmware_map_remove_entry().  Hold the map_entries_lock across find
            and remove /sys/firmware/memmap/X operation.
      
             And also, users of these two functions need to be careful to
            hold the lock when using these two functions.
      
      [tangchen@cn.fujitsu.com: Hold spinlock across find|remove /sys operation]
      [tangchen@cn.fujitsu.com: fix the wrong comments of map_entries]
      [tangchen@cn.fujitsu.com: reuse the storage of /sys/firmware/memmap/X/ allocated by bootmem]
      [tangchen@cn.fujitsu.com: fix section mismatch problem]
      [tangchen@cn.fujitsu.com: fix the doc format in drivers/firmware/memmap.c]
      Signed-off-by: default avatarWen Congyang <wency@cn.fujitsu.com>
      Signed-off-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarTang Chen <tangchen@cn.fujitsu.com>
      Reviewed-by: default avatarKamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
      Cc: Jiang Liu <jiang.liu@huawei.com>
      Cc: Jianguo Wu <wujianguo@huawei.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Tang Chen <tangchen@cn.fujitsu.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Julian Calaby <julian.calaby@gmail.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      46c66c4b
  17. 12 Feb, 2013 4 commits
    • Seiji Aguchi's avatar
      efi_pstore: Introducing workqueue updating sysfs · a93bc0c6
      Seiji Aguchi authored
      [Problem]
      efi_pstore creates sysfs entries, which enable users to access to NVRAM,
      in a write callback. If a kernel panic happens in an interrupt context,
      it may fail because it could sleep due to dynamic memory allocations during
      creating sysfs entries.
      
      [Patch Description]
      This patch removes sysfs operations from a write callback by introducing
      a workqueue updating sysfs entries which is scheduled after the write
      callback is called.
      
      Also, the workqueue is kicked in a just oops case.
      A system will go down in other cases such as panic, clean shutdown and emergency
      restart. And we don't need to create sysfs entries because there is no chance for
      users to access to them.
      
      efi_pstore will be robust against a kernel panic in an interrupt context with this patch.
      Signed-off-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Acked-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      a93bc0c6
    • Seiji Aguchi's avatar
      efivars: Disable external interrupt while holding efivars->lock · 81fa4e58
      Seiji Aguchi authored
      [Problem]
      There is a scenario which efi_pstore fails to log messages in a panic case.
      
       - CPUA holds an efi_var->lock in either efivarfs parts
         or efi_pstore with interrupt enabled.
       - CPUB panics and sends IPI to CPUA in smp_send_stop().
       - CPUA stops with holding the lock.
       - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC)
         but it returns without logging messages.
      
      [Patch Description]
      This patch disables an external interruption while holding efivars->lock
      as follows.
      
      In efi_pstore_write() and get_var_data(), spin_lock/spin_unlock is
      replaced by spin_lock_irqsave/spin_unlock_irqrestore because they may
      be called in an interrupt context.
      
      In other functions, they are replaced by spin_lock_irq/spin_unlock_irq.
      because they are all called from a process context.
      
      By applying this patch, we can avoid the problem above with
      a following senario.
      
       - CPUA holds an efi_var->lock with interrupt disabled.
       - CPUB panics and sends IPI to CPUA in smp_send_stop().
       - CPUA receives the IPI after releasing the lock because it is
         disabling interrupt while holding the lock.
       - CPUB waits for one sec until CPUA releases the lock.
       - CPUB kicks efi_pstore_write() via kmsg_dump(KSMG_DUMP_PANIC)
         And it can hold the lock successfully.
      Signed-off-by: default avatarSeiji Aguchi <seiji.aguchi@hds.com>
      Acked-by: default avatarMike Waychison <mikew@google.com>
      Acked-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarTony Luck <tony.luck@intel.com>
      81fa4e58
    • Matt Fleming's avatar
      efivarfs: guid part of filenames are case-insensitive · da27a243
      Matt Fleming authored
      It makes no sense to treat the following filenames as unique,
      
      	VarName-abcdefab-abcd-abcd-abcd-abcdefabcdef
      	VarName-ABCDEFAB-ABCD-ABCD-ABCD-ABCDEFABCDEF
      	VarName-ABcDEfAB-ABcD-ABcD-ABcD-ABcDEfABcDEf
      	VarName-aBcDEfAB-aBcD-aBcD-aBcD-aBcDEfaBcDEf
      	... etc ...
      
      since the guid will be converted into a binary representation, which
      has no case.
      
      Roll our own dentry operations so that we can treat the variable name
      part of filenames ("VarName" in the above example) as case-sensitive,
      but the guid portion as case-insensitive. That way, efivarfs will
      refuse to create the above files if any one already exists.
      Reported-by: default avatarLingzhu Xiang <lxiang@redhat.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      da27a243
    • Matt Fleming's avatar
      efivarfs: Validate filenames much more aggressively · 47f531e8
      Matt Fleming authored
      The only thing that efivarfs does to enforce a valid filename is
      ensure that the name isn't too short. We need to strongly sanitise any
      filenames, not least because variable creation is delayed until
      efivarfs_file_write(), which means we can't rely on the firmware to
      inform us of an invalid name, because if the file is never written to
      we'll never know it's invalid.
      
      Perform a couple of steps before agreeing to create a new file,
      
        * hex_to_bin() returns a value indicating whether or not it was able
          to convert its arguments to a binary representation - we should
          check it.
      
        * Ensure that the GUID portion of the filename is the correct length
          and format.
      
        * The variable name portion of the filename needs to be at least one
          character in size.
      Reported-by: default avatarLingzhu Xiang <lxiang@redhat.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Jeremy Kerr <jeremy.kerr@canonical.com>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      47f531e8
  18. 31 Jan, 2013 1 commit
  19. 30 Jan, 2013 1 commit
    • Matt Fleming's avatar
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming authored
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  20. 18 Jan, 2013 1 commit
    • Matt Fleming's avatar
      efivarfs: Delete dentry from dcache in efivarfs_file_write() · 791eb564
      Matt Fleming authored
      Unlike the unlink path that is called from the VFS layer, we need to
      call d_delete() ourselves when a variable is deleted in
      efivarfs_file_write().
      
      Failure to do so means we can access a stale struct efivar_entry when
      reading/writing the file, which can result in the following oops,
      
        [   59.978216] general protection fault: 0000 [#1] SMP
        [   60.038660] CPU 9
        [   60.040501] Pid: 1001, comm: cat Not tainted 3.7.0-2.fc19.x86_64 #1 IBM System x3550 M3 -[7944I21]-/69Y4438
        [   60.050840] RIP: 0010:[<ffffffff810d5d1e>]  [<ffffffff810d5d1e>] __lock_acquire+0x5e/0x1bb0
        [   60.059198] RSP: 0018:ffff880270595ce8  EFLAGS: 00010046
        [   60.064500] RAX: 0000000000000046 RBX: 0000000000000002 RCX: 0000000000000000
        [   60.071617] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 6b6b6b6b6b6b6b83
        [   60.078735] RBP: ffff880270595dd8 R08: 0000000000000002 R09: 0000000000000000
        [   60.085852] R10: 6b6b6b6b6b6b6b83 R11: 0000000000000000 R12: 0000000000000000
        [   60.092971] R13: ffff88027170cd20 R14: 0000000000000000 R15: 0000000000000000
        [   60.100091] FS:  00007fc0c8ff3740(0000) GS:ffff880277000000(0000) knlGS:0000000000000000
        [   60.108164] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        [   60.113899] CR2: 0000000001520000 CR3: 000000026d594000 CR4: 00000000000007e0
        [   60.121016] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
        [   60.128135] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
        [   60.135254] Process cat (pid: 1001, threadinfo ffff880270594000, task ffff88027170cd20)
        [   60.143239] Stack:
        [   60.145251]  ffff880270595cf8 ffffffff81021da3 ffff880270595d08 ffffffff81021e19
        [   60.152714]  ffff880270595d38 ffffffff810acdb5 ffff880200000168 0000000000000086
        [   60.160175]  ffff88027170d5e8 ffffffff810d25ed ffff880270595d58 ffffffff810ace7f
        [   60.167638] Call Trace:
        [   60.170088]  [<ffffffff81021da3>] ? native_sched_clock+0x13/0x80
        [   60.176085]  [<ffffffff81021e19>] ? sched_clock+0x9/0x10
        [   60.181389]  [<ffffffff810acdb5>] ? sched_clock_cpu+0xc5/0x120
        [   60.187211]  [<ffffffff810d25ed>] ? trace_hardirqs_off+0xd/0x10
        [   60.193121]  [<ffffffff810ace7f>] ? local_clock+0x6f/0x80
        [   60.198513]  [<ffffffff810d2f6f>] ? lock_release_holdtime.part.26+0xf/0x180
        [   60.205465]  [<ffffffff810d7b57>] ? lock_release_non_nested+0x2e7/0x320
        [   60.212073]  [<ffffffff815638bb>] ? efivarfs_file_write+0x5b/0x280
        [   60.218242]  [<ffffffff810d7f41>] lock_acquire+0xa1/0x1f0
        [   60.223633]  [<ffffffff81563971>] ? efivarfs_file_write+0x111/0x280
        [   60.229892]  [<ffffffff8118b47c>] ? might_fault+0x5c/0xb0
        [   60.235287]  [<ffffffff816f1bf6>] _raw_spin_lock+0x46/0x80
        [   60.240762]  [<ffffffff81563971>] ? efivarfs_file_write+0x111/0x280
        [   60.247018]  [<ffffffff81563971>] efivarfs_file_write+0x111/0x280
        [   60.253103]  [<ffffffff811d307f>] vfs_write+0xaf/0x190
        [   60.258233]  [<ffffffff811d33d5>] sys_write+0x55/0xa0
        [   60.263278]  [<ffffffff816fbd19>] system_call_fastpath+0x16/0x1b
        [   60.269271] Code: 41 0f 45 d8 4c 89 75 f0 4c 89 7d f8 85 c0 0f 84 09 01 00 00 8b 05 a3 f9 ff 00 49 89 fa 41 89 f6 41 89 d3 85 c0 0f 84 12 01 00 00 <49> 8b 02 ba 01 00 00 00 48 3d a0 07 14 82 0f 44 da 41 83 fe 01
        [   60.289431] RIP  [<ffffffff810d5d1e>] __lock_acquire+0x5e/0x1bb0
        [   60.295444]  RSP <ffff880270595ce8>
        [   60.298928] ---[ end trace 1bbfd41a2cf6a0d8 ]---
      
      Cc: Josh Boyer <jwboyer@redhat.com>
      Acked-by: default avatarJeremy Kerr <jeremy.kerr@canonical.com>
      Cc: Lee, Chun-Yi <jlee@suse.com>
      Cc: Andy Whitcroft <apw@canonical.com>
      Reported-by: default avatarLingzhu Xiang <lxiang@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      791eb564