1. 09 Dec, 2015 6 commits
  2. 09 Nov, 2015 24 commits
  3. 27 Oct, 2015 10 commits
    • Greg Kroah-Hartman's avatar
      Linux 3.10.92 · d17332eb
      Greg Kroah-Hartman authored
      d17332eb
    • Ilya Dryomov's avatar
      rbd: fix double free on rbd_dev->header_name · f2271406
      Ilya Dryomov authored
      commit 3ebe138a upstream.
      
      If rbd_dev_image_probe() in rbd_dev_probe_parent() fails, header_name
      is freed twice: once in rbd_dev_probe_parent() and then in its caller
      rbd_dev_image_probe() (rbd_dev_image_probe() is called recursively to
      handle parent images).
      
      rbd_dev_probe_parent() is responsible for probing the parent, so it
      shouldn't muck with clone's fields.
      Signed-off-by: default avatarIlya Dryomov <idryomov@gmail.com>
      Reviewed-by: default avatarAlex Elder <elder@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2271406
    • Mike Snitzer's avatar
      dm thin: fix missing pool reference count decrement in pool_ctr error path · ad824a82
      Mike Snitzer authored
      commit ba30670f upstream.
      
      Fixes: ac8c3f3d ("dm thin: generate event when metadata threshold passed")
      Signed-off-by: default avatarMike Snitzer <snitzer@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ad824a82
    • Shaohua Li's avatar
      workqueue: make sure delayed work run in local cpu · 334c9407
      Shaohua Li authored
      commit 874bbfe6 upstream.
      
      My system keeps crashing with below message. vmstat_update() schedules a delayed
      work in current cpu and expects the work runs in the cpu.
      schedule_delayed_work() is expected to make delayed work run in local cpu. The
      problem is timer can be migrated with NO_HZ. __queue_work() queues work in
      timer handler, which could run in a different cpu other than where the delayed
      work is scheduled. The end result is the delayed work runs in different cpu.
      The patch makes __queue_delayed_work records local cpu earlier. Where the timer
      runs doesn't change where the work runs with the change.
      
      [   28.010131] ------------[ cut here ]------------
      [   28.010609] kernel BUG at ../mm/vmstat.c:1392!
      [   28.011099] invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN
      [   28.011860] Modules linked in:
      [   28.012245] CPU: 0 PID: 289 Comm: kworker/0:3 Tainted: G        W4.3.0-rc3+ #634
      [   28.013065] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153802- 04/01/2014
      [   28.014160] Workqueue: events vmstat_update
      [   28.014571] task: ffff880117682580 ti: ffff8800ba428000 task.ti: ffff8800ba428000
      [   28.015445] RIP: 0010:[<ffffffff8115f921>]  [<ffffffff8115f921>]vmstat_update+0x31/0x80
      [   28.016282] RSP: 0018:ffff8800ba42fd80  EFLAGS: 00010297
      [   28.016812] RAX: 0000000000000000 RBX: ffff88011a858dc0 RCX:0000000000000000
      [   28.017585] RDX: ffff880117682580 RSI: ffffffff81f14d8c RDI:ffffffff81f4df8d
      [   28.018366] RBP: ffff8800ba42fd90 R08: 0000000000000001 R09:0000000000000000
      [   28.019169] R10: 0000000000000000 R11: 0000000000000121 R12:ffff8800baa9f640
      [   28.019947] R13: ffff88011a81e340 R14: ffff88011a823700 R15:0000000000000000
      [   28.020071] FS:  0000000000000000(0000) GS:ffff88011a800000(0000)knlGS:0000000000000000
      [   28.020071] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [   28.020071] CR2: 00007ff6144b01d0 CR3: 00000000b8e93000 CR4:00000000000006f0
      [   28.020071] Stack:
      [   28.020071]  ffff88011a858dc0 ffff8800baa9f640 ffff8800ba42fe00ffffffff8106bd88
      [   28.020071]  ffffffff8106bd0b 0000000000000096 0000000000000000ffffffff82f9b1e8
      [   28.020071]  ffffffff829f0b10 0000000000000000 ffffffff81f18460ffff88011a81e340
      [   28.020071] Call Trace:
      [   28.020071]  [<ffffffff8106bd88>] process_one_work+0x1c8/0x540
      [   28.020071]  [<ffffffff8106bd0b>] ? process_one_work+0x14b/0x540
      [   28.020071]  [<ffffffff8106c214>] worker_thread+0x114/0x460
      [   28.020071]  [<ffffffff8106c100>] ? process_one_work+0x540/0x540
      [   28.020071]  [<ffffffff81071bf8>] kthread+0xf8/0x110
      [   28.020071]  [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200
      [   28.020071]  [<ffffffff81a6522f>] ret_from_fork+0x3f/0x70
      [   28.020071]  [<ffffffff81071b00>] ?kthread_create_on_node+0x200/0x200
      Signed-off-by: default avatarShaohua Li <shli@fb.com>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      334c9407
    • Wolfram Sang's avatar
      i2c: rcar: enable RuntimePM before registering to the core · 49d851ce
      Wolfram Sang authored
      commit 4f7effdd upstream.
      
      The core may register clients attached to this master which may use
      funtionality from the master. So, RuntimePM must be enabled before, otherwise
      this will fail. While here, move drvdata, too.
      Reported-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarWolfram Sang <wsa+renesas@sang-engineering.com>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      49d851ce
    • Russell King's avatar
      crypto: ahash - ensure statesize is non-zero · 2aafe811
      Russell King authored
      commit 8996eafd upstream.
      
      Unlike shash algorithms, ahash drivers must implement export
      and import as their descriptors may contain hardware state and
      cannot be exported as is.  Unfortunately some ahash drivers did
      not provide them and end up causing crashes with algif_hash.
      
      This patch adds a check to prevent these drivers from registering
      ahash algorithms until they are fixed.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2aafe811
    • Dave Kleikamp's avatar
      crypto: sparc - initialize blkcipher.ivsize · 29e5b424
      Dave Kleikamp authored
      commit a66d7f72 upstream.
      
      Some of the crypto algorithms write to the initialization vector,
      but no space has been allocated for it. This clobbers adjacent memory.
      Signed-off-by: default avatarDave Kleikamp <dave.kleikamp@oracle.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29e5b424
    • Geert Uytterhoeven's avatar
      m68k/uaccess: Fix asm constraints for userspace access · 31e29b7b
      Geert Uytterhoeven authored
      commit 631d8b67 upstream.
      
      When compiling a MMU kernel with CPU_HAS_ADDRESS_SPACES=n (e.g. "MMU=y
      allnoconfig": "echo CONFIG_MMU=y > allno.config && make KCONFIG_ALLCONFIG=1
      allnoconfig"), we use plain "move" instead of "moves", and I got:
      
        CC      arch/m68k/lib/uaccess.o
      {standard input}: Assembler messages:
      {standard input}:47: Error: operands mismatch -- statement `move.b %a0,(%a1)' ignored
      
      This happens because plain "move" doesn't support byte transfers between
      memory and address registers, while "moves" does.
      
      Fix the asm constraints for __generic_copy_from_user(),
      __generic_copy_to_user(), and __clear_user() to only use data registers
      when accessing userspace.
      
      Also, relax the asm constraints for 16-bit userspace accesses in
      __put_user() and __get_user(), as both "move" and "moves" do support
      such transfers between memory and address registers.
      Signed-off-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      31e29b7b
    • Charles Keepax's avatar
      asix: Do full reset during ax88772_bind · 37673fd3
      Charles Keepax authored
      [ Upstream commit 436c2a50 ]
      
      commit 3cc81d85 ("asix: Don't reset PHY on if_up for ASIX 88772")
      causes the ethernet on Arndale to no longer function. This appears to
      be because the Arndale ethernet requires a full reset before it will
      function correctly, however simply reverting the above patch causes
      problems with ethtool settings getting reset.
      
      It seems the problem is that the ethernet is not properly reset during
      bind, and indeed the code in ax88772_bind that resets the device is a
      very small subset of the actual ax88772_reset function. This patch uses
      ax88772_reset in place of the existing reset code in ax88772_bind which
      removes some code duplication and fixes the ethernet on Arndale.
      
      It is still possible that the original patch causes some issues with
      suspend and resume but that seems like a separate issue and I haven't
      had a chance to test that yet.
      Signed-off-by: default avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Tested-by: default avatarRiku Voipio <riku.voipio@linaro.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37673fd3
    • Michel Stam's avatar
      asix: Don't reset PHY on if_up for ASIX 88772 · d54ee99a
      Michel Stam authored
      [ Upstream commit 3cc81d85 ]
      
      I've noticed every time the interface is set to 'up,', the kernel
      reports that the link speed is set to 100 Mbps/Full Duplex, even
      when ethtool is used to set autonegotiation to 'off', half
      duplex, 10 Mbps.
      It can be tested by:
       ifconfig eth0 down
       ethtool -s eth0 autoneg off speed 10 duplex half
       ifconfig eth0 up
      
      Then checking 'dmesg' for the link speed.
      Signed-off-by: default avatarMichel Stam <m.stam@fugro.nl>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d54ee99a