[dm-devel] Re: dm: bind new table before destroying old
Alasdair G Kergon
agk at redhat.com
Thu Nov 19 00:50:36 UTC 2009
On Wed, Nov 11, 2009 at 06:45:55PM -0500, Mike Snitzer wrote:
> After further testing I've hit a lockdep trace. My testing was with
> handing over on the same device. I had the snapshot (of an ext3 FS)
> mounted and I was doing a sequential direct-io write to a file in the
> FS. While writing I triggered a handover with the following:
> =======================================================
> [ INFO: possible circular locking dependency detected ]
> 2.6.32-rc6-snitm #8
> -------------------------------------------------------
> dmsetup/1827 is trying to acquire lock:
> (&md->suspend_lock){+.+...}, at: [<ffffffffa00678d8>] dm_swap_table+0x2d/0x249 [dm_mod]
>
> but task is already holding lock:
> (&journal->j_barrier){+.+...}, at: [<ffffffff8119192d>] journal_lock_updates+0xe1/0xf0
>
> which lock already depends on the new lock.
I'm going to assume this is bogus - and I can't spot any annotations
available to suppress it, so people will just have to ignore it.
Suspend involves:
get suspend lock
if dev is not already suspended
get journal lock
set state "dev is suspended"
release suspend lock
Resume involves
[journal lock is held]
get suspend lock
if dev is suspended
release journal lock
set state "dev is not suspended"
release suspend lock
It looks as if lockdep sees that as a problem:
Imagine those two sections running in parallel without the "Is dev
suspended?" check, of which lockdep has no knowledge.
Alasdair
More information about the dm-devel
mailing list