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 14:15:44 +0100
From:   Jan Kara <jack@...e.cz>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     Al Viro <viro@...iv.linux.org.uk>,
        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 06-11-17 09:32:35, Dmitry Vyukov wrote:
> 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?

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@...e.com>
SUSE Labs, CR