1. 13 12月, 2013 9 次提交
    • L
      Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging · 86b581f6
      Linus Torvalds 提交于
      Pull hwmon fix from Guenter Roeck:
       "Fix HIH-6130 driver to work with BeagleBone"
      
      * tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
        hwmon: HIH-6130: Support I2C bus drivers without I2C_FUNC_SMBUS_QUICK
      86b581f6
    • L
      Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging · c8469441
      Linus Torvalds 提交于
      Pull hwmon fixes from Jean Delvare.
      
      * 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging:
        hwmon: Prevent some divide by zeros in FAN_TO_REG()
        hwmon: (w83l768ng) Fix fan speed control range
        hwmon: (w83l786ng) Fix fan speed control mode setting and reporting
        hwmon: (lm90) Unregister hwmon device if interrupt setup fails
      c8469441
    • W
      word-at-a-time: provide generic big-endian zero_bytemask implementation · 11ec50ca
      Will Deacon 提交于
      Whilst architectures may be able to do better than this (which they can,
      by simply defining their own macro), this is a generic stab at a
      zero_bytemask implementation for the asm-generic, big-endian
      word-at-a-time implementation.
      
      On arm64, a clz instruction is used to implement the fls efficiently.
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      11ec50ca
    • W
      dcache: allow word-at-a-time name hashing with big-endian CPUs · a5c21dce
      Will Deacon 提交于
      When explicitly hashing the end of a string with the word-at-a-time
      interface, we have to be careful which end of the word we pick up.
      
      On big-endian CPUs, the upper-bits will contain the data we're after, so
      ensure we generate our masks accordingly (and avoid hashing whatever
      random junk may have been sitting after the string).
      
      This patch adds a new dcache helper, bytemask_from_count, which creates
      a mask appropriate for the CPU endianness.
      
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a5c21dce
    • L
      Merge tag 'iommu-fixes-for-v3.13-rc4' of git://github.com/awilliam/linux-vfio · 319720f5
      Linus Torvalds 提交于
      Pull iommu fixes from Alex Williamson:
       "arm/smmu driver updates via Will Deacon fixing locking around page
        table walks and a couple other issues"
      
      * tag 'iommu-fixes-for-v3.13-rc4' of git://github.com/awilliam/linux-vfio:
        iommu/arm-smmu: fix error return code in arm_smmu_device_dt_probe()
        iommu/arm-smmu: remove potential NULL dereference on mapping path
        iommu/arm-smmu: use mutex instead of spinlock for locking page tables
      319720f5
    • L
      Merge tag 'keys-devel-20131210' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs · 5dec682c
      Linus Torvalds 提交于
      Pull misc keyrings fixes from David Howells:
       "These break down into five sets:
      
         - A patch to error handling in the big_key type for huge payloads.
           If the payload is larger than the "low limit" and the backing store
           allocation fails, then big_key_instantiate() doesn't clear the
           payload pointers in the key, assuming them to have been previously
           cleared - but only one of them is.
      
           Unfortunately, the garbage collector still calls big_key_destroy()
           when sees one of the pointers with a weird value in it (and not
           NULL) which it then tries to clean up.
      
         - Three patches to fix the keyring type:
      
           * A patch to fix the hash function to correctly divide keyrings off
             from keys in the topology of the tree inside the associative
             array.  This is only a problem if searching through nested
             keyrings - and only if the hash function incorrectly puts the a
             keyring outside of the 0 branch of the root node.
      
           * A patch to fix keyrings' use of the associative array.  The
             __key_link_begin() function initially passes a NULL key pointer
             to assoc_array_insert() on the basis that it's holding a place in
             the tree whilst it does more allocation and stuff.
      
             This is only a problem when a node contains 16 keys that match at
             that level and we want to add an also matching 17th.  This should
             easily be manufactured with a keyring full of keyrings (without
             chucking any other sort of key into the mix) - except for (a)
             above which makes it on average adding the 65th keyring.
      
           * A patch to fix searching down through nested keyrings, where any
             keyring in the set has more than 16 keyrings and none of the
             first keyrings we look through has a match (before the tree
             iteration needs to step to a more distal node).
      
           Test in keyutils test suite:
      
              http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=8b4ae963ed92523aea18dfbb8cab3f4979e13bd1
      
         - A patch to fix the big_key type's use of a shmem file as its
           backing store causing audit messages and LSM check failures.  This
           is done by setting S_PRIVATE on the file to avoid LSM checks on the
           file (access to the shmem file goes through the keyctl() interface
           and so is gated by the LSM that way).
      
           This isn't normally a problem if a key is used by the context that
           generated it - and it's currently only used by libkrb5.
      
           Test in keyutils test suite:
      
              http://git.kernel.org/cgit/linux/kernel/git/dhowells/keyutils.git/commit/?id=d9a53cbab42c293962f2f78f7190253fc73bd32e
      
         - A patch to add a generated file to .gitignore.
      
         - A patch to fix the alignment of the system certificate data such
           that it it works on s390.  As I understand it, on the S390 arch,
           symbols must be 2-byte aligned because loading the address discards
           the least-significant bit"
      
      * tag 'keys-devel-20131210' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs:
        KEYS: correct alignment of system_certificate_list content in assembly file
        Ignore generated file kernel/x509_certificate_list
        security: shmem: implement kernel private shmem inodes
        KEYS: Fix searching of nested keyrings
        KEYS: Fix multiple key add into associative array
        KEYS: Fix the keyring hash function
        KEYS: Pre-clear struct key on allocation
      5dec682c
    • L
      Merge tag 'xfs-for-linus-v3.13-rc4' of git://oss.sgi.com/xfs/xfs · 48a2f0b2
      Linus Torvalds 提交于
      Pull xfs bugfixes from Ben Myers:
      
       - fix for buffer overrun in agfl with growfs on v4 superblock
      
       - return EINVAL if requested discard length is less than a block
      
       - fix possible memory corruption in xfs_attrlist_by_handle()
      
      * tag 'xfs-for-linus-v3.13-rc4' of git://oss.sgi.com/xfs/xfs:
        xfs: growfs overruns AGFL buffer on V4 filesystems
        xfs: don't perform discard if the given range length is less than block size
        xfs: underflow bug in xfs_attrlist_by_handle()
      48a2f0b2
    • L
      futex: move user address verification up to common code · 5cdec2d8
      Linus Torvalds 提交于
      When debugging the read-only hugepage case, I was confused by the fact
      that get_futex_key() did an access_ok() only for the non-shared futex
      case, since the user address checking really isn't in any way specific
      to the private key handling.
      
      Now, it turns out that the shared key handling does effectively do the
      equivalent checks inside get_user_pages_fast() (it doesn't actually
      check the address range on x86, but does check the page protections for
      being a user page).  So it wasn't actually a bug, but the fact that we
      treat the address differently for private and shared futexes threw me
      for a loop.
      
      Just move the check up, so that it gets done for both cases.  Also, use
      the 'rw' parameter for the type, even if it doesn't actually matter any
      more (it's a historical artifact of the old racy i386 "page faults from
      kernel space don't check write protections").
      
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5cdec2d8
    • L
      futex: fix handling of read-only-mapped hugepages · f12d5bfc
      Linus Torvalds 提交于
      The hugepage code had the exact same bug that regular pages had in
      commit 7485d0d3 ("futexes: Remove rw parameter from
      get_futex_key()").
      
      The regular page case was fixed by commit 9ea71503 ("futex: Fix
      regression with read only mappings"), but the transparent hugepage case
      (added in a5b338f2: "thp: update futex compound knowledge") case
      remained broken.
      
      Found by Dave Jones and his trinity tool.
      Reported-and-tested-by: NDave Jones <davej@fedoraproject.org>
      Cc: stable@kernel.org # v2.6.38+
      Acked-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Mel Gorman <mgorman@suse.de>
      Cc: Darren Hart <dvhart@linux.intel.com>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f12d5bfc
  2. 12 12月, 2013 5 次提交
  3. 11 12月, 2013 7 次提交
  4. 10 12月, 2013 19 次提交