Re: [PATCH -stable] block: fix ext_dev_lock lockdep report

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/11/2015 08:07 AM, Dan Williams wrote:
On Thu, Jun 11, 2015 at 12:51 AM, Jiri Slaby <jslaby@xxxxxxx> wrote:
On 06/11/2015, 05:47 AM, Dan Williams wrote:
  =================================
  [ INFO: inconsistent lock state ]
  4.1.0-rc7+ #217 Tainted: G           O
  ---------------------------------
  inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
  swapper/6/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
   (ext_devt_lock){+.?...}, at: [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70
  {SOFTIRQ-ON-W} state was registered at:
    [<ffffffff810bf6b1>] __lock_acquire+0x461/0x1e70
    [<ffffffff810c1947>] lock_acquire+0xb7/0x290
    [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
    [<ffffffff8143a07d>] blk_alloc_devt+0x6d/0xd0  <-- take the lock in process context
[..]
   [<ffffffff810bf64e>] __lock_acquire+0x3fe/0x1e70
   [<ffffffff810c00ad>] ? __lock_acquire+0xe5d/0x1e70
   [<ffffffff810c1947>] lock_acquire+0xb7/0x290
   [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
   [<ffffffff818ac3a8>] _raw_spin_lock+0x38/0x50
   [<ffffffff8143a60c>] ? blk_free_devt+0x3c/0x70
   [<ffffffff8143a60c>] blk_free_devt+0x3c/0x70    <-- take the lock in softirq
   [<ffffffff8143bfec>] part_release+0x1c/0x50
   [<ffffffff8158edf6>] device_release+0x36/0xb0
   [<ffffffff8145ac2b>] kobject_cleanup+0x7b/0x1a0
   [<ffffffff8145aad0>] kobject_put+0x30/0x70
   [<ffffffff8158f147>] put_device+0x17/0x20
   [<ffffffff8143c29c>] delete_partition_rcu_cb+0x16c/0x180
   [<ffffffff8143c130>] ? read_dev_sector+0xa0/0xa0
   [<ffffffff810e0e0f>] rcu_process_callbacks+0x2ff/0xa90
   [<ffffffff810e0dcf>] ? rcu_process_callbacks+0x2bf/0xa90
   [<ffffffff81067e2e>] __do_softirq+0xde/0x600

Neil sees this in his tests and it also triggers on pmem driver unbind
for the libnvdimm tests.  This fix is on top of an initial fix by Keith
for incorrect usage of mutex_lock() in this path: 2da78092dda1 "block:
Fix dev_t minor allocation lifetime".  Both this and 2da78092dda1 are
candidates for -stable.

And what is *this* in terms of SHA? Thanks.

Whatever it becomes when applied by Jens, i.e. self-referencing.

4d66e5e9b6d720d8463e11d027bd4ad91c8b1318

--
Jens Axboe

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]