All of lore.kernel.org
 help / color / mirror / Atom feed
From: syzbot <syzbot+a76129f18c89f3e2ddd4@syzkaller.appspotmail.com>
To: ak@linux.intel.com, akpm@linux-foundation.org, arve@android.com,
	dhowells@redhat.com, dvyukov@google.com,
	gregkh@linuxfoundation.org, hannes@cmpxchg.org, jack@suse.cz,
	jlayton@kernel.org, joel@joelfernandes.org, joelaf@google.com,
	jrdr.linux@gmail.com, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, maco@android.com, mawilcox@microsoft.com,
	mgorman@techsingularity.net, syzkaller-bugs@googlegroups.com,
	tkjos@android.com, tkjos@google.com
Subject: Re: possible deadlock in __do_page_fault
Date: Sun, 30 Sep 2018 22:23:03 -0700	[thread overview]
Message-ID: <000000000000d2c6c3057723ffc5@google.com> (raw)
In-Reply-To: <000000000000f7a28e057653dc6e@google.com>

syzbot has found a reproducer for the following crash on:

HEAD commit:    17b57b1883c1 Linux 4.19-rc6
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=17920a7e400000
kernel config:  https://syzkaller.appspot.com/x/.config?x=c0af03fe452b65fb
dashboard link: https://syzkaller.appspot.com/bug?extid=a76129f18c89f3e2ddd4
compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=160c0f11400000
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1788de81400000

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

audit: type=1800 audit(1538371187.479:30): pid=5202 uid=0 auid=4294967295  
ses=4294967295 subj=_ op=collect_data cause=failed(directio)  
comm="startpar" name="rmnologin" dev="sda1" ino=2423 res=0

======================================================
WARNING: possible circular locking dependency detected
4.19.0-rc6+ #39 Not tainted
------------------------------------------------------
syz-executor559/5371 is trying to acquire lock:
00000000e34677d1 (&mm->mmap_sem){++++}, at: __do_page_fault+0xb70/0xed0  
arch/x86/mm/fault.c:1331

