1. 17 Mar, 2013 3 commits
    • David Rientjes's avatar
      perf,x86: fix link failure for non-Intel configs · 6c4d3bc9
      David Rientjes authored
      Commit 1d9d8639
      
       ("perf,x86: fix kernel crash with PEBS/BTS after
      suspend/resume") introduces a link failure since
      perf_restore_debug_store() is only defined for CONFIG_CPU_SUP_INTEL:
      
      	arch/x86/power/built-in.o: In function `restore_processor_state':
      	(.text+0x45c): undefined reference to `perf_restore_debug_store'
      
      Fix it by defining the dummy function appropriately.
      Signed-off-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      6c4d3bc9
    • Linus Torvalds's avatar
      perf,x86: fix wrmsr_on_cpu() warning on suspend/resume · 2a6e06b2
      Linus Torvalds authored
      Commit 1d9d8639
      
       ("perf,x86: fix kernel crash with PEBS/BTS after
      suspend/resume") fixed a crash when doing PEBS performance profiling
      after resuming, but in using init_debug_store_on_cpu() to restore the
      DS_AREA mtrr it also resulted in a new WARN_ON() triggering.
      
      init_debug_store_on_cpu() uses "wrmsr_on_cpu()", which in turn uses CPU
      cross-calls to do the MSR update.  Which is not really valid at the
      early resume stage, and the warning is quite reasonable.  Now, it all
      happens to _work_, for the simple reason that smp_call_function_single()
      ends up just doing the call directly on the CPU when the CPU number
      matches, but we really should just do the wrmsr() directly instead.
      
      This duplicates the wrmsr() logic, but hopefully we can just remove the
      wrmsr_on_cpu() version eventually.
      Reported-and-tested-by: default avatarParag Warudkar <parag.lkml@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      2a6e06b2
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 08637024
      Linus Torvalds authored
      Pull btrfs fixes from Chris Mason:
       "Eric's rcu barrier patch fixes a long standing problem with our
        unmount code hanging on to devices in workqueue helpers.  Liu Bo
        nailed down a difficult assertion for in-memory extent mappings."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: fix warning of free_extent_map
        Btrfs: fix warning when creating snapshots
        Btrfs: return as soon as possible when edquot happens
        Btrfs: return EIO if we have extent tree corruption
        btrfs: use rcu_barrier() to wait for bdev puts at unmount
        Btrfs: remove btrfs_try_spin_lock
        Btrfs: get better concurrency for snapshot-aware defrag work
      08637024
  2. 15 Mar, 2013 15 commits
  3. 14 Mar, 2013 15 commits
  4. 13 Mar, 2013 7 commits
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace · aea8b5d1
      Linus Torvalds authored
      Pull namespace bugfixes from Eric Biederman:
       "This tree includes a partial revert for "fs: Limit sys_mount to only
        request filesystem modules." When I added the new style module aliases
        to the filesystems I deleted the old ones.  A bad move.  It turns out
        that distributions like Arch linux use module aliases when
        constructing ramdisks.  Which meant ultimately that an ext3 filesystem
        mounted with ext4 would not result in the ext4 module being put into
        the ramdisk.
      
        The other change in this tree adds a handful of filesystem module
        alias I simply failed to add the first time.  Which inconvinienced a
        few folks using cifs.
      
        I don't want to inconvinience folks any longer than I have to so here
        are these trivial fixes."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace:
        fs: Readd the fs module aliases.
        fs: Limit sys_mount to only request filesystem modules. (Part 3)
      aea8b5d1
    • Linus Torvalds's avatar
      Merge branch 'akpm' (fixes from Andrew) · 842d223f
      Linus Torvalds authored
      Merge misc fixes from Andrew Morton:
      
       - A bunch of fixes
      
       - Finish off the idr API conversions before someone starts to use the
         old interfaces again.
      
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        idr: idr_alloc() shouldn't trigger lowmem warning when preloaded
        UAPI: fix endianness conditionals in M32R's asm/stat.h
        UAPI: fix endianness conditionals in linux/raid/md_p.h
        UAPI: fix endianness conditionals in linux/acct.h
        UAPI: fix endianness conditionals in linux/aio_abi.h
        decompressors: fix typo "POWERPC"
        mm/fremap.c: fix oops on error path
        idr: deprecate idr_pre_get() and idr_get_new[_above]()
        tidspbridge: convert to idr_alloc()
        zcache: convert to idr_alloc()
        mlx4: remove leftover idr_pre_get() call
        workqueue: convert to idr_alloc()
        nfsd: convert to idr_alloc()
        nfsd: remove unused get_new_stid()
        kernel/signal.c: use __ARCH_HAS_SA_RESTORER instead of SA_RESTORER
        signal: always clear sa_restorer on execve
        mm: remove_memory(): fix end_pfn setting
        include/linux/res_counter.h needs errno.h
      842d223f
    • Tejun Heo's avatar
      idr: idr_alloc() shouldn't trigger lowmem warning when preloaded · 59bfbcf0
      Tejun Heo authored
      
      
      GFP_NOIO is often used for idr_alloc() inside preloaded section as the
      allocation mask doesn't really matter.  If the idr tree needs to be
      expanded, idr_alloc() first tries to allocate using the specified
      allocation mask and if it fails falls back to the preloaded buffer.  This
      order prevent non-preloading idr_alloc() users from taking advantage of
      preloading ones by using preload buffer without filling it shifting the
      burden of allocation to the preload users.
      
      Unfortunately, this allowed/expected-to-fail kmem_cache allocation ends up
      generating spurious slab lowmem warning before succeeding the request from
      the preload buffer.
      
      This patch makes idr_layer_alloc() add __GFP_NOWARN to the first
      kmem_cache attempt and try kmem_cache again w/o __GFP_NOWARN after
      allocation from preload_buffer fails so that lowmem warning is generated
      if not suppressed by the original @gfp_mask.
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Reported-by: default avatarDavid Teigland <teigland@redhat.com>
      Tested-by: default avatarDavid Teigland <teigland@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      59bfbcf0
    • David Howells's avatar
      UAPI: fix endianness conditionals in M32R's asm/stat.h · 415586c9
      David Howells authored
      
      
      In the UAPI header files, __BIG_ENDIAN and __LITTLE_ENDIAN must be
      compared against __BYTE_ORDER in preprocessor conditionals where these are
      exposed to userspace (that is they're not inside __KERNEL__ conditionals).
      
      However, in the main kernel the norm is to check for
      "defined(__XXX_ENDIAN)" rather than comparing against __BYTE_ORDER and
      this has incorrectly leaked into the userspace headers.
      
      The definition of struct stat64 in M32R's asm/stat.h is wrong in this way.
       Note that userspace will likely interpret the field order incorrectly as
      the big-endian variant on little-endian machines - depending on header
      inclusion order.
      
      [!!!] NOTE [!!!]  This patch may adversely change the userspace API.  It might
      be better to fix the ordering of st_blocks and __pad4 in struct stat64.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      415586c9
    • David Howells's avatar
      UAPI: fix endianness conditionals in linux/raid/md_p.h · ca044f9a
      David Howells authored
      
      
      In the UAPI header files, __BIG_ENDIAN and __LITTLE_ENDIAN must be
      compared against __BYTE_ORDER in preprocessor conditionals where these are
      exposed to userspace (that is they're not inside __KERNEL__ conditionals).
      
      However, in the main kernel the norm is to check for
      "defined(__XXX_ENDIAN)" rather than comparing against __BYTE_ORDER and
      this has incorrectly leaked into the userspace headers.
      
      The definition of struct mdp_superblock_s in linux/raid/md_p.h is wrong in
      this way.  Note that userspace will likely interpret the ordering of the
      fields incorrectly as the big-endian variant on a little-endian machines -
      depending on header inclusion order.
      
      [!!!] NOTE [!!!]  This patch may adversely change the userspace API.  It might
      be better to fix the ordering of events_hi, events_lo, cp_events_hi and
      cp_events_lo in struct mdp_superblock_s / typedef mdp_super_t.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      ca044f9a
    • David Howells's avatar
      UAPI: fix endianness conditionals in linux/acct.h · 29ba06b9
      David Howells authored
      
      
      In the UAPI header files, __BIG_ENDIAN and __LITTLE_ENDIAN must be
      compared against __BYTE_ORDER in preprocessor conditionals where these are
      exposed to userspace (that is they're not inside __KERNEL__ conditionals).
      
      However, in the main kernel the norm is to check for
      "defined(__XXX_ENDIAN)" rather than comparing against __BYTE_ORDER and
      this has incorrectly leaked into the userspace headers.
      
      The definition of ACCT_BYTEORDER in linux/acct.h is wrong in this way.
      Note that userspace will likely interpret this incorrectly as the
      big-endian variant on little-endian machines - depending on header
      inclusion order.
      
      [!!!] NOTE [!!!]  This patch may adversely change the userspace API.  It might
      be better to fix the value of ACCT_BYTEORDER.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      29ba06b9
    • David Howells's avatar
      UAPI: fix endianness conditionals in linux/aio_abi.h · 51b154ed
      David Howells authored
      
      
      In the UAPI header files, __BIG_ENDIAN and __LITTLE_ENDIAN must be
      compared against __BYTE_ORDER in preprocessor conditionals where these are
      exposed to userspace (that is they're not inside __KERNEL__ conditionals).
      
      However, in the main kernel the norm is to check for
      "defined(__XXX_ENDIAN)" rather than comparing against __BYTE_ORDER and
      this has incorrectly leaked into the userspace headers.
      
      The definition of PADDED() in linux/aio_abi.h is wrong in this way.  Note
      that userspace will likely interpret this and thus the order of fields in
      struct iocb incorrectly as the little-endian variant on big-endian
      machines - depending on header inclusion order.
      
      [!!!] NOTE [!!!]  This patch may adversely change the userspace API.  It might
      be better to fix the ordering of aio_key and aio_reserved1 in struct iocb.
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Acked-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Acked-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      51b154ed