linux-kernel - Re: possible deadlock in generic_file_write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 6 Nov 2017 09:32:35 +0300
From:   Dmitry Vyukov <dvyukov@...gle.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     syzbot 
        <bot+f99f3a0db9007f4f4e32db54229a240c4fe57c15@...kaller.appspotmail.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Johannes Weiner <hannes@...xchg.org>, Jan Kara <jack@...e.cz>,
        jlayton@...hat.com, LKML <linux-kernel@...r.kernel.org>,
        linux-mm@...ck.org, npiggin@...il.com, rgoldwyn@...e.com,
        ross.zwisler@...ux.intel.com, syzkaller-bugs@...glegroups.com
Subject: Re: possible deadlock in generic_file_write_iter

On Mon, Nov 6, 2017 at 6:29 AM, Al Viro <viro@...iv.linux.org.uk> 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?