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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171106032941.GR21978@ZenIV.linux.org.uk>
Date:   Mon, 6 Nov 2017 03:29:42 +0000
From:   Al Viro <viro@...IV.linux.org.uk>
To:     syzbot 
        <bot+f99f3a0db9007f4f4e32db54229a240c4fe57c15@...kaller.appspotmail.com>
Cc:     akpm@...ux-foundation.org, hannes@...xchg.org, jack@...e.cz,
        jlayton@...hat.com, 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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