Re: possible deadlock in shmem_fallocate (2)

2019-01-22 Thread Joel Fernandes 
On Tue, Jan 22, 2019 at 04:40:57PM +0100, Dmitry Vyukov wrote:
> On Tue, Jan 22, 2019 at 4:34 PM Joel Fernandes  wrote:
> >
> > On Tue, Jan 22, 2019 at 02:59:29PM +0100, Dmitry Vyukov wrote:
> > > On Fri, Aug 10, 2018 at 6:18 PM Matthew Wilcox  
> > > wrote:
> > > >
> > > >
> > > > This is another ashmem lockdep splat.  Forwarding to the appropriate 
> > > > ashmem
> > > > people.
> > >
> > >
> > > Let's test Tetsuo's patch
> > >
> > > #syz test: 
> > > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > > master
> >
> > Just to clarify, the following patch only went in, in September:
> > mm: shmem.c: Correctly annotate new inodes for lockdep
> 
> Is it supposed to fix this bug? This bug still happens: last time 5 hours ago:
> 
> https://syzkaller.appspot.com/bug?extid=4b8b031b89e6b96c4b2e

Ok, thanks for confirming. It looks like there is more than one issue causing
the same splat. It fixes one subset of the issues.

Tetsuo's patch will fix it for sure though, lets discuss that on the other
thread. Thanks,

 - Joel


> > thanks,
> >
> >  - Joel
> >
> >
> > > > On Fri, Aug 10, 2018 at 04:59:02AM -0700, syzbot wrote:
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > > > HEAD commit:4110b42356f3 Add linux-next specific files for 
> > > > > 20180810
> > > > > git tree:   linux-next
> > > > > console output: 
> > > > > https://syzkaller.appspot.com/x/log.txt?x=1411d6e240
> > > > > kernel config:  
> > > > > https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
> > > > > dashboard link: 
> > > > > https://syzkaller.appspot.com/bug?extid=4b8b031b89e6b96c4b2e
> > > > > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > > > > syzkaller 
> > > > > repro:https://syzkaller.appspot.com/x/repro.syz?x=175052f840
> > > > > C reproducer:   
> > > > > https://syzkaller.appspot.com/x/repro.c?x=1187362240
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the 
> > > > > commit:
> > > > > Reported-by: syzbot+4b8b031b89e6b96c4...@syzkaller.appspotmail.com
> > > > >
> > > > > random: sshd: uninitialized urandom read (32 bytes read)
> > > > > random: sshd: uninitialized urandom read (32 bytes read)
> > > > > random: sshd: uninitialized urandom read (32 bytes read)
> > > > >
> > > > > ==
> > > > > WARNING: possible circular locking dependency detected
> > > > > 4.18.0-rc8-next-20180810+ #36 Not tainted
> > > > > --
> > > > > syz-executor900/4483 is trying to acquire lock:
> > > > > d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at: inode_lock
> > > > > include/linux/fs.h:765 [inline]
> > > > > d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at:
> > > > > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
> > > > >
> > > > > but task is already holding lock:
> > > > > 25208078 (ashmem_mutex){+.+.}, at: 
> > > > > ashmem_shrink_scan+0xb4/0x630
> > > > > drivers/staging/android/ashmem.c:448
> > > > >
> > > > > which lock already depends on the new lock.
> > > > >
> > > > >
> > > > > the existing dependency chain (in reverse order) is:
> > > > >
> > > > > -> #2 (ashmem_mutex){+.+.}:
> > > > >__mutex_lock_common kernel/locking/mutex.c:925 [inline]
> > > > >__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
> > > > >mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
> > > > >ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
> > > > >call_mmap include/linux/fs.h:1844 [inline]
> > > > >mmap_region+0xf27/0x1c50 mm/mmap.c:1762
> > > > >do_mmap+0xa10/0x1220 mm/mmap.c:1535
> > > > >do_mmap_pgoff include/linux/mm.h:2298 [inline]
> > > > >vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
> > > > >ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
> > > > >__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
> > > > >__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
> > > > >__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
> > > > >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > > > >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > > >
> > > > > -> #1 (&mm->mmap_sem){}:
> > > > >__might_fault+0x155/0x1e0 mm/memory.c:4568
> > > > >_copy_to_user+0x30/0x110 lib/usercopy.c:25
> > > > >copy_to_user include/linux/uaccess.h:155 [inline]
> > > > >filldir+0x1ea/0x3a0 fs/readdir.c:196
> > > > >dir_emit_dot include/linux/fs.h:3464 [inline]
> > > > >dir_emit_dots include/linux/fs.h:3475 [inline]
> > > > >dcache_readdir+0x13a/0x620 fs/libfs.c:193
> > > > >iterate_dir+0x48b/0x5d0 fs/readdir.c:51
> > > > >__do_sys_getdents fs/readdir.c:231 [inline]
> > > > >__se_sys_getdents fs/readdir.c:212 [inline]
> > > > >__x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
> > > > >do_syscall_64+0x1b

