Testing with request based dm multipathing and lock dependency checking
revealed this problem. Fix this by disabling interrupts when acquiring the
map_lock from the ioctl call in __bind and __unbind.
It seems that the problem has been introduced with this patch:
http://lkml.indiana.edu/hypermail/linux/kernel/0810.0/1067.html
================================================== ====
[ INFO: soft-safe -> soft-unsafe lock order detected ]
2.6.27.13-1.1.mz11dbg-default #1
------------------------------------------------------
multipath/3857 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
(&md->map_lock){----}, at: [<000003e000573a0e>] dm_get_table+0x32/0x68 [dm_mod]
and this task is already holding:
(&q->__queue_lock){.+..}, at: [<000003e000573b04>] dm_resume+0xc0/0x1b8 [dm_mod]
which would create a new lock dependency:
(&q->__queue_lock){.+..} -> (&md->map_lock){----}
but this new dependency connects a soft-irq-safe lock:
(&q->__queue_lock){.+..}
... which became soft-irq-safe at:
[<00000000001633fa>] mark_irqflags+0xa6/0x154
[<0000000000165486>] __lock_acquire+0x5ea/0x780
[<0000000000165686>] lock_acquire+0x6a/0x90
[<00000000003b5f8a>] _spin_lock+0x4a/0x64
[<000003e000786fd2>] scsi_device_unbusy+0xb2/0xe4 [scsi_mod]
[<000003e00077def4>] scsi_finish_command+0x4c/0x11c [scsi_mod]
[<000003e000787278>] scsi_softirq_done+0x170/0x180 [scsi_mod]
[<00000000002a4c2a>] blk_done_softirq+0xc6/0xe4
[<000000000013c9d2>] __do_softirq+0xee/0x1ec
[<000000000010fcc8>] do_softirq+0x9c/0xd8
[<000000000013c3e6>] irq_exit+0x82/0xe0
[<00000000002fda4c>] do_IRQ+0x170/0x190
[<0000000000113c36>] io_return+0x0/0x8
[<0000000000109c10>] default_idle+0x198/0x1a8
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
02-19-2009, 02:02 AM
Kiyoshi Ueda
dm: Fix lock dependency warning for request based dm
Hi Christof,
On 2009/02/18 23:21 +0900, Christof Schmitt wrote:
> > From: Christof Schmitt <christof.schmitt@de.ibm.com>
> >
> > Testing with request based dm multipathing and lock dependency checking
> > revealed this problem. Fix this by disabling interrupts when acquiring the
> > map_lock from the ioctl call in __bind and __unbind.
> >
> > It seems that the problem has been introduced with this patch:
> > http://lkml.indiana.edu/hypermail/linux/kernel/0810.0/1067.html
Thank you for your testing request-based dm-multipath and the patch.
Attached is a patch to fix it.
Since request-based dm gets map_lock after taking queue_lock with
interrupt disabled, we have to use save/restore variant.
(By the way, although lockdep warns the deadlock possibility, currently
there should be no such code path in request-based dm where request_fn
is called from the interrupt context.)
I have done simple build and boot testings, but haven't done other
testings (e.g. stress testing) yet.
I will include this patch to the next update after such testings.
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
02-19-2009, 09:12 AM
Christof Schmitt
dm: Fix lock dependency warning for request based dm
On Thu, Feb 19, 2009 at 12:02:23PM +0900, Kiyoshi Ueda wrote:
> Hi Christof,
>
> On 2009/02/18 23:21 +0900, Christof Schmitt wrote:
> > > From: Christof Schmitt <christof.schmitt@de.ibm.com>
> > >
> > > Testing with request based dm multipathing and lock dependency checking
> > > revealed this problem. Fix this by disabling interrupts when acquiring the
> > > map_lock from the ioctl call in __bind and __unbind.
> > >
> > > It seems that the problem has been introduced with this patch:
> > > http://lkml.indiana.edu/hypermail/linux/kernel/0810.0/1067.html
>
> Thank you for your testing request-based dm-multipath and the patch.
>
> Attached is a patch to fix it.
> Since request-based dm gets map_lock after taking queue_lock with
> interrupt disabled, we have to use save/restore variant.
> (By the way, although lockdep warns the deadlock possibility, currently
> there should be no such code path in request-based dm where request_fn
> is called from the interrupt context.)
I was checking for other locking problems when this warning from
lockdep showed up. While i agree that it is only a problem in theory,
it deserves fixing to continue using lockdep.
> I have done simple build and boot testings, but haven't done other
> testings (e.g. stress testing) yet.
> I will include this patch to the next update after such testings.
Thanks for the updated patch. I will include this one in future tests.
--
Christof Schmitt
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel