Re: INFO: task hung in filemap_fault

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Dec 18, 2017 at 3:52 PM, Tetsuo Handa
<penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote:
> On 2017/12/18 17:43, syzbot wrote:
>> Hello,
>>
>> syzkaller hit the following crash on 6084b576dca2e898f5c101baef151f7bfdbb606d
>> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>>
>> Unfortunately, I don't have any reproducer for this bug yet.
>>
>
> This log has a lot of mmap() but also has Android's binder messages.
>
> r9 = syz_open_dev$binder(&(0x7f0000000000)='/dev/binder#\x00', 0x0, 0x800)
>
> [   49.200735] binder: 9749:9755 IncRefs 0 refcount change on invalid ref 2 ret -22
> [   49.221514] binder: 9749:9755 Acquire 1 refcount change on invalid ref 4 ret -22
> [   49.233325] binder: 9749:9755 Acquire 1 refcount change on invalid ref 0 ret -22
> [   49.241979] binder: binder_mmap: 9749 205a3000-205a7000 bad vm_flags failed -1
> [   49.256949] binder: 9749:9755 unknown command 0
> [   49.262470] binder: 9749:9755 ioctl c0306201 20000fd0 returned -22
> [   49.293365] binder: 9749:9755 IncRefs 0 refcount change on invalid ref 2 ret -22
> [   49.301297] binder: binder_mmap: 9749 205a3000-205a7000 bad vm_flags failed -1
> [   49.314146] binder: 9749:9755 Acquire 1 refcount change on invalid ref 4 ret -22
> [   49.322732] binder: 9749:9755 Acquire 1 refcount change on invalid ref 0 ret -22
> [   49.332063] binder: 9749:9755 Release 1 refcount change on invalid ref 1 ret -22
> [   49.340796] binder: 9749:9755 Acquire 1 refcount change on invalid ref 2 ret -22
> [   49.349457] binder: 9749:9755 BC_DEAD_BINDER_DONE 0000000000000001 not found
> [   49.349462] binder: 9749:9755 BC_DEAD_BINDER_DONE 0000000000000000 not found
>
> [  246.752088] INFO: task syz-executor7:10280 blocked for more than 120 seconds.
>
> Anything that hung after uptime > 46.75 can be reported at uptime = 246.75, can't it?
>
> Is it possible to reproduce this problem by running the same program?


Hi Tetsuo,

syzbot always re-runs the same workload on a new machine. If it
manages to reproduce the problem, it provides a reproducer. In this
case it didn't.

The program that triggered this is this one (number 7 matches task
syz-executor7):

2017/12/18 06:16:18 executing program 7:

It has only 2 mmaps. The first one is pretty standard, but the second
one mmaps loop device:

r7 = syz_open_dev$loop(&(0x7f0000e58000-0xb)='/dev/loop#\x00', 0x0, 0x4102)
mmap(&(0x7f0000e5b000/0x1000)=nil, 0x1000, 0x3, 0x2011, r7, 0x0)

We have a bunch of hangs around /dev/loop:

https://groups.google.com/forum/#!msg/syzkaller-bugs/qzz2v1M93O4/DjHEEvq5AQAJ
https://groups.google.com/forum/#!msg/syzkaller-bugs/jy-bXYbRh7c/a1dQYyD9CgAJ
https://groups.google.com/forum/#!msg/syzkaller-bugs/vjGYuMMspAU/K3oOF_eHCgAJ
https://groups.google.com/forum/#!msg/syzkaller-bugs/BwpEc6q6gFY/5kHDMGElAgAJ

Probably related to these ones.
+loop maintainers.



>> INFO: task syz-executor7:10280 blocked for more than 120 seconds.
>>       Not tainted 4.15.0-rc3-next-20171214+ #67
>> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
>> syz-executor7   D    0 10280   3310 0x00000004
>> Call Trace:
>>  context_switch kernel/sched/core.c:2800 [inline]
>>  __schedule+0x30b/0xaf0 kernel/sched/core.c:3376
>>  schedule+0x2e/0x90 kernel/sched/core.c:3435
>>  io_schedule+0x11/0x40 kernel/sched/core.c:5043
>>  wait_on_page_bit_common mm/filemap.c:1099 [inline]
>>  wait_on_page_bit mm/filemap.c:1132 [inline]
>>  wait_on_page_locked include/linux/pagemap.h:530 [inline]
>>  __lock_page_or_retry+0x391/0x3e0 mm/filemap.c:1310
>>  lock_page_or_retry include/linux/pagemap.h:510 [inline]
>>  filemap_fault+0x61c/0xa70 mm/filemap.c:2532
>>  __do_fault+0x23/0xa4 mm/memory.c:3206
>>  do_read_fault mm/memory.c:3616 [inline]
>>  do_fault mm/memory.c:3716 [inline]
>>  handle_pte_fault mm/memory.c:3947 [inline]
>>  __handle_mm_fault+0x10b5/0x1930 mm/memory.c:4071
>>  handle_mm_fault+0x215/0x450 mm/memory.c:4108
>>  faultin_page mm/gup.c:502 [inline]
>>  __get_user_pages+0x1ff/0x980 mm/gup.c:699
>>  populate_vma_page_range+0xa1/0xb0 mm/gup.c:1200
>>  __mm_populate+0xcc/0x190 mm/gup.c:1250
>>  mm_populate include/linux/mm.h:2233 [inline]
>>  vm_mmap_pgoff+0x103/0x110 mm/util.c:338
>>  SYSC_mmap_pgoff mm/mmap.c:1533 [inline]
>>  SyS_mmap_pgoff+0x215/0x2c0 mm/mmap.c:1491
>>  SYSC_mmap arch/x86/kernel/sys_x86_64.c:100 [inline]
>>  SyS_mmap+0x16/0x20 arch/x86/kernel/sys_x86_64.c:91
>>  entry_SYSCALL_64_fastpath+0x1f/0x96
>> RIP: 0033:0x452a09
>> RSP: 002b:00007efce66dac58 EFLAGS: 00000212 ORIG_RAX: 0000000000000009
>> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452a09
>> RDX: 0000000000000003 RSI: 0000000000001000 RDI: 0000000020e5b000
>> RBP: 0000000000000033 R08: 0000000000000016 R09: 0000000000000000
>> R10: 0000000000002011 R11: 0000000000000212 R12: 00000000006ed568
>> R13: 00000000ffffffff R14: 00007efce66db6d4 R15: 0000000000000000
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@xxxxxxxxxxxxxxxx.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/82d89066-7dd2-12fe-3cc0-c8d624fe0d51%40I-love.SAKURA.ne.jp.
> For more options, visit https://groups.google.com/d/optout.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]
  Powered by Linux