Re: possible deadlock in shmem_fallocate (2)

2019-01-22 Thread Dmitry Vyukov 
On Tue, Jan 22, 2019 at 4:34 PM Joel Fernandes  wrote:
>
> On Tue, Jan 22, 2019 at 02:59:29PM +0100, Dmitry Vyukov wrote:
> > On Fri, Aug 10, 2018 at 6:18 PM Matthew Wilcox  wrote:
> > >
> > >
> > > This is another ashmem lockdep splat.  Forwarding to the appropriate 
> > > ashmem
> > > people.
> >
> >
> > Let's test Tetsuo's patch
> >
> > #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
>
> Just to clarify, the following patch only went in, in September:
> mm: shmem.c: Correctly annotate new inodes for lockdep

Is it supposed to fix this bug? This bug still happens: last time 5 hours ago:

https://syzkaller.appspot.com/bug?extid=4b8b031b89e6b96c4b2e


> thanks,
>
>  - Joel
>
>
> > > On Fri, Aug 10, 2018 at 04:59:02AM -0700, syzbot wrote:
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> > > > HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
> > > > git tree:   linux-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1411d6e240
> > > > kernel config:  
> > > > https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
> > > > dashboard link: 
> > > > https://syzkaller.appspot.com/bug?extid=4b8b031b89e6b96c4b2e
> > > > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > > > syzkaller 
> > > > repro:https://syzkaller.appspot.com/x/repro.syz?x=175052f840
> > > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1187362240
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the 
> > > > commit:
> > > > Reported-by: syzbot+4b8b031b89e6b96c4...@syzkaller.appspotmail.com
> > > >
> > > > random: sshd: uninitialized urandom read (32 bytes read)
> > > > random: sshd: uninitialized urandom read (32 bytes read)
> > > > random: sshd: uninitialized urandom read (32 bytes read)
> > > >
> > > > ==
> > > > WARNING: possible circular locking dependency detected
> > > > 4.18.0-rc8-next-20180810+ #36 Not tainted
> > > > --
> > > > syz-executor900/4483 is trying to acquire lock:
> > > > d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at: inode_lock
> > > > include/linux/fs.h:765 [inline]
> > > > d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at:
> > > > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
> > > >
> > > > but task is already holding lock:
> > > > 25208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630
> > > > drivers/staging/android/ashmem.c:448
> > > >
> > > > which lock already depends on the new lock.
> > > >
> > > >
> > > > the existing dependency chain (in reverse order) is:
> > > >
> > > > -> #2 (ashmem_mutex){+.+.}:
> > > >__mutex_lock_common kernel/locking/mutex.c:925 [inline]
> > > >__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
> > > >mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
> > > >ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
> > > >call_mmap include/linux/fs.h:1844 [inline]
> > > >mmap_region+0xf27/0x1c50 mm/mmap.c:1762
> > > >do_mmap+0xa10/0x1220 mm/mmap.c:1535
> > > >do_mmap_pgoff include/linux/mm.h:2298 [inline]
> > > >vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
> > > >ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
> > > >__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
> > > >__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
> > > >__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
> > > >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > > >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > >
> > > > -> #1 (&mm->mmap_sem){}:
> > > >__might_fault+0x155/0x1e0 mm/memory.c:4568
> > > >_copy_to_user+0x30/0x110 lib/usercopy.c:25
> > > >copy_to_user include/linux/uaccess.h:155 [inline]
> > > >filldir+0x1ea/0x3a0 fs/readdir.c:196
> > > >dir_emit_dot include/linux/fs.h:3464 [inline]
> > > >dir_emit_dots include/linux/fs.h:3475 [inline]
> > > >dcache_readdir+0x13a/0x620 fs/libfs.c:193
> > > >iterate_dir+0x48b/0x5d0 fs/readdir.c:51
> > > >__do_sys_getdents fs/readdir.c:231 [inline]
> > > >__se_sys_getdents fs/readdir.c:212 [inline]
> > > >__x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
> > > >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > > >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > >
> > > > -> #0 (&sb->s_type->i_mutex_key#9){}:
> > > >lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> > > >down_write+0x8f/0x130 kernel/locking/rwsem.c:70
> > > >inode_lock include/linux/fs.h:765 [inline]
> > > >shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
> > > >ashmem_shrink_scan+0x236/0x630 
> > > > drivers/staging/android/ashmem.c:455
> > > >ashmem_ioctl+0x3ae/0x13a0 drivers/staging/andr

