* general protection fault in send_sigurg_to_task
@ 2018-08-13 12:54 syzbot
2018-08-13 13:33 ` syzbot
0 siblings, 1 reply; 12+ messages in thread
From: syzbot @ 2018-08-13 12:54 UTC (permalink / raw)
To: bfields, jlayton, linux-fsdevel, linux-kernel, syzkaller-bugs, viro
Hello,
syzbot found the following crash on:
HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=16c2a63c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab
dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761
compiler: gcc (GCC) 8.0.1 20180413 (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+1f371ca19b341a276761@syzkaller.appspotmail.com
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
CPU: 0 PID: 19114 Comm: syz-executor6 Not tainted 4.18.0-next-20180813+ #37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
RSP: 0018:ffff88019afc74a8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88019afc7518 RCX: ffffc9000643f000
RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
RBP: ffff88019afc7540 R08: ffff8801b16ae5c0 R09: ffffed003b6046d6
R10: ffffed003b6046d6 R11: ffff8801db0236b3 R12: 1ffff100335f8e97
R13: ffff8801cb8ddb48 R14: 0000000000000001 R15: 0000000000000000
FS: 00007f2e92a99700(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa4f3c16e18 CR3: 00000001b2e21000 CR4: 00000000001406f0
Call Trace:
send_sigurg+0x342/0x480 fs/fcntl.c:833
sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731
tcp_check_urg net/ipv4/tcp_input.c:5266 [inline]
tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307
tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637
tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532
sk_backlog_rcv include/net/sock.h:931 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2336
release_sock+0xad/0x2c0 net/core/sock.c:2849
tcp_sendmsg+0x3a/0x50 net/ipv4/tcp.c:1444
inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:622 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:632
__sys_sendto+0x3d7/0x670 net/socket.c:1787
__do_sys_sendto net/socket.c:1799 [inline]
__se_sys_sendto net/socket.c:1795 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1795
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 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 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f2e92a98c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f2e92a996d4 RCX: 0000000000457089
RDX: fffffffffffffd43 RSI: 0000000020de1fff RDI: 0000000000000004
RBP: 00000000009300a0 R08: 0000000020db4ff0 R09: 0000000000000010
R10: 0000000020008005 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004d3d08 R14: 00000000004c898d R15: 0000000000000000
Modules linked in:
Dumping ftrace buffer:
(ftrace buffer empty)
---[ end trace dc729739ab19eafd ]---
RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline]
RIP: 0010:sigio_perm fs/fcntl.c:715 [inline]
RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810
Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06
00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48
RSP: 0018:ffff88019afc74a8 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff88019afc7518 RCX: ffffc9000643f000
RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658
RBP: ffff88019afc7540 R08: ffff8801b16ae5c0 R09: ffffed003b6046d6
R10: ffffed003b6046d6 R11: ffff8801db0236b3 R12: 1ffff100335f8e97
R13: ffff8801cb8ddb48 R14: 0000000000000001 R15: 0000000000000000
FS: 00007f2e92a99700(0000) GS:ffff8801db000000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fa4f3c16e18 CR3: 00000001b2e21000 CR4: 00000000001406f0
---
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#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: general protection fault in send_sigurg_to_task 2018-08-13 12:54 general protection fault in send_sigurg_to_task syzbot @ 2018-08-13 13:33 ` syzbot 2018-08-14 19:11 ` J. Bruce Fields 0 siblings, 1 reply; 12+ messages in thread From: syzbot @ 2018-08-13 13:33 UTC (permalink / raw) To: bfields, jlayton, linux-fsdevel, linux-kernel, syzkaller-bugs, viro syzbot has found a reproducer for the following crash on: HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=10787028400000 kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 compiler: gcc (GCC) 8.0.1 20180413 (experimental) syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e828400000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b72400000 IMPORTANT: if you fix the bug, please add the following tag to the commit: Reported-by: syzbot+1f371ca19b341a276761@syzkaller.appspotmail.com nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: 0000 [#1] SMP KASAN CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 RSP: 0000:ffff8801db106c18 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0 RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658 RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6 R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85 R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000 FS: 0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0 Call Trace: <IRQ> send_sigurg+0x342/0x480 fs/fcntl.c:833 sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 NF_HOOK include/linux/netfilter.h:287 [inline] ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 dst_input include/net/dst.h:450 [inline] ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 NF_HOOK include/linux/netfilter.h:287 [inline] ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 process_backlog+0x219/0x760 net/core/dev.c:5808 napi_poll net/core/dev.c:6228 [inline] net_rx_action+0x799/0x1900 net/core/dev.c:6294 __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 invoke_softirq kernel/softirq.c:372 [inline] irq_exit+0x1d4/0x210 kernel/softirq.c:412 exiting_irq arch/x86/include/asm/apic.h:527 [inline] smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 </IRQ> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 [inline] RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 RSP: 0000:ffff8801c6de7578 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13 RAX: dffffc0000000000 RBX: 0000000000000286 RCX: 0000000000000000 RDX: 1ffffffff0fe3665 RSI: 0000000000000000 RDI: 0000000000000286 RBP: ffff8801c6de7598 R08: ffffed003b6246d7 R09: ffffed003b6246d6 R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: ffff8801b4ad4640 R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000000 lock_is_held include/linux/lockdep.h:344 [inline] rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285 xa_entry include/linux/xarray.h:486 [inline] xas_next_entry include/linux/xarray.h:905 [inline] filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536 do_fault_around mm/memory.c:3603 [inline] do_read_fault mm/memory.c:3637 [inline] do_fault mm/memory.c:3742 [inline] handle_pte_fault mm/memory.c:3973 [inline] __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097 handle_mm_fault+0x53e/0xc80 mm/memory.c:4134 __do_page_fault+0x620/0xe50 arch/x86/mm/fault.c:1395 do_page_fault+0xf6/0x7a4 arch/x86/mm/fault.c:1470 page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1164 RIP: 0033:0x400bc3 Code: 09 00 00 00 e8 0e 09 04 00 48 c7 05 2b 2b 2d 00 00 00 00 00 48 83 c4 10 e8 fa f1 03 00 85 c0 0f 85 d2 07 00 00 e8 ed f1 03 00 <89> c3 89 c5 85 c0 79 0a bf 01 00 00 00 e8 6b ed 00 00 85 c0 0f 85 RSP: 002b:00007ffd6e71ae70 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 000000000000116b RCX: 000000000043fe8a RDX: 0000001899a3a3ae RSI: 0000000000000000 RDI: 0000000001200011 RBP: 000000000000116b R08: 0000000000001149 R09: 0000000000949880 R10: 0000000000949b50 R11: 0000000000000246 R12: 000000000000a5e7 R13: 00000000004023f0 R14: 0000000000000000 R15: 0000000000000000 Modules linked in: Dumping ftrace buffer: (ftrace buffer empty) ---[ end trace b74ebc04d71b9f0f ]--- RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 RSP: 0000:ffff8801db106c18 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0 RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658 RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6 R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85 R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000 FS: 0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-13 13:33 ` syzbot @ 2018-08-14 19:11 ` J. Bruce Fields 2018-08-14 20:50 ` Dmitry Vyukov 0 siblings, 1 reply; 12+ messages in thread From: J. Bruce Fields @ 2018-08-14 19:11 UTC (permalink / raw) To: syzbot; +Cc: jlayton, linux-fsdevel, linux-kernel, syzkaller-bugs, viro On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > syzbot has found a reproducer for the following crash on: > > HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 > git tree: linux-next I fetched linux-next but don't have 5ed5da74de9e. I'm also not sure why I'm on the cc for this. --b. > console output: https://syzkaller.appspot.com/x/log.txt?x=10787028400000 > kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab > dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 > compiler: gcc (GCC) 8.0.1 20180413 (experimental) > syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e828400000 > C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b72400000 > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > Reported-by: syzbot+1f371ca19b341a276761@syzkaller.appspotmail.com > > nf_conntrack: default automatic helper assignment has been turned > off for security reasons and CT-based firewall rule not found. Use > the iptables CT target to attach helpers instead. > kasan: CONFIG_KASAN_INLINE enabled > kasan: GPF could be caused by NULL-ptr deref or user memory access > general protection fault: 0000 [#1] SMP KASAN > CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 > Hardware name: Google Google Compute Engine/Google Compute Engine, > BIOS Google 01/01/2011 > RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] > RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] > RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 > Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf > 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> > 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 > RSP: 0000:ffff8801db106c18 EFLAGS: 00010202 > RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0 > RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658 > RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6 > R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85 > R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000 > FS: 0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0 > Call Trace: > <IRQ> > send_sigurg+0x342/0x480 fs/fcntl.c:833 > sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 > tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] > tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 > tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 > tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 > tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 > ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 > NF_HOOK include/linux/netfilter.h:287 [inline] > ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 > dst_input include/net/dst.h:450 [inline] > ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 > NF_HOOK include/linux/netfilter.h:287 [inline] > ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 > __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 > __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 > process_backlog+0x219/0x760 net/core/dev.c:5808 > napi_poll net/core/dev.c:6228 [inline] > net_rx_action+0x799/0x1900 net/core/dev.c:6294 > __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 > invoke_softirq kernel/softirq.c:372 [inline] > irq_exit+0x1d4/0x210 kernel/softirq.c:412 > exiting_irq arch/x86/include/asm/apic.h:527 [inline] > smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 > </IRQ> > RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 > [inline] > RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 > Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 > 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> > 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 > RSP: 0000:ffff8801c6de7578 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13 > RAX: dffffc0000000000 RBX: 0000000000000286 RCX: 0000000000000000 > RDX: 1ffffffff0fe3665 RSI: 0000000000000000 RDI: 0000000000000286 > RBP: ffff8801c6de7598 R08: ffffed003b6246d7 R09: ffffed003b6246d6 > R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: ffff8801b4ad4640 > R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000000 > lock_is_held include/linux/lockdep.h:344 [inline] > rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285 > xa_entry include/linux/xarray.h:486 [inline] > xas_next_entry include/linux/xarray.h:905 [inline] > filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536 > do_fault_around mm/memory.c:3603 [inline] > do_read_fault mm/memory.c:3637 [inline] > do_fault mm/memory.c:3742 [inline] > handle_pte_fault mm/memory.c:3973 [inline] > __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097 > handle_mm_fault+0x53e/0xc80 mm/memory.c:4134 > __do_page_fault+0x620/0xe50 arch/x86/mm/fault.c:1395 > do_page_fault+0xf6/0x7a4 arch/x86/mm/fault.c:1470 > page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1164 > RIP: 0033:0x400bc3 > Code: 09 00 00 00 e8 0e 09 04 00 48 c7 05 2b 2b 2d 00 00 00 00 00 48 > 83 c4 10 e8 fa f1 03 00 85 c0 0f 85 d2 07 00 00 e8 ed f1 03 00 <89> > c3 89 c5 85 c0 79 0a bf 01 00 00 00 e8 6b ed 00 00 85 c0 0f 85 > RSP: 002b:00007ffd6e71ae70 EFLAGS: 00010246 > RAX: 0000000000000000 RBX: 000000000000116b RCX: 000000000043fe8a > RDX: 0000001899a3a3ae RSI: 0000000000000000 RDI: 0000000001200011 > RBP: 000000000000116b R08: 0000000000001149 R09: 0000000000949880 > R10: 0000000000949b50 R11: 0000000000000246 R12: 000000000000a5e7 > R13: 00000000004023f0 R14: 0000000000000000 R15: 0000000000000000 > Modules linked in: > Dumping ftrace buffer: > (ftrace buffer empty) > ---[ end trace b74ebc04d71b9f0f ]--- > RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] > RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] > RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 > Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf > 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> > 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 > RSP: 0000:ffff8801db106c18 EFLAGS: 00010202 > RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0 > RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658 > RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6 > R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85 > R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000 > FS: 0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-14 19:11 ` J. Bruce Fields @ 2018-08-14 20:50 ` Dmitry Vyukov 2018-08-15 0:11 ` Stephen Rothwell ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Dmitry Vyukov @ 2018-08-14 20:50 UTC (permalink / raw) To: J. Bruce Fields, Stephen Rothwell Cc: syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >> syzbot has found a reproducer for the following crash on: >> >> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 >> git tree: linux-next > > I fetched linux-next but don't have 5ed5da74de9e. Hi Bruce, +Stephen for the disappeared linux-next commit. On the dashboard link you can see that it also happened on a more recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see now in linux-next. > I'm also not sure why I'm on the cc for this. You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" as maintainer of the file, which is the file where the crash happened. > --b. > >> console output: https://syzkaller.appspot.com/x/log.txt?x=10787028400000 >> kernel config: https://syzkaller.appspot.com/x/.config?x=18edf0289d1b5ab >> dashboard link: https://syzkaller.appspot.com/bug?extid=1f371ca19b341a276761 >> compiler: gcc (GCC) 8.0.1 20180413 (experimental) >> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1487e828400000 >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15084b72400000 >> >> IMPORTANT: if you fix the bug, please add the following tag to the commit: >> Reported-by: syzbot+1f371ca19b341a276761@syzkaller.appspotmail.com >> >> nf_conntrack: default automatic helper assignment has been turned >> off for security reasons and CT-based firewall rule not found. Use >> the iptables CT target to attach helpers instead. >> kasan: CONFIG_KASAN_INLINE enabled >> kasan: GPF could be caused by NULL-ptr deref or user memory access >> general protection fault: 0000 [#1] SMP KASAN >> CPU: 1 PID: 4474 Comm: syz-executor782 Not tainted 4.18.0-next-20180813+ #37 >> Hardware name: Google Google Compute Engine/Google Compute Engine, >> BIOS Google 01/01/2011 >> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] >> RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] >> RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 >> Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf >> 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> >> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 >> RSP: 0000:ffff8801db106c18 EFLAGS: 00010202 >> RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0 >> RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658 >> RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6 >> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85 >> R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000 >> FS: 0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0 >> Call Trace: >> <IRQ> >> send_sigurg+0x342/0x480 fs/fcntl.c:833 >> sk_send_sigurg+0xd2/0x3d0 net/core/sock.c:2731 >> tcp_check_urg net/ipv4/tcp_input.c:5266 [inline] >> tcp_urg+0x3c3/0xba0 net/ipv4/tcp_input.c:5307 >> tcp_rcv_established+0xd45/0x2130 net/ipv4/tcp_input.c:5637 >> tcp_v4_do_rcv+0x635/0x8f0 net/ipv4/tcp_ipv4.c:1532 >> tcp_v4_rcv+0x2ff9/0x3a90 net/ipv4/tcp_ipv4.c:1824 >> ip_local_deliver_finish+0x2eb/0xda0 net/ipv4/ip_input.c:215 >> NF_HOOK include/linux/netfilter.h:287 [inline] >> ip_local_deliver+0x1e9/0x750 net/ipv4/ip_input.c:256 >> dst_input include/net/dst.h:450 [inline] >> ip_rcv_finish+0x1f9/0x300 net/ipv4/ip_input.c:415 >> NF_HOOK include/linux/netfilter.h:287 [inline] >> ip_rcv+0xed/0x610 net/ipv4/ip_input.c:524 >> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4892 >> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002 >> process_backlog+0x219/0x760 net/core/dev.c:5808 >> napi_poll net/core/dev.c:6228 [inline] >> net_rx_action+0x799/0x1900 net/core/dev.c:6294 >> __do_softirq+0x2e8/0xa6d kernel/softirq.c:292 >> invoke_softirq kernel/softirq.c:372 [inline] >> irq_exit+0x1d4/0x210 kernel/softirq.c:412 >> exiting_irq arch/x86/include/asm/apic.h:527 [inline] >> smp_apic_timer_interrupt+0x186/0x690 arch/x86/kernel/apic/apic.c:1055 >> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:867 >> </IRQ> >> RIP: 0010:arch_local_irq_restore arch/x86/include/asm/paravirt.h:783 >> [inline] >> RIP: 0010:lock_is_held_type+0x18b/0x210 kernel/locking/lockdep.c:3941 >> Code: ff df 41 c7 84 24 3c 08 00 00 00 00 00 00 48 89 fa 48 c1 ea 03 >> 80 3c 02 00 75 63 48 83 3d f4 33 93 06 00 74 30 48 89 df 57 9d <0f> >> 1f 44 00 00 48 83 c4 08 44 89 e8 5b 41 5c 41 5d 5d c3 48 83 c4 >> RSP: 0000:ffff8801c6de7578 EFLAGS: 00000286 ORIG_RAX: ffffffffffffff13 >> RAX: dffffc0000000000 RBX: 0000000000000286 RCX: 0000000000000000 >> RDX: 1ffffffff0fe3665 RSI: 0000000000000000 RDI: 0000000000000286 >> RBP: ffff8801c6de7598 R08: ffffed003b6246d7 R09: ffffed003b6246d6 >> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: ffff8801b4ad4640 >> R13: 0000000000000001 R14: dffffc0000000000 R15: 0000000000000000 >> lock_is_held include/linux/lockdep.h:344 [inline] >> rcu_read_lock_held+0xa9/0xc0 kernel/rcu/update.c:285 >> xa_entry include/linux/xarray.h:486 [inline] >> xas_next_entry include/linux/xarray.h:905 [inline] >> filemap_map_pages+0xdab/0x1990 mm/filemap.c:2536 >> do_fault_around mm/memory.c:3603 [inline] >> do_read_fault mm/memory.c:3637 [inline] >> do_fault mm/memory.c:3742 [inline] >> handle_pte_fault mm/memory.c:3973 [inline] >> __handle_mm_fault+0x339c/0x4470 mm/memory.c:4097 >> handle_mm_fault+0x53e/0xc80 mm/memory.c:4134 >> __do_page_fault+0x620/0xe50 arch/x86/mm/fault.c:1395 >> do_page_fault+0xf6/0x7a4 arch/x86/mm/fault.c:1470 >> page_fault+0x1e/0x30 arch/x86/entry/entry_64.S:1164 >> RIP: 0033:0x400bc3 >> Code: 09 00 00 00 e8 0e 09 04 00 48 c7 05 2b 2b 2d 00 00 00 00 00 48 >> 83 c4 10 e8 fa f1 03 00 85 c0 0f 85 d2 07 00 00 e8 ed f1 03 00 <89> >> c3 89 c5 85 c0 79 0a bf 01 00 00 00 e8 6b ed 00 00 85 c0 0f 85 >> RSP: 002b:00007ffd6e71ae70 EFLAGS: 00010246 >> RAX: 0000000000000000 RBX: 000000000000116b RCX: 000000000043fe8a >> RDX: 0000001899a3a3ae RSI: 0000000000000000 RDI: 0000000001200011 >> RBP: 000000000000116b R08: 0000000000001149 R09: 0000000000949880 >> R10: 0000000000949b50 R11: 0000000000000246 R12: 000000000000a5e7 >> R13: 00000000004023f0 R14: 0000000000000000 R15: 0000000000000000 >> Modules linked in: >> Dumping ftrace buffer: >> (ftrace buffer empty) >> ---[ end trace b74ebc04d71b9f0f ]--- >> RIP: 0010:__read_once_size include/linux/compiler.h:188 [inline] >> RIP: 0010:sigio_perm fs/fcntl.c:715 [inline] >> RIP: 0010:send_sigurg_to_task+0xf5/0x4d0 fs/fcntl.c:810 >> Code: 61 af b1 ff 45 84 f6 0f 84 52 03 00 00 e8 83 ae b1 ff 49 8d bf >> 58 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> >> 3c 02 00 0f 85 91 03 00 00 48 8d 43 c0 4d 8b b7 58 06 00 00 48 >> RSP: 0000:ffff8801db106c18 EFLAGS: 00010202 >> RAX: dffffc0000000000 RBX: ffff8801db106c88 RCX: ffffffff81cae2d0 >> RDX: 00000000000000cb RSI: ffffffff81cadf6d RDI: 0000000000000658 >> RBP: ffff8801db106cb0 R08: ffff8801b4ad4640 R09: ffffed003b6246d6 >> R10: ffffed003b6246d6 R11: ffff8801db1236b3 R12: 1ffff1003b620d85 >> R13: ffff8801b4cb9388 R14: 0000000000000001 R15: 0000000000000000 >> FS: 0000000000949880(0000) GS:ffff8801db100000(0000) knlGS:0000000000000000 >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> CR2: 0000000000400bc3 CR3: 00000001bb122000 CR4: 00000000001406e0 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-14 20:50 ` Dmitry Vyukov @ 2018-08-15 0:11 ` Stephen Rothwell 2018-08-15 18:53 ` J. Bruce Fields 2018-08-15 20:35 ` J. Bruce Fields 2018-08-16 4:01 ` Eric W. Biederman 2 siblings, 1 reply; 12+ messages in thread From: Stephen Rothwell @ 2018-08-15 0:11 UTC (permalink / raw) To: Dmitry Vyukov Cc: J. Bruce Fields, syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro [-- Attachment #1: Type: text/plain, Size: 1187 bytes --] Hi Bruce, On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov <dvyukov@google.com> wrote: > > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > >> syzbot has found a reproducer for the following crash on: > >> > >> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 > >> git tree: linux-next > > > > I fetched linux-next but don't have 5ed5da74de9e. > > +Stephen for the disappeared linux-next commit. That is just the HEAD commit on linux-next that day. If you fetched linux-next after I released next-20180814 yesterday, then it would have a different HEAD commit. If you check out the tag next-20180813, you will get the above HEAD commit. > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. Which is just the HEAD commit of next-20180814. Linux-next is rebuilt every day based on Linus' tree of the day, followed by merging all the other branches, so its HEAD is different every day. -- Cheers, Stephen Rothwell [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-15 0:11 ` Stephen Rothwell @ 2018-08-15 18:53 ` J. Bruce Fields 0 siblings, 0 replies; 12+ messages in thread From: J. Bruce Fields @ 2018-08-15 18:53 UTC (permalink / raw) To: Stephen Rothwell Cc: Dmitry Vyukov, syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro On Wed, Aug 15, 2018 at 10:11:20AM +1000, Stephen Rothwell wrote: > Hi Bruce, > > On Tue, 14 Aug 2018 13:50:20 -0700 Dmitry Vyukov <dvyukov@google.com> wrote: > > > > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > > >> syzbot has found a reproducer for the following crash on: > > >> > > >> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 > > >> git tree: linux-next > > > > > > I fetched linux-next but don't have 5ed5da74de9e. > > > > +Stephen for the disappeared linux-next commit. > > That is just the HEAD commit on linux-next that day. If you fetched > linux-next after I released next-20180814 yesterday, then it would have > a different HEAD commit. If you check out the tag next-20180813, you > will get the above HEAD commit. > > > On the dashboard link you can see that it also happened on a more > > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > > now in linux-next. > > Which is just the HEAD commit of next-20180814. > > Linux-next is rebuilt every day based on Linus' tree of the day, > followed by merging all the other branches, so its HEAD is different > every day. I new it was rebuilt every day, but for some reason I expected git to fetch all new tags. But that's wrong, it just fetches whatever branch(es) you request and then only tags that happen to reference stuff on that branch; from git-fetch(1): "By default, any tag that points into the histories being fetched is also fetched; the effect is to fetch tags that point at branches that you are interested in. This default behavior can be changed by using the --tags or --no-tags options or by configuring remote.<name>.tagOpt. By using a refspec that fetches tags explicitly, you can fetch tags that do not point into branches you are interested in as well." Sorry for the confusion! --b. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-14 20:50 ` Dmitry Vyukov 2018-08-15 0:11 ` Stephen Rothwell @ 2018-08-15 20:35 ` J. Bruce Fields 2018-08-16 4:01 ` Eric W. Biederman 2 siblings, 0 replies; 12+ messages in thread From: J. Bruce Fields @ 2018-08-15 20:35 UTC (permalink / raw) To: Dmitry Vyukov Cc: Stephen Rothwell, syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro On Tue, Aug 14, 2018 at 01:50:20PM -0700, Dmitry Vyukov wrote: > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > > On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > >> syzbot has found a reproducer for the following crash on: > >> > >> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 > >> git tree: linux-next > > > > I fetched linux-next but don't have 5ed5da74de9e. > > Hi Bruce, > > +Stephen for the disappeared linux-next commit. > > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. > > > I'm also not sure why I'm on the cc for this. > > You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > as maintainer of the file, which is the file where the crash happened. We should probably fix that. There's a tiny bit of lock-related code in that file but it's not at all interesting compared, say, to the code that this bug is hitting.... (Which I have no clue about. send_sigurg_to_task() is getting a bad task? Help.) --b. diff --git a/MAINTAINERS b/MAINTAINERS index 9d5eeff51b5f..a5dca2be8513 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -5541,9 +5541,6 @@ M: Jeff Layton <jlayton@kernel.org> M: "J. Bruce Fields" <bfields@fieldses.org> L: linux-fsdevel@vger.kernel.org S: Maintained -F: include/linux/fcntl.h -F: include/uapi/linux/fcntl.h -F: fs/fcntl.c F: fs/locks.c FILESYSTEMS (VFS and infrastructure) ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-14 20:50 ` Dmitry Vyukov 2018-08-15 0:11 ` Stephen Rothwell 2018-08-15 20:35 ` J. Bruce Fields @ 2018-08-16 4:01 ` Eric W. Biederman 2018-08-17 17:26 ` Dmitry Vyukov 2 siblings, 1 reply; 12+ messages in thread From: Eric W. Biederman @ 2018-08-16 4:01 UTC (permalink / raw) To: Dmitry Vyukov Cc: J. Bruce Fields, Stephen Rothwell, syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro Dmitry Vyukov <dvyukov@google.com> writes: > On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: >> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >>> syzbot has found a reproducer for the following crash on: >>> >>> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 >>> git tree: linux-next >> >> I fetched linux-next but don't have 5ed5da74de9e. > > Hi Bruce, > > +Stephen for the disappeared linux-next commit. > > On the dashboard link you can see that it also happened on a more > recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > now in linux-next. > >> I'm also not sure why I'm on the cc for this. > > You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > as maintainer of the file, which is the file where the crash happened. You need to use your reproducer to bisect and find the commit that caused this. Otherwise you will continue to confuse people. get_maintainer.pl is not a good target for automated reporting especially against linux-next. Eric ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-16 4:01 ` Eric W. Biederman @ 2018-08-17 17:26 ` Dmitry Vyukov 2018-08-17 18:22 ` Eric W. Biederman 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Vyukov @ 2018-08-17 17:26 UTC (permalink / raw) To: Eric W. Biederman Cc: J. Bruce Fields, Stephen Rothwell, syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > Dmitry Vyukov <dvyukov@google.com> writes: > >> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: >>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >>>> syzbot has found a reproducer for the following crash on: >>>> >>>> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 >>>> git tree: linux-next >>> >>> I fetched linux-next but don't have 5ed5da74de9e. >> >> Hi Bruce, >> >> +Stephen for the disappeared linux-next commit. >> >> On the dashboard link you can see that it also happened on a more >> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see >> now in linux-next. >> >>> I'm also not sure why I'm on the cc for this. >> >> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" >> as maintainer of the file, which is the file where the crash happened. > > You need to use your reproducer to bisect and find the commit that > caused this. Otherwise you will continue to confuse people. > > get_maintainer.pl is not a good target for automated reporting > especially against linux-next. Hi Eric, We will do bisection. But I afraid it will not give perfect attribution for a number of reasons: - broken build/boot which happens sometimes for prolonged periods and prohibits bisection - elusive races that can't be reproduced reliably and thus bisection can give wrong results - bugs introduced too long ago (e.g. author email is not even valid today) - reproducers triggering more than 1 bug, so base bisection commit can actually be for another bug, or bisection can switch from one bug to another - last but not least, bugs without reproducers Bisection will add useful information to the bug report, but it will not necessary make attribution better than it is now. Do you have more examples where bugs were misreported? From what I see current attrition works well. There are episodic fallouts, but well, nothing is perfect in this world. Humans don't bisect frequently and misreport sometimes. I think we just need to re-route bugs in such cases. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-17 17:26 ` Dmitry Vyukov @ 2018-08-17 18:22 ` Eric W. Biederman 2018-08-17 18:38 ` J. Bruce Fields 2018-08-17 18:42 ` Dmitry Vyukov 0 siblings, 2 replies; 12+ messages in thread From: Eric W. Biederman @ 2018-08-17 18:22 UTC (permalink / raw) To: Dmitry Vyukov Cc: J. Bruce Fields, Stephen Rothwell, syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro Dmitry Vyukov <dvyukov@google.com> writes: > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman > <ebiederm@xmission.com> wrote: >> Dmitry Vyukov <dvyukov@google.com> writes: >> >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: >>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >>>>> syzbot has found a reproducer for the following crash on: >>>>> >>>>> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 >>>>> git tree: linux-next >>>> >>>> I fetched linux-next but don't have 5ed5da74de9e. >>> >>> Hi Bruce, >>> >>> +Stephen for the disappeared linux-next commit. >>> >>> On the dashboard link you can see that it also happened on a more >>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see >>> now in linux-next. >>> >>>> I'm also not sure why I'm on the cc for this. >>> >>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" >>> as maintainer of the file, which is the file where the crash happened. >> >> You need to use your reproducer to bisect and find the commit that >> caused this. Otherwise you will continue to confuse people. >> >> get_maintainer.pl is not a good target for automated reporting >> especially against linux-next. > > Hi Eric, > > We will do bisection. > But I afraid it will not give perfect attribution for a number of reasons: > - broken build/boot which happens sometimes for prolonged periods and > prohibits bisection > - elusive races that can't be reproduced reliably and thus bisection > can give wrong results > - bugs introduced too long ago (e.g. author email is not even valid today) > - reproducers triggering more than 1 bug, so base bisection commit > can actually be for another bug, or bisection can switch from one bug > to another > - last but not least, bugs without reproducers > Bisection will add useful information to the bug report, but it will > not necessary make attribution better than it is now. > > Do you have more examples where bugs were misreported? From what I see > current attrition works well. There are episodic fallouts, but well, > nothing is perfect in this world. Humans don't bisect frequently and > misreport sometimes. I think we just need to re-route bugs in such > cases. I have yet to see syzbot make a good report. Especially against linux-next. Eric ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-17 18:22 ` Eric W. Biederman @ 2018-08-17 18:38 ` J. Bruce Fields 2018-08-17 18:42 ` Dmitry Vyukov 1 sibling, 0 replies; 12+ messages in thread From: J. Bruce Fields @ 2018-08-17 18:38 UTC (permalink / raw) To: Eric W. Biederman Cc: Dmitry Vyukov, Stephen Rothwell, syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro On Fri, Aug 17, 2018 at 01:22:31PM -0500, Eric W. Biederman wrote: > Dmitry Vyukov <dvyukov@google.com> writes: > > > On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman > > <ebiederm@xmission.com> wrote: > >> Dmitry Vyukov <dvyukov@google.com> writes: > >> > >>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: > >>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: > >>>>> syzbot has found a reproducer for the following crash on: > >>>>> > >>>>> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 > >>>>> git tree: linux-next > >>>> > >>>> I fetched linux-next but don't have 5ed5da74de9e. > >>> > >>> Hi Bruce, > >>> > >>> +Stephen for the disappeared linux-next commit. > >>> > >>> On the dashboard link you can see that it also happened on a more > >>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see > >>> now in linux-next. > >>> > >>>> I'm also not sure why I'm on the cc for this. > >>> > >>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" > >>> as maintainer of the file, which is the file where the crash happened. > >> > >> You need to use your reproducer to bisect and find the commit that > >> caused this. Otherwise you will continue to confuse people. > >> > >> get_maintainer.pl is not a good target for automated reporting > >> especially against linux-next. > > > > Hi Eric, > > > > We will do bisection. > > But I afraid it will not give perfect attribution for a number of reasons: > > - broken build/boot which happens sometimes for prolonged periods and > > prohibits bisection > > - elusive races that can't be reproduced reliably and thus bisection > > can give wrong results > > - bugs introduced too long ago (e.g. author email is not even valid today) > > - reproducers triggering more than 1 bug, so base bisection commit > > can actually be for another bug, or bisection can switch from one bug > > to another > > - last but not least, bugs without reproducers > > Bisection will add useful information to the bug report, but it will > > not necessary make attribution better than it is now. > > > > Do you have more examples where bugs were misreported? From what I see > > current attrition works well. There are episodic fallouts, but well, > > nothing is perfect in this world. Humans don't bisect frequently and > > misreport sometimes. I think we just need to re-route bugs in such > > cases. > > I have yet to see syzbot make a good report. Especially against > linux-next. It did result in a fix (thanks!): https://lkml.org/lkml/2018/8/16/47 So I'd call that a better-than-nothing report if not a great report? There's some value just in timeliness; it's a lot easier for me to fix a bug that I introduced in the last few days, with the change still fresh in my mind.... --b. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: general protection fault in send_sigurg_to_task 2018-08-17 18:22 ` Eric W. Biederman 2018-08-17 18:38 ` J. Bruce Fields @ 2018-08-17 18:42 ` Dmitry Vyukov 1 sibling, 0 replies; 12+ messages in thread From: Dmitry Vyukov @ 2018-08-17 18:42 UTC (permalink / raw) To: Eric W. Biederman Cc: J. Bruce Fields, Stephen Rothwell, syzbot, jlayton, linux-fsdevel, LKML, syzkaller-bugs, Al Viro On Fri, Aug 17, 2018 at 11:22 AM, Eric W. Biederman <ebiederm@xmission.com> wrote: > Dmitry Vyukov <dvyukov@google.com> writes: > >> On Wed, Aug 15, 2018 at 9:01 PM, Eric W. Biederman >> <ebiederm@xmission.com> wrote: >>> Dmitry Vyukov <dvyukov@google.com> writes: >>> >>>> On Tue, Aug 14, 2018 at 12:11 PM, J. Bruce Fields <bfields@fieldses.org> wrote: >>>>> On Mon, Aug 13, 2018 at 06:33:02AM -0700, syzbot wrote: >>>>>> syzbot has found a reproducer for the following crash on: >>>>>> >>>>>> HEAD commit: 5ed5da74de9e Add linux-next specific files for 20180813 >>>>>> git tree: linux-next >>>>> >>>>> I fetched linux-next but don't have 5ed5da74de9e. >>>> >>>> Hi Bruce, >>>> >>>> +Stephen for the disappeared linux-next commit. >>>> >>>> On the dashboard link you can see that it also happened on a more >>>> recent commit 4e8b38549b50459a22573d756dd1f4e1963c2a8d that I do see >>>> now in linux-next. >>>> >>>>> I'm also not sure why I'm on the cc for this. >>>> >>>> You've been pointed to by "./scripts/get_maintainer.pl -f fs/fcntl.c" >>>> as maintainer of the file, which is the file where the crash happened. >>> >>> You need to use your reproducer to bisect and find the commit that >>> caused this. Otherwise you will continue to confuse people. >>> >>> get_maintainer.pl is not a good target for automated reporting >>> especially against linux-next. >> >> Hi Eric, >> >> We will do bisection. >> But I afraid it will not give perfect attribution for a number of reasons: >> - broken build/boot which happens sometimes for prolonged periods and >> prohibits bisection >> - elusive races that can't be reproduced reliably and thus bisection >> can give wrong results >> - bugs introduced too long ago (e.g. author email is not even valid today) >> - reproducers triggering more than 1 bug, so base bisection commit >> can actually be for another bug, or bisection can switch from one bug >> to another >> - last but not least, bugs without reproducers >> Bisection will add useful information to the bug report, but it will >> not necessary make attribution better than it is now. >> >> Do you have more examples where bugs were misreported? From what I see >> current attrition works well. There are episodic fallouts, but well, >> nothing is perfect in this world. Humans don't bisect frequently and >> misreport sometimes. I think we just need to re-route bugs in such >> cases. > > I have yet to see syzbot make a good report. Especially against > linux-next. Well, first of all, we are not aware of any massive problems because nobody tells us. What are the systematic problems that affect lots of reports? I took few recent ones. Anything wrong with them? https://lkml.org/lkml/2018/7/15/230 https://lkml.org/lkml/2018/7/18/992 https://lkml.org/lkml/2018/4/19/705 https://groups.google.com/forum/#!msg/syzkaller-bugs/F7KnbAmMa7E/VSbaYHyQCAAJ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2018-08-17 18:43 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-08-13 12:54 general protection fault in send_sigurg_to_task syzbot 2018-08-13 13:33 ` syzbot 2018-08-14 19:11 ` J. Bruce Fields 2018-08-14 20:50 ` Dmitry Vyukov 2018-08-15 0:11 ` Stephen Rothwell 2018-08-15 18:53 ` J. Bruce Fields 2018-08-15 20:35 ` J. Bruce Fields 2018-08-16 4:01 ` Eric W. Biederman 2018-08-17 17:26 ` Dmitry Vyukov 2018-08-17 18:22 ` Eric W. Biederman 2018-08-17 18:38 ` J. Bruce Fields 2018-08-17 18:42 ` Dmitry Vyukov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).