On Mon 06-11-17 09:32:35, Dmitry Vyukov wrote:
> On Mon, Nov 6, 2017 at 6:29 AM, Al Viro <viro@xxxxxxxxxxxxxxxxxx> wrote:
> > On Sun, Nov 05, 2017 at 02:25:00AM -0800, syzbot wrote:
> >
> >> loop0/2986 is trying to acquire lock:
> >> (&sb->s_type->i_mutex_key#9){++++}, at: [<ffffffff8186f9ec>] inode_lock
> >> include/linux/fs.h:712 [inline]
> >> (&sb->s_type->i_mutex_key#9){++++}, at: [<ffffffff8186f9ec>]
> >> generic_file_write_iter+0xdc/0x7a0 mm/filemap.c:3151
> >>
> >> but now in release context of a crosslock acquired at the following:
> >> ((complete)&ret.event){+.+.}, at: [<ffffffff822a055e>]
> >> submit_bio_wait+0x15e/0x200 block/bio.c:953
> >>
> >> which lock already depends on the new lock.
> >
> > Almost certainly a false positive... lockdep can't tell ->i_rwsem of
> > inode on filesystem that lives on /dev/loop0 and that of inode of
> > the backing file of /dev/loop0.
> >
> > Try and put them on different filesystem types and see if you still
> > can reproduce that. We do have a partial ordering between the filesystems,
> > namely "(parts of) hosting device of X live in a file on Y". It's
> > going to be acyclic, or you have a much worse problem. And that's
> > what really orders the things here.
>
> Should we annotate these inodes with different lock types? Or use
> nesting annotations?
Well, you'd need to have a completely separate set of locking classes for
each filesystem to avoid false positives like these. And that would
increase number of classes lockdep has to handle significantly. So I'm not
sure it's really worth it...
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
