Re: lockdep complaint from ckpt-v15

[Nathan Lynch <ntl-e+AXbWqSrlAAvxtiuMwx3w@public.gmane.org>]

Oren Laadan <orenl-eQaUEPhvms7ENvBUuze7eA@public.gmane.org> writes:
> Hi Nathan,
>
> This was observed before:
> https://lists.linux-foundation.org/pipermail/containers/2009-February/015595.html
> (and you replied :)

Heh, thought it seemed familiar.


> I believe it's a false alarm: the code takes the pipe's inode mutexthen takes
> the same mutex (of a different inode) when writing data out
> to the output file descriptor.
>
> This could create a deadlock if the user provides the pipe's fd as the output
> file; Howver, I protects against that by explicitly checking that the file of
> the pipe isn't the file in ctx->file.

That will prevent deadlock on that one inode, yes, but I believe lockdep
is pointing to a different problem.  Locks of the same class have to be
acquired in some pre-determined order, and lockdep has to be taught that
order.  In other words, if it's okay to acquire these inode mutexes in
this order, it must be forbidden to acquire them in the reverse order.
Otherwise you have the potential for AB-BA deadlock.  At least, that's
my impression after spending some time with the lockdep and vfs locking
docs... hope I'm right :)

There are vfs operations (rename etc) which need to acquire multiple
inodes' i_mutex in the same class -- the ordering rules are expressed in
include/linux/fs.h:inode_i_mutex_lock_class and with use of
mutex_lock_nested() in e.g. fs/namei.c:lock_rename().  But I don't see
immediately how to apply these mechanisms to this situation.