1. 24 Apr, 2013 2 commits
    • Josh Boyer's avatar
      efi: Check EFI revision in setup_efi_vars · f697036b
      Josh Boyer authored
      We need to check the runtime sys_table for the EFI version the firmware
      specifies instead of just checking for a NULL QueryVariableInfo.  Older
      implementations of EFI don't have QueryVariableInfo but the runtime is
      a smaller structure, so the pointer to it may be pointing off into garbage.
      
      This is apparently the case with several Apple firmwares that support EFI
      1.10, and the current check causes them to no longer boot.  Fix based on
      a suggestion from Matthew Garrett.
      Signed-off-by: default avatarJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      f697036b
    • Borislav Petkov's avatar
      x86, efi: Fix a build warning · 51f8fbba
      Borislav Petkov authored
      Fix this:
      
      arch/x86/boot/compressed/eboot.c: In function ‘setup_efi_vars’:
      arch/x86/boot/compressed/eboot.c:269:2: warning: passing argument 1 of ‘efi_call_phys’ makes pointer from integer without a cast [enabled by default]
      In file included from arch/x86/boot/compressed/eboot.c:12:0:
      /w/kernel/linux/arch/x86/include/asm/efi.h:8:33: note: expected ‘void *’ but argument is of type ‘long unsigned int’
      
      after cc5a080c ("efi: Pass boot services variable info to runtime
      code").
      Reported-by: default avatarPaul Bolle <pebolle@tiscali.nl>
      Cc: Matthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      51f8fbba
  2. 17 Apr, 2013 1 commit
  3. 16 Apr, 2013 2 commits
  4. 15 Apr, 2013 3 commits
    • Matthew Garrett's avatar
      efi: Distinguish between "remaining space" and actually used space · 31ff2f20
      Matthew Garrett authored
      EFI implementations distinguish between space that is actively used by a
      variable and space that merely hasn't been garbage collected yet. Space
      that hasn't yet been garbage collected isn't available for use and so isn't
      counted in the remaining_space field returned by QueryVariableInfo().
      
      Combined with commit 68d92986 this can cause problems. Some implementations
      don't garbage collect until the remaining space is smaller than the maximum
      variable size, and as a result check_var_size() will always fail once more
      than 50% of the variable store has been used even if most of that space is
      marked as available for garbage collection. The user is unable to create
      new variables, and deleting variables doesn't increase the remaining space.
      
      The problem that 68d92986 was attempting to avoid was one where certain
      platforms fail if the actively used space is greater than 50% of the
      available storage space. We should be able to calculate that by simply
      summing the size of each available variable and subtracting that from
      the total storage space. With luck this will fix the problem described in
      https://bugzilla.kernel.org/show_bug.cgi?id=55471 without permitting
      damage to occur to the machines 68d92986 was attempting to fix.
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      31ff2f20
    • Matthew Garrett's avatar
      efi: Pass boot services variable info to runtime code · cc5a080c
      Matthew Garrett authored
      EFI variables can be flagged as being accessible only within boot services.
      This makes it awkward for us to figure out how much space they use at
      runtime. In theory we could figure this out by simply comparing the results
      from QueryVariableInfo() to the space used by all of our variables, but
      that fails if the platform doesn't garbage collect on every boot. Thankfully,
      calling QueryVariableInfo() while still inside boot services gives a more
      reliable answer. This patch passes that information from the EFI boot stub
      up to the efi platform code.
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      cc5a080c
    • Matthew Garrett's avatar
      Move utf16 functions to kernel core and rename · 0635eb8a
      Matthew Garrett authored
      We want to be able to use the utf16 functions that are currently present
      in the EFI variables code in platform-specific code as well. Move them to
      the kernel core, and in the process rename them to accurately describe what
      they do - they don't handle UTF16, only UCS2.
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      0635eb8a
  5. 11 Apr, 2013 1 commit
  6. 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
  7. 22 Mar, 2013 1 commit
  8. 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
  9. 10 Mar, 2013 2 commits
    • Linus Torvalds's avatar
      Linux 3.9-rc2 · f6161aa1
      Linus Torvalds authored
      f6161aa1
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace · 72932611
      Linus Torvalds authored
      Pull namespace bugfixes from Eric Biederman:
       "This is three simple fixes against 3.9-rc1.  I have tested each of
        these fixes and verified they work correctly.
      
        The userns oops in key_change_session_keyring and the BUG_ON triggered
        by proc_ns_follow_link were found by Dave Jones.
      
        I am including the enhancement for mount to only trigger requests of
        filesystem modules here instead of delaying this for the 3.10 merge
        window because it is both trivial and the kind of change that tends to
        bit-rot if left untouched for two months."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
        proc: Use nd_jump_link in proc_ns_follow_link
        fs: Limit sys_mount to only request filesystem modules (Part 2).
        fs: Limit sys_mount to only request filesystem modules.
        userns: Stop oopsing in key_change_session_keyring
      72932611
  10. 09 Mar, 2013 5 commits
    • Linus Torvalds's avatar
      Atmel MXT touchscreen: increase reset timeouts · 8343bce1
      Linus Torvalds authored
      There is a more complete atmel patch-series out by Nick Dyer that fixes
      this and other things, but in the meantime this is the minimal thing to
      get the touchscreen going on (at least my) Pixel Chromebook.
      
      Not that I want my dirty fingers near that beautiful screen, but it
      seems that a non-initialized touchscreen will also end up being a
      constant wakeup source, so you have to disable it to go to sleep.  And
      it's easier to just fix the initialization sequence.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      8343bce1
    • Eric W. Biederman's avatar
      proc: Use nd_jump_link in proc_ns_follow_link · db04dc67
      Eric W. Biederman authored
      Update proc_ns_follow_link to use nd_jump_link instead of just
      manually updating nd.path.dentry.
      
      This fixes the BUG_ON(nd->inode != parent->d_inode) reported by Dave
      Jones and reproduced trivially with mkdir /proc/self/ns/uts/a.
      
      Sigh it looks like the VFS change to require use of nd_jump_link
      happend while proc_ns_follow_link was baking and since the common case
      of proc_ns_follow_link continued to work without problems the need for
      making this change was overlooked.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      db04dc67
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 0aefda3e
      Linus Torvalds authored
      Pull btrfs fixes from Chris Mason:
       "These are scattered fixes and one performance improvement.  The
        biggest functional change is in how we throttle metadata changes.  The
        new code bumps our average file creation rate up by ~13% in fs_mark,
        and lowers CPU usage.
      
        Stefan bisected out a regression in our allocation code that made
        balance loop on extents larger than 256MB."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: improve the delayed inode throttling
        Btrfs: fix a mismerge in btrfs_balance()
        Btrfs: enforce min_bytes parameter during extent allocation
        Btrfs: allow running defrag in parallel to administrative tasks
        Btrfs: avoid deadlock on transaction waiting list
        Btrfs: do not BUG_ON on aborted situation
        Btrfs: do not BUG_ON in prepare_to_reloc
        Btrfs: free all recorded tree blocks on error
        Btrfs: build up error handling for merge_reloc_roots
        Btrfs: check for NULL pointer in updating reloc roots
        Btrfs: fix unclosed transaction handler when the async transaction commitment fails
        Btrfs: fix wrong handle at error path of create_snapshot() when the commit fails
        Btrfs: use set_nlink if our i_nlink is 0
      0aefda3e
    • Benson Leung's avatar
      Platform: x86: chromeos_laptop : Add basic platform data for atmel devices · 2ef39204
      Benson Leung authored
      Add basic platform data to get the current upstream driver working
      with the 224s touchpad and 1664s touchscreen.
      We will be using NULL config so we will use the settings from the
      devices' NVRAMs.
      Signed-off-by: default avatarBenson Leung <bleung@chromium.org>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2ef39204
    • Daniel Kurtz's avatar
      Input: atmel_mxt_ts - Support for touchpad variant · 22dfab7f
      Daniel Kurtz authored
      This same driver can be used by atmel based touchscreens and touchpads
      (buttonpads). Platform data may specify a device is a touchpad
      using the is_tp flag.
      
      This will cause the driver to perform some touchpad specific
      initializations, such as:
        * register input device name "Atmel maXTouch Touchpad" instead of
        Touchscreen.
        * register BTN_LEFT & BTN_TOOL_* event types.
        * register axis resolution (as a fixed constant, for now)
        * register BUTTONPAD property
        * process GPIO buttons using reportid T19
      
      Input event GPIO mapping is done by the platform data key_map array.
      
      key_map[x] should contain the KEY or BTN code to send when processing
      GPIOx from T19. To specify a GPIO as not an input source, populate
      with KEY_RESERVED, or 0.
      Signed-off-by: default avatarDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: default avatarBenson Leung <bleung@chromium.org>
      Signed-off-by: default avatarNick Dyer <nick.dyer@itdev.co.uk>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      22dfab7f
  11. 08 Mar, 2013 18 commits