1. 17 Jan, 2014 1 commit
  2. 16 Jan, 2014 6 commits
  3. 15 Jan, 2014 12 commits
    • Linus Torvalds's avatar
      Merge branch 'akpm' (incoming from Andrew) · 2e67c562
      Linus Torvalds authored
      Merge patches from Andrew Morton:
       "Six fixes"
      * emailed patches from Andrew Morton <akpm@linux-foundation.org>:
        lib/percpu_counter.c: fix __percpu_counter_add()
        crash_dump: fix compilation error (on MIPS at least)
        mm: fix crash when using XFS on loopback
        MIPS: fix blast_icache32 on loongson2
        MIPS: fix case mismatch in local_r4k_flush_icache_range()
        nilfs2: fix segctor bug that causes file system corruption
    • Linus Torvalds's avatar
      Merge tag 'md/3.13-fixes' of git://neil.brown.name/md · 1a60864f
      Linus Torvalds authored
      Pull late md fixes from Neil Brown:
       "Half a dozen md bug fixes.
        All of these fix real bugs the people have hit, and are tagged for
        -stable.  Sorry they are late ....  Christmas holidays and all that.
        Hopefully they can still squeak into 3.13"
      * tag 'md/3.13-fixes' of git://neil.brown.name/md:
        md: fix problem when adding device to read-only array with bitmap.
        md/raid10: fix bug when raid10 recovery fails to recover a block.
        md/raid5: fix a recently broken BUG_ON().
        md/raid1: fix request counting bug in new 'barrier' code.
        md/raid10: fix two bugs in handling of known-bad-blocks.
        md/raid5: Fix possible confusion when multiple write errors occur.
    • Linus Torvalds's avatar
      Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux · 145830df
      Linus Torvalds authored
      Pull drm fixes from Dave Airlie:
       "One nouveau regression fix on older cards, i915 black screen fixes,
        and a revert for a strange G33 intel problem"
      * 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
        drm/nouveau: fix null ptr dereferences on some boards
        Revert "drm: copy mode type in drm_mode_connector_list_update()"
        drm/i915/bdw: make sure south port interrupts are enabled properly v2
        drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init()
        drm/i915: fix DDI PLLs HW state readout code
    • Ming Lei's avatar
      lib/percpu_counter.c: fix __percpu_counter_add() · 74e72f89
      Ming Lei authored
      __percpu_counter_add() may be called in softirq/hardirq handler (such
      as, blk_mq_queue_exit() is typically called in hardirq/softirq handler),
      so we need to call this_cpu_add()(irq safe helper) to update percpu
      counter, otherwise counts may be lost.
      This fixes the problem that 'rmmod null_blk' hangs in blk_cleanup_queue()
      because of miscounting of request_queue->mq_usage_counter.
      This patch is the v1 of previous one of "lib/percpu_counter.c:
      disable local irq when updating percpu couter", and takes Andrew's
      approach which may be more efficient for ARCHs(x86, s390) that
      have optimized this_cpu_add().
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Shaohua Li <shli@fusionio.com>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Fan Du <fan.du@windriver.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Qais Yousef's avatar
      crash_dump: fix compilation error (on MIPS at least) · 5a610fcc
      Qais Yousef authored
        In file included from kernel/crash_dump.c:2:0:
        include/linux/crash_dump.h:22:27: error: unknown type name `pgprot_t'
      when CONFIG_CRASH_DUMP=y
      The error was traced back to commit 9cb21813
       ("vmcore: introduce
      include <asm/pgtable.h> to get the missing definition
      Signed-off-by: default avatarQais Yousef <qais.yousef@imgtec.com>
      Reviewed-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Cc: <stable@vger.kernel.org>	[3.12+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Mikulas Patocka's avatar
      mm: fix crash when using XFS on loopback · 03e5ac2f
      Mikulas Patocka authored
      Commit 8456a648 ("slab: use struct page for slab management") causes
      a crash in the LVM2 testsuite on PA-RISC (the crashing test is
      fsadm.sh).  The testsuite doesn't crash on 3.12, crashes on 3.13-rc1 and
       Bad Address (null pointer deref?): Code=15 regs=000000413edd89a0 (Addr=000006202224647d)
       CPU: 3 PID: 24008 Comm: loop0 Not tainted 3.13.0-rc6 #5
       task: 00000001bf3c0048 ti: 000000413edd8000 task.ti: 000000413edd8000
       PSW: 00001000000001101111100100001110 Not tainted
       r00-03  000000ff0806f90e 00000000405c8de0 000000004013e6c0 000000413edd83f0
       r04-07  00000000405a95e0 0000000000000200 00000001414735f0 00000001bf349e40
       r08-11  0000000010fe3d10 0000000000000001 00000040829c7778 000000413efd9000
       r12-15  0000000000000000 000000004060d800 0000000010fe3000 0000000010fe3000
       r16-19  000000413edd82a0 00000041078ddbc0 0000000000000010 0000000000000001
       r20-23  0008f3d0d83a8000 0000000000000000 00000040829c7778 0000000000000080
       r24-27  00000001bf349e40 00000001bf349e40 202d66202224640d 00000000405a95e0
       r28-31  202d662022246465 000000413edd88f0 000000413edd89a0 0000000000000001
       sr00-03  000000000532c000 0000000000000000 0000000000000000 000000000532c000
       sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000
       IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000401fe42c 00000000401fe430
        IIR: 539c0030    ISR: 00000000202d6000  IOR: 000006202224647d
        CPU:        3   CR30: 000000413edd8000 CR31: 0000000000000000
        ORIG_R28: 00000000405a95e0
        IAOQ[0]: vma_interval_tree_iter_first+0x14/0x48
        IAOQ[1]: vma_interval_tree_iter_first+0x18/0x48
        RP(r2): flush_dcache_page+0x128/0x388
         lo_splice_actor+0x90/0x148 [loop]
         lo_direct_splice_actor+0x1c/0x70 [loop]
         lo_receive+0xe4/0x298 [loop]
         loop_thread+0x478/0x640 [loop]
         xfs_setsize_buftarg+0x0/0x90 [xfs]
       Kernel panic - not syncing: Bad Address (null pointer deref?)
      Commit 8456a648
       changes the page structure so that the slab
      subsystem reuses the page->mapping field.
      The crash happens in the following way:
       * XFS allocates some memory from slab and issues a bio to read data
         into it.
       * the bio is sent to the loopback device.
       * lo_receive creates an actor and calls splice_direct_to_actor.
       * lo_splice_actor copies data to the target page.
       * lo_splice_actor calls flush_dcache_page because the page may be
         mapped by userspace.  In that case we need to flush the kernel cache.
       * flush_dcache_page asks for the list of userspace mappings, however
         that page->mapping field is reused by the slab subsystem for a
         different purpose.  This causes the crash.
      Note that other architectures without coherent caches (sparc, arm, mips)
      also call page_mapping from flush_dcache_page, so they may crash in the
      same way.
      This patch fixes this bug by testing if the page is a slab page in
      page_mapping and returning NULL if it is.
      The patch also fixes VM_BUG_ON(PageSlab(page)) that could happen in
      earlier kernels in the same scenario on architectures without cache
      coherence when CONFIG_DEBUG_VM is enabled - so it should be backported
      to stable kernels.
      In the old kernels, the function page_mapping is placed in
      include/linux/mm.h, so you should modify the patch accordingly when
      backporting it.
      Signed-off-by: default avatarMikulas Patocka <mpatocka@redhat.com>
      Cc: John David Anglin <dave.anglin@bell.net>]
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Christoph Lameter <cl@linux.com>
      Acked-by: default avatarPekka Enberg <penberg@kernel.org>
      Reviewed-by: default avatarJoonsoo Kim <iamjoonsoo.kim@lge.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Aaro Koskinen's avatar
      MIPS: fix blast_icache32 on loongson2 · 43a06847
      Aaro Koskinen authored
      Commit 14bd8c08
       ("MIPS: Loongson: Get rid of Loongson 2 #ifdefery
      all over arch/mips") failed to add Loongson2 specific blast_icache32
      functions.  Fix that.
      The patch fixes the following crash seen with 3.13-rc1:
        Reserved instruction in kernel code[#1]:
        Call Trace:
        Code: 00200825  64834000  00200825 <bc900000> bc900020  bc900040  bc900060  bc900080  bc9000a0
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Reviewed-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      Acked-by: default avatarJohn Crispin <blogic@openwrt.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Huacai Chen's avatar
      MIPS: fix case mismatch in local_r4k_flush_icache_range() · bad009fe
      Huacai Chen authored
      Currently, Loongson-2 call protected_blast_icache_range() and others
      call protected_loongson23_blast_icache_range(), but I think the correct
      behavior should be the opposite.  BTW, Loongson-3's cache-ops is
      compatible with MIPS64, but not compatible with Loongson-2.  So, rename
      xxx_loongson23_yyy things to xxx_loongson2_yyy.
      The patch fixes early boot hang with 3.13-rc1, introduced in commit
       ("MIPS: Loongson: Get rid of Loongson 2 #ifdefery all over
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Signed-off-by: default avatarAaro Koskinen <aaro.koskinen@iki.fi>
      Reviewed-by: default avatarAurelien Jarno <aurelien@aurel32.net>
      Acked-by: default avatarJohn Crispin <blogic@openwrt.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Andreas Rohner's avatar
      nilfs2: fix segctor bug that causes file system corruption · 70f2fe3a
      Andreas Rohner authored
      There is a bug in the function nilfs_segctor_collect, which results in
      active data being written to a segment, that is marked as clean.  It is
      possible, that this segment is selected for a later segment
      construction, whereby the old data is overwritten.
      The problem shows itself with the following kernel log message:
        nilfs_sufile_do_cancel_free: segment 6533 must be clean
      Usually a few hours later the file system gets corrupted:
        NILFS: bad btree node (blocknr=8748107): level = 0, flags = 0x0, nchildren = 0
        NILFS error (device sdc1): nilfs_bmap_last_key: broken bmap (inode number=114660)
      The issue can be reproduced with a file system that is nearly full and
      with the cleaner running, while some IO intensive task is running.
      Although it is quite hard to reproduce.
      This is what happens:
       1. The cleaner starts the segment construction
       2. nilfs_segctor_collect is called
       3. sc_stage is on NILFS_ST_SUFILE and segments are freed
       4. sc_stage is on NILFS_ST_DAT current segment is full
       5. nilfs_segctor_extend_segments is called, which
          allocates a new segment
       6. The new segment is one of the segments freed in step 3
       7. nilfs_sufile_cancel_freev is called and produces an error message
       8. Loop around and the collection starts again
       9. sc_stage is on NILFS_ST_SUFILE and segments are freed
          including the newly allocated segment, which will contain active
          data and can be allocated at a later time
      10. A few hours later another segment construction allocates the
          segment and causes file system corruption
      This can be prevented by simply reordering the statements.  If
      nilfs_sufile_cancel_freev is called before nilfs_segctor_extend_segments
      the freed segments are marked as dirty and cannot be allocated any more.
      Signed-off-by: default avatarAndreas Rohner <andreas.rohner@gmx.net>
      Reviewed-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Tested-by: default avatarAndreas Rohner <andreas.rohner@gmx.net>
      Signed-off-by: default avatarRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Ingo Molnar's avatar
      Merge branch 'clockevents/3.13-fixes' of... · e59da0ae
      Ingo Molnar authored
      Merge branch 'clockevents/3.13-fixes' of git://git.linaro.org/people/daniel.lezcano/linux
       into timers/urgent
      Pull clock driver fix from Daniel Lezcano:
       " * Soren Brinkmann fixed the cadence_ttc driver where a call to
           clk_get_rate happens in an interrupt context. More precisely in an IPI
           when the broadcast timer is initialized for each cpu in the cpuidle
           driver. "
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Dave Airlie's avatar
      Merge branch 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6 into drm-fixes · 703a8c2d
      Dave Airlie authored
      Single regression fix for nouveau
      * 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6:
        drm/nouveau: fix null ptr dereferences on some boards
    • Ben Skeggs's avatar
      drm/nouveau: fix null ptr dereferences on some boards · fdd239ac
      Ben Skeggs authored
      Regression from "device: populate master subdev pointer only when fully
      Reported-by: default avatarBob Gleitsmann <rjgleits@bellsouth.net>
      Signed-off-by: default avatarBen Skeggs <bskeggs@redhat.com>
  4. 14 Jan, 2014 10 commits
    • Jean Delvare's avatar
      hwmon: (coretemp) Fix truncated name of alarm attributes · 3f9aec76
      Jean Delvare authored
      When the core number exceeds 9, the size of the buffer storing the
      alarm attribute name is insufficient and the attribute name is
      truncated. This causes libsensors to skip these attributes as the
      truncated name is not recognized.
      Reported-by: default avatarAndreas Hollmann <hollmann@in.tum.de>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGuenter Roeck <linux@roeck-us.net>
    • Stephen Warren's avatar
      i2c: Re-instate body of i2c_parent_is_i2c_adapter() · 2fac2b89
      Stephen Warren authored
      The body of i2c_parent_is_i2c_adapter() is currently guarded by
      I2C_MUX. It should be CONFIG_I2C_MUX instead.
      Among potentially other problems, this resulted in i2c_lock_adapter()
      only locking I2C mux child adapters, and not the parent adapter. In
      turn, this could allow inter-mingling of mux child selection and I2C
      transactions, which could result in I2C transactions being directed to
      the wrong I2C bus, and possibly even switching between busses in the
      middle of a transaction.
      One concrete issue caused by this bug was corrupted HDMI EDID reads
      during boot on the NVIDIA Tegra Seaboard system, although this only
      became apparent in recent linux-next, when the boot timing was changed
      just enough to trigger the race condition.
      Fixes: 3923172b
       ("i2c: reduce parent checking to a NOOP in non-I2C_MUX case")
      Cc: Phil Carmody <phil.carmody@partner.samsung.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: Stephen Warren's avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
    • NeilBrown's avatar
      md: fix problem when adding device to read-only array with bitmap. · 8313b8e5
      NeilBrown authored
      If an array is started degraded, and then the missing device
      is found it can be re-added and a minimal bitmap-based recovery
      will bring it fully up-to-date.
      If the array is read-only a recovery would not be allowed.
      But also if the array is read-only and the missing device was
      present very recently, then there could be no need for any
      recovery at all, so we simply include the device in the read-only
      array without any recovery.
      However... if the missing device was removed a little longer ago
      it could be missing some updates, but if a bitmap is present it will
      be conditionally accepted pending a bitmap-based update.  We don't
      currently detect this case properly and will include that old
      device into the read-only array with no recovery even though it really
      needs a recovery.
      This patch keeps track of whether a bitmap-based-recovery is really
      needed or not in the new Bitmap_sync rdev flag.  If that is set,
      then the device will not be added to a read-only array.
      Cc: Andrei Warkentin <andreiw@vmware.com>
      Fixes: d70ed2e4
      Cc: stable@vger.kernel.org (3.2+)
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    • NeilBrown's avatar
      md/raid10: fix bug when raid10 recovery fails to recover a block. · e8b84915
      NeilBrown authored
      commit e875ecea
          md/raid10 record bad blocks as needed during recovery.
      added code to the "cannot recover this block" path to record a bad
      block rather than fail the whole recovery.
      Unfortunately this new case was placed *after* r10bio was freed rather
      than *before*, yet it still uses r10bio.
      This is will crash with a null dereference.
      So move the freeing of r10bio down where it is safe.
      Cc: stable@vger.kernel.org (v3.1+)
      Fixes: e875ecea
      Reported-by: default avatarDamian Nowak <spam@nowaker.net>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    • NeilBrown's avatar
      md/raid5: fix a recently broken BUG_ON(). · 5af9bef7
      NeilBrown authored
      commit 6d183de4
          md/raid5: fix newly-broken locking in get_active_stripe.
      simplified a BUG_ON, but removed too much so now it sometimes fires
      when it shouldn't.
      When the STRIPE_EXPANDING flag is set, the stripe_head might be on a
      special list while multiple stripe_heads are collected, or it might
      not be on any list, even a 'free' list when the refcount is zero.  As
      long as STRIPE_EXPANDING is set, it will be found and added back to a
      list eventually.
      So both of the BUG_ONs which test for the ->lru being empty or not
      need to avoid the case where STRIPE_EXPANDING is set.
      The patch which broke this was marked for -stable, so this patch needs
      to be applied to any branch that received 6d183de4
      Fixes: 6d183de4
      Cc: stable@vger.kernel.org (any release to which above was applied)
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    • NeilBrown's avatar
      md/raid1: fix request counting bug in new 'barrier' code. · 41a336e0
      NeilBrown authored
      The new iobarrier implementation in raid1 (which keeps normal writes
      and resync activity separate) counts every request what is not before
      the current resync point in either next_window_requests or
      It flags that the request is counted by setting ->start_next_window.
      allow_barrier follows this model exactly and decrements one of the
      *_window_requests if and only if ->start_next_window is set.
      However wait_barrier(), which increments *_window_requests uses a
      slightly different test for setting -.start_next_window (which is set
      from the return value of this function).
      So there is a possibility of the counts getting out of sync, and this
      leads to the resync hanging.
      So change wait_barrier() to return a non-zero value in exactly the
      same cases that it increments *_window_requests.
      But was introduced in 3.13-rc1.
      Reported-by: default avatarBruno Wolff III <bruno@wolff.to>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68061
      Fixes: 79ef3a8a
      Cc: majianpeng <majianpeng@gmail.com>
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    • NeilBrown's avatar
      md/raid10: fix two bugs in handling of known-bad-blocks. · b50c259e
      NeilBrown authored
      If we discover a bad block when reading we split the request and
      potentially read some of it from a different device.
      The code path of this has two bugs in RAID10.
      1/ we get a spin_lock with _irq, but unlock without _irq!!
      2/ The calculation of 'sectors_handled' is wrong, as can be clearly
         seen by comparison with raid1.c
      This leads to at least 2 warnings and a probable crash is a RAID10
      ever had known bad blocks.
      Cc: stable@vger.kernel.org (v3.1+)
      Fixes: 856e08e2
      Reported-by: default avatarDamian Nowak <spam@nowaker.net>
      URL: https://bugzilla.kernel.org/show_bug.cgi?id=68181
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    • NeilBrown's avatar
      md/raid5: Fix possible confusion when multiple write errors occur. · 1cc03eb9
      NeilBrown authored
      commit 5d8c71f9
          md: raid5 crash during degradation
      Fixed a crash in an overly simplistic way which could leave
      R5_WriteError or R5_MadeGood set in the stripe cache for devices
      for which it is no longer relevant.
      When those devices are removed and spares added the flags are still
      set and can cause incorrect behaviour.
      commit 14a75d3e
          md/raid5: preferentially read from replacement device if possible.
      Fixed the same bug if a more effective way, so we can now revert
      the original commit.
      Reported-and-tested-by: default avatarAlexander Lyakas <alex.bolshoy@gmail.com>
      Cc: stable@vger.kernel.org (3.2+ - 3.2 will need a different fix though)
      Fixes: 5d8c71f9
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
    • Dave Airlie's avatar
      Revert "drm: copy mode type in drm_mode_connector_list_update()" · abce1ec9
      Dave Airlie authored
      This reverts commit 3fbd6439
      This caused some strange booting lockup issues on an Intel G33
      belonging to Daniel Vetter, very unusual, I was hoping Daniel
      would track this down, but it looks like instead I'll have to hack
      a different fix for -next.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
    • Dave Airlie's avatar
      Merge tag 'drm-intel-fixes-2014-01-13' of... · c0eeb856
      Dave Airlie authored
      Merge tag 'drm-intel-fixes-2014-01-13' of git://people.freedesktop.org/~danvet/drm-intel into drm-fixes
      Black screen fixes, one for hsw+bdw each and a regression fix for
      locking+load detection.
      * tag 'drm-intel-fixes-2014-01-13' of git://people.freedesktop.org/~danvet/drm-intel:
        drm/i915/bdw: make sure south port interrupts are enabled properly v2
        drm/i915: Don't grab crtc mutexes in intel_modeset_gem_init()
        drm/i915: fix DDI PLLs HW state readout code
  5. 13 Jan, 2014 2 commits
  6. 12 Jan, 2014 9 commits
    • Benjamin Herrenschmidt's avatar
      powerpc: Check return value of instance-to-package OF call · 10348f59
      Benjamin Herrenschmidt authored
      On PA-Semi firmware, the instance-to-package callback doesn't seem
      to be implemented. We didn't check for error, however, thus
      subsequently passed the -1 value returned into stdout_node to
      thins like prom_getprop etc...
      Thus caused the firmware to load values around 0 (physical) internally
      as node structures. It somewhat "worked" as long as we had a NULL in the
      right place (address 8) at the beginning of the kernel, we didn't "see"
      the bug. But commit 5c0484e2
      "powerpc: Endian safe trampoline" changed the kernel entry point causing
      that old bug to now cause a crash early during boot.
      This fixes booting on PA-Semi board by properly checking the return
      value from instance-to-package.
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Tested-by: default avatarOlof Johansson <olof@lixom.net>
    • Taras Kondratiuk's avatar
      ARM: 7938/1: OMAP4/highbank: Flush L2 cache before disabling · b25f3e1c
      Taras Kondratiuk authored
      Kexec disables outer cache before jumping to reboot code, but it doesn't
      flush it explicitly. Flush is done implicitly inside of l2x0_disable().
      But some SoC's override default .disable handler and don't flush cache.
      This may lead to a corrupted memory during Kexec reboot on these
      This patch adds cache flush inside of OMAP4 and Highbank outer_cache.disable()
      handlers to make it consistent with default l2x0_disable().
      Acked-by: default avatarRob Herring <rob.herring@calxeda.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarTaras Kondratiuk <taras.kondratiuk@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
    • Linus Torvalds's avatar
      Linux 3.13-rc8 · 7e22e911
      Linus Torvalds authored
    • Steven Rostedt's avatar
      SELinux: Fix possible NULL pointer dereference in selinux_inode_permission() · 3dc91d43
      Steven Rostedt authored
      While running stress tests on adding and deleting ftrace instances I hit
      this bug:
        BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
        IP: selinux_inode_permission+0x85/0x160
        PGD 63681067 PUD 7ddbe067 PMD 0
        Oops: 0000 [#1] PREEMPT
        CPU: 0 PID: 5634 Comm: ftrace-test-mki Not tainted 3.13.0-rc4-test-00033-gd2a6dde-dirty #20
        Hardware name:                  /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006
        task: ffff880078375800 ti: ffff88007ddb0000 task.ti: ffff88007ddb0000
        RIP: 0010:[<ffffffff812d8bc5>]  [<ffffffff812d8bc5>] selinux_inode_permission+0x85/0x160
        RSP: 0018:ffff88007ddb1c48  EFLAGS: 00010246
        RAX: 0000000000000000 RBX: 0000000000800000 RCX: ffff88006dd43840
        RDX: 0000000000000001 RSI: 0000000000000081 RDI: ffff88006ee46000
        RBP: ffff88007ddb1c88 R08: 0000000000000000 R09: ffff88007ddb1c54
        R10: 6e6576652f6f6f66 R11: 0000000000000003 R12: 0000000000000000
        R13: 0000000000000081 R14: ffff88006ee46000 R15: 0000000000000000
        FS:  00007f217b5b6700(0000) GS:ffffffff81e21000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033^M
        CR2: 0000000000000020 CR3: 000000006a0fe000 CR4: 00000000000007f0
        Call Trace:
        Code: 84 a1 00 00 00 81 e3 00 20 00 00 89 d8 83 c8 02 40 f6 c6 04 0f 45 d8 40 f6 c6 08 74 71 80 cf 02 49 8b 46 38 4c 8d 4d cc 45 31 c0 <0f> b7 50 20 8b 70 1c 48 8b 41 70 89 d9 8b 78 04 e8 36 cf ff ff
        RIP  selinux_inode_permission+0x85/0x160
        CR2: 0000000000000020
      Investigating, I found that the inode->i_security was NULL, and the
      dereference of it caused the oops.
      in selinux_inode_permission():
      	isec = inode->i_security;
      	rc = avc_has_perm_noaudit(sid, isec->sid, isec->sclass, perms, 0, &avd);
      Note, the crash came from stressing the deletion and reading of debugfs
      files.  I was not able to recreate this via normal files.  But I'm not
      sure they are safe.  It may just be that the race window is much harder
      to hit.
      What seems to have happened (and what I have traced), is the file is
      being opened at the same time the file or directory is being deleted.
      As the dentry and inode locks are not held during the path walk, nor is
      the inodes ref counts being incremented, there is nothing saving these
      structures from being discarded except for an rcu_read_lock().
      The rcu_read_lock() protects against freeing of the inode, but it does
      not protect freeing of the inode_security_struct.  Now if the freeing of
      the i_security happens with a call_rcu(), and the i_security field of
      the inode is not changed (it gets freed as the inode gets freed) then
      there will be no issue here.  (Linus Torvalds suggested not setting the
      field to NULL such that we do not need to check if it is NULL in the
      permission check).
      Note, this is a hack, but it fixes the problem at hand.  A real fix is
      to restructure the destroy_inode() to call all the destructor handlers
      from the RCU callback.  But that is a major job to do, and requires a
      lot of work.  For now, we just band-aid this bug with this fix (it
      works), and work on a more maintainable solution in the future.
      Link: http://lkml.kernel.org/r/20140109101932.0508dec7@gandalf.local.home
      Link: http://lkml.kernel.org/r/20140109182756.17abaaa8@gandalf.local.home
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Hugh Dickins's avatar
      thp: fix copy_page_rep GPF by testing is_huge_zero_pmd once only · eecc1e42
      Hugh Dickins authored
      We see General Protection Fault on RSI in copy_page_rep: that RSI is
      what you get from a NULL struct page pointer.
        RIP: 0010:[<ffffffff81154955>]  [<ffffffff81154955>] copy_page_rep+0x5/0x10
        RSP: 0000:ffff880136e15c00  EFLAGS: 00010286
        RAX: ffff880000000000 RBX: ffff880136e14000 RCX: 0000000000000200
        RDX: 6db6db6db6db6db7 RSI: db73880000000000 RDI: ffff880dd0c00000
        RBP: ffff880136e15c18 R08: 0000000000000200 R09: 000000000005987c
        R10: 000000000005987c R11: 0000000000000200 R12: 0000000000000001
        R13: ffffea00305aa000 R14: 0000000000000000 R15: 0000000000000000
        FS:  00007f195752f700(0000) GS:ffff880c7fc20000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
        CR2: 0000000093010000 CR3: 00000001458e1000 CR4: 00000000000027e0
        Call Trace:
      do_huge_pmd_wp_page() tests is_huge_zero_pmd(orig_pmd) four times: but
      since shrink_huge_zero_page() can free the huge_zero_page, and we have
      no hold of our own on it here (except where the fourth test holds
      page_table_lock and has checked pmd_same), it's possible for it to
      answer yes the first time, but no to the second or third test.  Change
      all those last three to tests for NULL page.
      (Note: this is not the same issue as trinity's DEBUG_PAGEALLOC BUG
      in copy_page_rep with RSI: ffff88009c422000, reported by Sasha Levin
      in https://lkml.org/lkml/2013/3/29/103.  I believe that one is due
      to the source page being split, and a tail page freed, while copy
      is in progress; and not a problem without DEBUG_PAGEALLOC, since
      the pmd_same check will prevent a miscopy from being made visible.)
      Fixes: 97ae1749
       ("thp: implement refcounting for huge zero page")
      Signed-off-by: default avatarHugh Dickins <hughd@google.com>
      Cc: stable@vger.kernel.org # v3.10 v3.11 v3.12
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • Ming Lei's avatar
      block: null_blk: fix queue leak inside removing device · 518d00b7
      Ming Lei authored
      When queue_mode is NULL_Q_MQ and null_blk is being removed,
      blk_cleanup_queue() isn't called to cleanup queue, so the queue
      allocated won't be freed.
      This patch calls blk_cleanup_queue() for MQ to drain all pending
      requests first and release the reference counter of queue kobject, then
      blk_mq_free_queue() will be called in queue kobject's release handler
      when queue kobject's reference counter drops to zero.
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    • John Stultz's avatar
      sched_clock: Disable seqlock lockdep usage in sched_clock() · 7a06c41c
      John Stultz authored
      Unfortunately the seqlock lockdep enablement can't be used
      in sched_clock(), since the lockdep infrastructure eventually
      calls into sched_clock(), which causes a deadlock.
      Thus, this patch changes all generic sched_clock() usage
      to use the raw_* methods.
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Reported-by: default avatarKrzysztof Hałasa <khalasa@piap.pl>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Cc: Willy Tarreau <w@1wt.eu>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1388704274-5278-2-git-send-email-john.stultz@linaro.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • John Stultz's avatar
      seqlock: Use raw_ prefix instead of _no_lockdep · 0c3351d4
      John Stultz authored
      Linus disliked the _no_lockdep() naming, so instead
      use the more-consistent raw_* prefix to the non-lockdep
      enabled seqcount methods.
      This also adds raw_ methods for the write operations
      as well, which will be utilized in a following patch.
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Krzysztof Hałasa <khalasa@piap.pl>
      Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Cc: Willy Tarreau <w@1wt.eu>
      Link: http://lkml.kernel.org/r/1388704274-5278-1-git-send-email-john.stultz@linaro.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Rik van Riel's avatar
      sched: Calculate effective load even if local weight is 0 · 9722c2da
      Rik van Riel authored
      Thomas Hellstrom bisected a regression where erratic 3D performance is
      experienced on virtual machines as measured by glxgears. It identified
      commit 58d081b5 ("sched/numa: Avoid overloading CPUs on a preferred NUMA
      node") as the problem which had modified the behaviour of effective_load.
      Effective load calculates the difference to the system-wide load if a
      scheduling entity was moved to another CPU. The task group is not heavier
      as a result of the move but overall system load can increase/decrease as a
      result of the change. Commit 58d081b5 ("sched/numa: Avoid overloading CPUs
      on a preferred NUMA node") changed effective_load to make it suitable for
      calculating if a particular NUMA node was compute overloaded. To reduce
      the cost of the function, it assumed that a current sched entity weight
      of 0 was uninteresting but that is not the case.
      wake_affine() uses a weight of 0 for sync wakeups on the grounds that it
      is assuming the waking task will sleep and not contribute to load in the
      near future. In this case, we still want to calculate the effective load
      of the sched entity hierarchy. As effective_load is no longer used by
      task_numa_compare since commit fb13c7ee
       (sched/numa: Use a system-wide
      search to find swap/migration candidates), this patch simply restores the
      historical behaviour.
      Reported-and-tested-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Signed-off-by: default avatarRik van Riel <riel@redhat.com>
      [ Wrote changelog]
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20140106113912.GC6178@suse.de
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>