From: syzbot <syzbot+5d04068d02b9da8a0947@syzkaller.appspotmail.com>
To: hughd@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, syzkaller-bugs@googlegroups.com
Subject: possible deadlock in shmem_fallocate (3)
Date: Mon, 09 Sep 2019 20:38:05 -0700 [thread overview]
Message-ID: <000000000000dc762d05922aa177@google.com> (raw)
Hello,
syzbot found the following crash on:
HEAD commit: 6d028043 Add linux-next specific files for 20190830
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=12359ec6600000
kernel config: https://syzkaller.appspot.com/x/.config?x=82a6bec43ab0cb69
dashboard link: https://syzkaller.appspot.com/bug?extid=5d04068d02b9da8a0947
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+5d04068d02b9da8a0947@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
5.3.0-rc6-next-20190830 #75 Not tainted
------------------------------------------------------
kswapd0/1770 is trying to acquire lock:
ffff8880a0b9b780 (&sb->s_type->i_mutex_key#13){+.+.}, at: inode_lock
include/linux/fs.h:789 [inline]
ffff8880a0b9b780 (&sb->s_type->i_mutex_key#13){+.+.}, at:
shmem_fallocate+0x15a/0xc60 mm/shmem.c:2728
but task is already holding lock:
ffffffff89042f80 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30
mm/page_alloc.c:4889
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (fs_reclaim){+.+.}:
__fs_reclaim_acquire mm/page_alloc.c:4075 [inline]
fs_reclaim_acquire.part.0+0x24/0x30 mm/page_alloc.c:4086
fs_reclaim_acquire mm/page_alloc.c:4662 [inline]
prepare_alloc_pages mm/page_alloc.c:4659 [inline]
__alloc_pages_nodemask+0x52f/0x900 mm/page_alloc.c:4711
alloc_pages_vma+0x1bc/0x3f0 mm/mempolicy.c:2114
shmem_alloc_page+0xbd/0x180 mm/shmem.c:1496
shmem_alloc_and_acct_page+0x165/0x990 mm/shmem.c:1521
shmem_getpage_gfp+0x598/0x2680 mm/shmem.c:1835
shmem_getpage mm/shmem.c:152 [inline]
shmem_write_begin+0x105/0x1e0 mm/shmem.c:2480
generic_perform_write+0x23b/0x540 mm/filemap.c:3304
__generic_file_write_iter+0x25e/0x630 mm/filemap.c:3433
generic_file_write_iter+0x420/0x690 mm/filemap.c:3465
call_write_iter include/linux/fs.h:1890 [inline]
new_sync_write+0x4d3/0x770 fs/read_write.c:483
__vfs_write+0xe1/0x110 fs/read_write.c:496
vfs_write+0x268/0x5d0 fs/read_write.c:558
ksys_write+0x14f/0x290 fs/read_write.c:611
__do_sys_write fs/read_write.c:623 [inline]
__se_sys_write fs/read_write.c:620 [inline]
__x64_sys_write+0x73/0xb0 fs/read_write.c:620
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
-> #0 (&sb->s_type->i_mutex_key#13){+.+.}:
check_prev_add kernel/locking/lockdep.c:2476 [inline]
check_prevs_add kernel/locking/lockdep.c:2581 [inline]
validate_chain kernel/locking/lockdep.c:2971 [inline]
__lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3955
lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4487
down_write+0x93/0x150 kernel/locking/rwsem.c:1534
inode_lock include/linux/fs.h:789 [inline]
shmem_fallocate+0x15a/0xc60 mm/shmem.c:2728
ashmem_shrink_scan drivers/staging/android/ashmem.c:462 [inline]
ashmem_shrink_scan+0x370/0x510 drivers/staging/android/ashmem.c:437
do_shrink_slab+0x40f/0xa30 mm/vmscan.c:560
shrink_slab mm/vmscan.c:721 [inline]
shrink_slab+0x19a/0x680 mm/vmscan.c:694
shrink_node+0x223/0x12e0 mm/vmscan.c:2807
kswapd_shrink_node mm/vmscan.c:3549 [inline]
balance_pgdat+0x57c/0xea0 mm/vmscan.c:3707
kswapd+0x5c3/0xf30 mm/vmscan.c:3958
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(fs_reclaim);
lock(&sb->s_type->i_mutex_key#13);
lock(fs_reclaim);
lock(&sb->s_type->i_mutex_key#13);
*** DEADLOCK ***
2 locks held by kswapd0/1770:
#0: ffffffff89042f80 (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30
mm/page_alloc.c:4889
#1: ffffffff8901ffe8 (shrinker_rwsem){++++}, at: shrink_slab
mm/vmscan.c:711 [inline]
#1: ffffffff8901ffe8 (shrinker_rwsem){++++}, at: shrink_slab+0xe6/0x680
mm/vmscan.c:694
stack backtrace:
CPU: 0 PID: 1770 Comm: kswapd0 Not tainted 5.3.0-rc6-next-20190830 #75
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+0x172/0x1f0 lib/dump_stack.c:113
print_circular_bug.isra.0.cold+0x163/0x172 kernel/locking/lockdep.c:1685
check_noncircular+0x32e/0x3e0 kernel/locking/lockdep.c:1809
check_prev_add kernel/locking/lockdep.c:2476 [inline]
check_prevs_add kernel/locking/lockdep.c:2581 [inline]
validate_chain kernel/locking/lockdep.c:2971 [inline]
__lock_acquire+0x2596/0x4a00 kernel/locking/lockdep.c:3955
lock_acquire+0x190/0x410 kernel/locking/lockdep.c:4487
down_write+0x93/0x150 kernel/locking/rwsem.c:1534
inode_lock include/linux/fs.h:789 [inline]
shmem_fallocate+0x15a/0xc60 mm/shmem.c:2728
ashmem_shrink_scan drivers/staging/android/ashmem.c:462 [inline]
ashmem_shrink_scan+0x370/0x510 drivers/staging/android/ashmem.c:437
do_shrink_slab+0x40f/0xa30 mm/vmscan.c:560
shrink_slab mm/vmscan.c:721 [inline]
shrink_slab+0x19a/0x680 mm/vmscan.c:694
shrink_node+0x223/0x12e0 mm/vmscan.c:2807
kswapd_shrink_node mm/vmscan.c:3549 [inline]
balance_pgdat+0x57c/0xea0 mm/vmscan.c:3707
kswapd+0x5c3/0xf30 mm/vmscan.c:3958
kthread+0x361/0x430 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
next reply other threads:[~2019-09-10 3:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-10 3:38 syzbot [this message]
-- strict thread matches above, loose matches on Subject: below --
2019-09-10 7:18 possible deadlock in shmem_fallocate (3) Hillf Danton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=000000000000dc762d05922aa177@google.com \
--to=syzbot+5d04068d02b9da8a0947@syzkaller.appspotmail.com \
--cc=hughd@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=syzkaller-bugs@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.