lkml.org 
[lkml]   [2017]   [Nov]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: possible deadlock in generic_file_write_iter
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.

\
 
 \ /
  Last update: 2017-11-06 04:30    [W:0.710 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site