Re: possible deadlock in shmem_fallocate (2)

2019-01-22 Thread Joel Fernandes 
On Tue, Jan 22, 2019 at 02:59:29PM +0100, Dmitry Vyukov wrote:
> On Fri, Aug 10, 2018 at 6:18 PM Matthew Wilcox  wrote:
> >
> >
> > This is another ashmem lockdep splat.  Forwarding to the appropriate ashmem
> > people.
> 
> 
> Let's test Tetsuo's patch
> 
> #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> master

Just to clarify, the following patch only went in, in September:
mm: shmem.c: Correctly annotate new inodes for lockdep

thanks,

 - Joel


> > On Fri, Aug 10, 2018 at 04:59:02AM -0700, syzbot wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
> > > git tree:   linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=1411d6e240
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=4b8b031b89e6b96c4b2e
> > > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=175052f840
> > > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1187362240
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+4b8b031b89e6b96c4...@syzkaller.appspotmail.com
> > >
> > > random: sshd: uninitialized urandom read (32 bytes read)
> > > random: sshd: uninitialized urandom read (32 bytes read)
> > > random: sshd: uninitialized urandom read (32 bytes read)
> > >
> > > ==
> > > WARNING: possible circular locking dependency detected
> > > 4.18.0-rc8-next-20180810+ #36 Not tainted
> > > --
> > > syz-executor900/4483 is trying to acquire lock:
> > > d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at: inode_lock
> > > include/linux/fs.h:765 [inline]
> > > d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at:
> > > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
> > >
> > > but task is already holding lock:
> > > 25208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630
> > > drivers/staging/android/ashmem.c:448
> > >
> > > which lock already depends on the new lock.
> > >
> > >
> > > the existing dependency chain (in reverse order) is:
> > >
> > > -> #2 (ashmem_mutex){+.+.}:
> > >__mutex_lock_common kernel/locking/mutex.c:925 [inline]
> > >__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
> > >mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
> > >ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
> > >call_mmap include/linux/fs.h:1844 [inline]
> > >mmap_region+0xf27/0x1c50 mm/mmap.c:1762
> > >do_mmap+0xa10/0x1220 mm/mmap.c:1535
> > >do_mmap_pgoff include/linux/mm.h:2298 [inline]
> > >vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
> > >ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
> > >__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
> > >__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
> > >__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
> > >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > >
> > > -> #1 (&mm->mmap_sem){}:
> > >__might_fault+0x155/0x1e0 mm/memory.c:4568
> > >_copy_to_user+0x30/0x110 lib/usercopy.c:25
> > >copy_to_user include/linux/uaccess.h:155 [inline]
> > >filldir+0x1ea/0x3a0 fs/readdir.c:196
> > >dir_emit_dot include/linux/fs.h:3464 [inline]
> > >dir_emit_dots include/linux/fs.h:3475 [inline]
> > >dcache_readdir+0x13a/0x620 fs/libfs.c:193
> > >iterate_dir+0x48b/0x5d0 fs/readdir.c:51
> > >__do_sys_getdents fs/readdir.c:231 [inline]
> > >__se_sys_getdents fs/readdir.c:212 [inline]
> > >__x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
> > >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> > >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > >
> > > -> #0 (&sb->s_type->i_mutex_key#9){}:
> > >lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> > >down_write+0x8f/0x130 kernel/locking/rwsem.c:70
> > >inode_lock include/linux/fs.h:765 [inline]
> > >shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
> > >ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
> > >ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
> > >vfs_ioctl fs/ioctl.c:46 [inline]
> > >file_ioctl fs/ioctl.c:501 [inline]
> > >do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
> > >ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
> > >__do_sys_ioctl fs/ioctl.c:709 [inline]
> > >__se_sys_ioctl fs/ioctl.c:707 [inline]
> > >__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
> > >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:2