but task is already holding lock:
00000000b0c242ca (&sb->s_type->i_mutex_key#11){+.+.}, at: inode_lock  
include/linux/fs.h:738 [inline]
00000000b0c242ca (&sb->s_type->i_mutex_key#11){+.+.}, at:  
generic_file_write_iter+0xed/0x870 mm/filemap.c:3289

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 (&sb->s_type->i_mutex_key#11){+.+.}:
        down_write+0x8a/0x130 kernel/locking/rwsem.c:70
        inode_lock include/linux/fs.h:738 [inline]
        shmem_fallocate+0x18b/0x12c0 mm/shmem.c:2651
        ashmem_shrink_scan+0x238/0x660 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

-> #1 (ashmem_mutex){+.+.}:
        __mutex_lock_common kernel/locking/mutex.c:925 [inline]
        __mutex_lock+0x166/0x1700 kernel/locking/mutex.c:1072
        mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:1087
        ashmem_mmap+0x55/0x520 drivers/staging/android/ashmem.c:361
        call_mmap include/linux/fs.h:1813 [inline]
        mmap_region+0xe82/0x1cd0 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

-> #0 (&mm->mmap_sem){++++}:
        lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
        down_read+0xb0/0x1d0 kernel/locking/rwsem.c:24
        __do_page_fault+0xb70/0xed0 arch/x86/mm/fault.c:1331
        do_page_fault+0xf2/0x7e0 arch/x86/mm/fault.c:1470
        page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1161
        fault_in_pages_readable include/linux/pagemap.h:609 [inline]
        iov_iter_fault_in_readable+0x363/0x450 lib/iov_iter.c:421
        generic_perform_write+0x216/0x6a0 mm/filemap.c:3129
        __generic_file_write_iter+0x26e/0x630 mm/filemap.c:3264
        generic_file_write_iter+0x436/0x870 mm/filemap.c:3292
        call_write_iter include/linux/fs.h:1808 [inline]
        new_sync_write fs/read_write.c:474 [inline]
        __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
        vfs_write+0x1fc/0x560 fs/read_write.c:549
        ksys_write+0x101/0x260 fs/read_write.c:598
        __do_sys_write fs/read_write.c:610 [inline]
        __se_sys_write fs/read_write.c:607 [inline]
        __x64_sys_write+0x73/0xb0 fs/read_write.c:607
        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:
   &mm->mmap_sem --> ashmem_mutex --> &sb->s_type->i_mutex_key#11

  Possible unsafe locking scenario:

        CPU0                    CPU1
        ----                    ----
   lock(&sb->s_type->i_mutex_key#11);
                                lock(ashmem_mutex);
                                lock(&sb->s_type->i_mutex_key#11);
   lock(&mm->mmap_sem);

  *** DEADLOCK ***

2 locks held by syz-executor559/5371:
  #0: 0000000012b388bb (sb_writers#5){.+.+}, at: file_start_write  
include/linux/fs.h:2759 [inline]
  #0: 0000000012b388bb (sb_writers#5){.+.+}, at: vfs_write+0x42a/0x560  
fs/read_write.c:548
  #1: 00000000b0c242ca (&sb->s_type->i_mutex_key#11){+.+.}, at: inode_lock  
include/linux/fs.h:738 [inline]
  #1: 00000000b0c242ca (&sb->s_type->i_mutex_key#11){+.+.}, at:  
generic_file_write_iter+0xed/0x870 mm/filemap.c:3289

stack backtrace:
CPU: 1 PID: 5371 Comm: syz-executor559 Not tainted 4.19.0-rc6+ #39
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+0x1c4/0x2b4 lib/dump_stack.c:113
  print_circular_bug.isra.33.cold.54+0x1bd/0x27d  
kernel/locking/lockdep.c:1221
  check_prev_add kernel/locking/lockdep.c:1861 [inline]
  check_prevs_add kernel/locking/lockdep.c:1974 [inline]
  validate_chain kernel/locking/lockdep.c:2415 [inline]
  __lock_acquire+0x33e4/0x4ec0 kernel/locking/lockdep.c:3411
  lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3900
  down_read+0xb0/0x1d0 kernel/locking/rwsem.c:24
  __do_page_fault+0xb70/0xed0 arch/x86/mm/fault.c:1331
  do_page_fault+0xf2/0x7e0 arch/x86/mm/fault.c:1470
  page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1161
RIP: 0010:fault_in_pages_readable include/linux/pagemap.h:609 [inline]
RIP: 0010:iov_iter_fault_in_readable+0x363/0x450 lib/iov_iter.c:421
Code: 00 31 ff 44 89 ee 88 55 98 e8 59 27 f4 fd 45 85 ed 74 c2 e9 7d fe ff  
ff e8 3a 26 f4 fd 0f 1f 00 0f ae e8 48 8b 85 28 ff ff ff <8a> 00 0f 1f 00  
31 ff 89 de 88 85 58 ff ff ff e8 29 27 f4 fd 85 db
RSP: 0018:ffff8801bf4e77d0 EFLAGS: 00010293
RAX: 000000002100053f RBX: 0000000000000000 RCX: ffffffff838a8de2
RDX: 0000000000000000 RSI: ffffffff838a8f46 RDI: 0000000000000007
RBP: ffff8801bf4e78a8 R08: ffff8801d81b24c0 R09: fffff94000da818e
R10: fffff94000da818e R11: ffffea0006d40c77 R12: 0000000000000000
R13: 0000000000001000 R14: 0000000000001000 R15: ffff8801bf4e7bc8
  generic_perform_write+0x216/0x6a0 mm/filemap.c:3129
  __generic_file_write_iter+0x26e/0x630 mm/filemap.c:3264
  generic_file_write_iter+0x436/0x870 mm/filemap.c:3292
  call_write_iter include/linux/fs.h:1808 [inline]
  new_sync_write fs/read_write.c:474 [inline]
  __vfs_write+0x6b8/0x9f0 fs/read_write.c:487
  vfs_write+0x1fc/0x560 fs/read_write.c:549
  ksys_write+0x101/0x260 fs/read_write.c:598
  __do_sys_write fs/read_write.c:610 [inline]
  __se_sys_write fs/read_write.c:607 [inline]
  __x64_sys_write+0x73/0xb0 fs/read_write.c:607
  do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
  entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x446339
Code: e8 2c b3 02 00 48 83 c4 18 c3 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7  
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff  
ff 0f 83 2b 09 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ff3053d5da8 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00000000006dac28 RCX: 0000000000446339
RDX: 00000000fffffda2 RSI: 0000000020000540 RDI: 0000000000000003
RBP: 00000000006dac20 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000293 R12: 00000000006dac2c
R13: dfdd4f11168a8b2b R14: 6873612f7665642f R15: 00000000006dad2c
kobject: 'regulatory.0' (000000004f5af2e3): kobject_uevent_env
kobject: 'regulatory.0' (000000004f5af2e3): fill_kobj_path: path  
= '/devices/platform/regulatory.0'


      parent reply	other threads:[~2018-10-01  5:23 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-20 21:04 possible deadlock in __do_page_fault syzbot
2018-09-20 21:10 ` Andrew Morton
2018-09-20 21:12   ` Todd Kjos
2018-09-20 23:33     ` Joel Fernandes
2018-09-21  6:37       ` Dmitry Vyukov
2018-09-21 23:21       ` Andrew Morton
2019-01-22 10:02         ` Tetsuo Handa
2019-01-22 10:12           ` Dmitry Vyukov
2019-01-22 10:32             ` Tetsuo Handa
2019-01-22 13:52               ` Dmitry Vyukov
2019-01-22 13:54                 ` Dmitry Vyukov
2019-01-22 14:08                   ` syzbot
2019-01-22 14:08                     ` syzbot
2019-01-22 15:32           ` Joel Fernandes
2019-01-23  2:01             ` Tetsuo Handa
2019-01-23 15:57               ` Joel Fernandes
2019-01-24  1:52                 ` Tetsuo Handa
2019-01-24 13:46                   ` Joel Fernandes
2019-01-25 16:02                     ` Tetsuo Handa
2019-01-25 16:02                       ` Tetsuo Handa
2019-01-28 16:45                       ` Joel Fernandes
2019-01-29 10:44                         ` Tetsuo Handa
2019-01-26  1:57                     ` Tetsuo Handa
2019-01-26  1:57                       ` Tetsuo Handa
2018-10-01  5:23 ` syzbot [this message]

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=000000000000d2c6c3057723ffc5@google.com \
    --to=syzbot+a76129f18c89f3e2ddd4@syzkaller.appspotmail.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=arve@android.com \
    --cc=dhowells@redhat.com \
    --cc=dvyukov@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=joel@joelfernandes.org \
    --cc=joelaf@google.com \
    --cc=jrdr.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maco@android.com \
    --cc=mawilcox@microsoft.com \
    --cc=mgorman@techsingularity.net \
    --cc=syzkaller-bugs@googlegroups.com \
    --cc=tkjos@android.com \
    --cc=tkjos@google.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.