[dm-devel] Re: dm: bind new table before destroying old

[Alasdair G Kergon]

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