Re: possible deadlock in shmem_fallocate (2)

2019-01-22 Thread syzbot 

Hello,

syzbot has tested the proposed patch and the reproducer did not trigger  
crash:


Reported-and-tested-by:  
syzbot+4b8b031b89e6b96c4...@syzkaller.appspotmail.com


Tested on:

commit: 48b161983ae5 Merge tag 'xarray-5.0-rc3' of git://git.infra..
git tree:   upstream
kernel config:  https://syzkaller.appspot.com/x/.config?x=864ab9949c515a07
compiler:   gcc (GCC) 9.0.0 20181231 (experimental)
patch:  https://syzkaller.appspot.com/x/patch.diff?x=1064a9a0c0

Note: testing is done by a robot and is best-effort only.

Re: possible deadlock in shmem_fallocate (2)

2019-01-22 Thread Dmitry Vyukov 
On Fri, Aug 10, 2018 at 6:18 PM Matthew Wilcox  wrote:
>
>
> This is another ashmem lockdep splat.  Forwarding to the appropriate ashmem
> people.


Let's test Tetsuo's patch

#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master



> On Fri, Aug 10, 2018 at 04:59:02AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
> > git tree:   linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1411d6e240
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
> > dashboard link: https://syzkaller.appspot.com/bug?extid=4b8b031b89e6b96c4b2e
> > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=175052f840
> > C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1187362240
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+4b8b031b89e6b96c4...@syzkaller.appspotmail.com
> >
> > random: sshd: uninitialized urandom read (32 bytes read)
> > random: sshd: uninitialized urandom read (32 bytes read)
> > random: sshd: uninitialized urandom read (32 bytes read)
> >
> > ==
> > WARNING: possible circular locking dependency detected
> > 4.18.0-rc8-next-20180810+ #36 Not tainted
> > --
> > syz-executor900/4483 is trying to acquire lock:
> > d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at: inode_lock
> > include/linux/fs.h:765 [inline]
> > d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at:
> > shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
> >
> > but task is already holding lock:
> > 25208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630
> > drivers/staging/android/ashmem.c:448
> >
> > which lock already depends on the new lock.
> >
> >
> > the existing dependency chain (in reverse order) is:
> >
> > -> #2 (ashmem_mutex){+.+.}:
> >__mutex_lock_common kernel/locking/mutex.c:925 [inline]
> >__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
> >mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
> >ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
> >call_mmap include/linux/fs.h:1844 [inline]
> >mmap_region+0xf27/0x1c50 mm/mmap.c:1762
> >do_mmap+0xa10/0x1220 mm/mmap.c:1535
> >do_mmap_pgoff include/linux/mm.h:2298 [inline]
> >vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
> >ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
> >__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
> >__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
> >__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
> >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #1 (&mm->mmap_sem){}:
> >__might_fault+0x155/0x1e0 mm/memory.c:4568
> >_copy_to_user+0x30/0x110 lib/usercopy.c:25
> >copy_to_user include/linux/uaccess.h:155 [inline]
> >filldir+0x1ea/0x3a0 fs/readdir.c:196
> >dir_emit_dot include/linux/fs.h:3464 [inline]
> >dir_emit_dots include/linux/fs.h:3475 [inline]
> >dcache_readdir+0x13a/0x620 fs/libfs.c:193
> >iterate_dir+0x48b/0x5d0 fs/readdir.c:51
> >__do_sys_getdents fs/readdir.c:231 [inline]
> >__se_sys_getdents fs/readdir.c:212 [inline]
> >__x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
> >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > -> #0 (&sb->s_type->i_mutex_key#9){}:
> >lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> >down_write+0x8f/0x130 kernel/locking/rwsem.c:70
> >inode_lock include/linux/fs.h:765 [inline]
> >shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
> >ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
> >ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
> >vfs_ioctl fs/ioctl.c:46 [inline]
> >file_ioctl fs/ioctl.c:501 [inline]
> >do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
> >ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
> >__do_sys_ioctl fs/ioctl.c:709 [inline]
> >__se_sys_ioctl fs/ioctl.c:707 [inline]
> >__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
> >do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> >entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > other info that might help us debug this:
> >
> > Chain exists of:
> >   &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex
> >
> >  Possible unsafe locking scenario:
> >
> >CPU0CPU1
> >
> >   lock(ashmem_mutex);
> >lock(&mm->mmap_sem

Re: possible deadlock in shmem_fallocate (2)

2018-08-10 Thread Matthew Wilcox 


This is another ashmem lockdep splat.  Forwarding to the appropriate ashmem
people.

On Fri, Aug 10, 2018 at 04:59:02AM -0700, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
> git tree:   linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1411d6e240
> kernel config:  https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
> dashboard link: https://syzkaller.appspot.com/bug?extid=4b8b031b89e6b96c4b2e
> compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=175052f840
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1187362240
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+4b8b031b89e6b96c4...@syzkaller.appspotmail.com
> 
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> random: sshd: uninitialized urandom read (32 bytes read)
> 
> ==
> WARNING: possible circular locking dependency detected
> 4.18.0-rc8-next-20180810+ #36 Not tainted
> --
> syz-executor900/4483 is trying to acquire lock:
> d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at: inode_lock
> include/linux/fs.h:765 [inline]
> d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at:
> shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
> 
> but task is already holding lock:
> 25208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630
> drivers/staging/android/ashmem.c:448
> 
> which lock already depends on the new lock.
> 
> 
> the existing dependency chain (in reverse order) is:
> 
> -> #2 (ashmem_mutex){+.+.}:
>__mutex_lock_common kernel/locking/mutex.c:925 [inline]
>__mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
>mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
>ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
>call_mmap include/linux/fs.h:1844 [inline]
>mmap_region+0xf27/0x1c50 mm/mmap.c:1762
>do_mmap+0xa10/0x1220 mm/mmap.c:1535
>do_mmap_pgoff include/linux/mm.h:2298 [inline]
>vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
>ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
>__do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>__se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
>__x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> -> #1 (&mm->mmap_sem){}:
>__might_fault+0x155/0x1e0 mm/memory.c:4568
>_copy_to_user+0x30/0x110 lib/usercopy.c:25
>copy_to_user include/linux/uaccess.h:155 [inline]
>filldir+0x1ea/0x3a0 fs/readdir.c:196
>dir_emit_dot include/linux/fs.h:3464 [inline]
>dir_emit_dots include/linux/fs.h:3475 [inline]
>dcache_readdir+0x13a/0x620 fs/libfs.c:193
>iterate_dir+0x48b/0x5d0 fs/readdir.c:51
>__do_sys_getdents fs/readdir.c:231 [inline]
>__se_sys_getdents fs/readdir.c:212 [inline]
>__x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> -> #0 (&sb->s_type->i_mutex_key#9){}:
>lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
>down_write+0x8f/0x130 kernel/locking/rwsem.c:70
>inode_lock include/linux/fs.h:765 [inline]
>shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
>ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
>ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
>vfs_ioctl fs/ioctl.c:46 [inline]
>file_ioctl fs/ioctl.c:501 [inline]
>do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
>ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
>__do_sys_ioctl fs/ioctl.c:709 [inline]
>__se_sys_ioctl fs/ioctl.c:707 [inline]
>__x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
>do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
>entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> other info that might help us debug this:
> 
> Chain exists of:
>   &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex
> 
>  Possible unsafe locking scenario:
> 
>CPU0CPU1
>
>   lock(ashmem_mutex);
>lock(&mm->mmap_sem);
>lock(ashmem_mutex);
>   lock(&sb->s_type->i_mutex_key#9);
> 
>  *** DEADLOCK ***
> 
> 1 lock held by syz-executor900/4483:
>  #0: 25208078 (ashmem_mutex){+.+.}, at:
> ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448
> 
> stack backtrace:
> CPU: 1 PID: 4483 Comm: syz-executor900 Not tainted 4.18.0

possible deadlock in shmem_fallocate (2)

2018-08-10 Thread syzbot 

Hello,

syzbot found the following crash on:

HEAD commit:4110b42356f3 Add linux-next specific files for 20180810
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1411d6e240
kernel config:  https://syzkaller.appspot.com/x/.config?x=1d80606e3795a4f5
dashboard link: https://syzkaller.appspot.com/bug?extid=4b8b031b89e6b96c4b2e
compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=175052f840
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1187362240

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+4b8b031b89e6b96c4...@syzkaller.appspotmail.com

random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)

==
WARNING: possible circular locking dependency detected
4.18.0-rc8-next-20180810+ #36 Not tainted
--
syz-executor900/4483 is trying to acquire lock:
d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at: inode_lock  
include/linux/fs.h:765 [inline]
d2bfc8fe (&sb->s_type->i_mutex_key#9){}, at:  
shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602


but task is already holding lock:
25208078 (ashmem_mutex){+.+.}, at: ashmem_shrink_scan+0xb4/0x630  
drivers/staging/android/ashmem.c:448


which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (ashmem_mutex){+.+.}:
   __mutex_lock_common kernel/locking/mutex.c:925 [inline]
   __mutex_lock+0x171/0x1700 kernel/locking/mutex.c:1073
   mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1088
   ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
   call_mmap include/linux/fs.h:1844 [inline]
   mmap_region+0xf27/0x1c50 mm/mmap.c:1762
   do_mmap+0xa10/0x1220 mm/mmap.c:1535
   do_mmap_pgoff include/linux/mm.h:2298 [inline]
   vm_mmap_pgoff+0x213/0x2c0 mm/util.c:357
   ksys_mmap_pgoff+0x4da/0x660 mm/mmap.c:1585
   __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
   __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline]
   __x64_sys_mmap+0xe9/0x1b0 arch/x86/kernel/sys_x86_64.c:91
   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #1 (&mm->mmap_sem){}:
   __might_fault+0x155/0x1e0 mm/memory.c:4568
   _copy_to_user+0x30/0x110 lib/usercopy.c:25
   copy_to_user include/linux/uaccess.h:155 [inline]
   filldir+0x1ea/0x3a0 fs/readdir.c:196
   dir_emit_dot include/linux/fs.h:3464 [inline]
   dir_emit_dots include/linux/fs.h:3475 [inline]
   dcache_readdir+0x13a/0x620 fs/libfs.c:193
   iterate_dir+0x48b/0x5d0 fs/readdir.c:51
   __do_sys_getdents fs/readdir.c:231 [inline]
   __se_sys_getdents fs/readdir.c:212 [inline]
   __x64_sys_getdents+0x29f/0x510 fs/readdir.c:212
   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

-> #0 (&sb->s_type->i_mutex_key#9){}:
   lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
   down_write+0x8f/0x130 kernel/locking/rwsem.c:70
   inode_lock include/linux/fs.h:765 [inline]
   shmem_fallocate+0x18b/0x12e0 mm/shmem.c:2602
   ashmem_shrink_scan+0x236/0x630 drivers/staging/android/ashmem.c:455
   ashmem_ioctl+0x3ae/0x13a0 drivers/staging/android/ashmem.c:797
   vfs_ioctl fs/ioctl.c:46 [inline]
   file_ioctl fs/ioctl.c:501 [inline]
   do_vfs_ioctl+0x1de/0x1720 fs/ioctl.c:685
   ksys_ioctl+0xa9/0xd0 fs/ioctl.c:702
   __do_sys_ioctl fs/ioctl.c:709 [inline]
   __se_sys_ioctl fs/ioctl.c:707 [inline]
   __x64_sys_ioctl+0x73/0xb0 fs/ioctl.c:707
   do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
   entry_SYSCALL_64_after_hwframe+0x49/0xbe

other info that might help us debug this:

Chain exists of:
  &sb->s_type->i_mutex_key#9 --> &mm->mmap_sem --> ashmem_mutex

 Possible unsafe locking scenario:

   CPU0CPU1
   
  lock(ashmem_mutex);
   lock(&mm->mmap_sem);
   lock(ashmem_mutex);
  lock(&sb->s_type->i_mutex_key#9);

 *** DEADLOCK ***

1 lock held by syz-executor900/4483:
 #0: 25208078 (ashmem_mutex){+.+.}, at:  
ashmem_shrink_scan+0xb4/0x630 drivers/staging/android/ashmem.c:448


stack backtrace:
CPU: 1 PID: 4483 Comm: syz-executor900 Not tainted  
4.18.0-rc8-next-20180810+ #36
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS  
Google 01/01/2011

Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
 print_circular_bug.isra.37.cold.58+0x1bd/0x27d  
kernel/locking/lockdep.c:1227

 check_prev_add kernel/locking/lockdep.c:1867 [inli