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?
--
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>
