Hello,
syzbot found the following crash on:
HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
kernel config: https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
dashboard link: https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
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: [email protected]
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x188/0x20d lib/dump_stack.c:118
assign_lock_key kernel/locking/lockdep.c:880 [inline]
register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
__lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
_raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
wake_up_worker kernel/workqueue.c:836 [inline]
insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
__queue_work+0x50d/0x1280 kernel/workqueue.c:1488
call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
expire_timers kernel/time/timer.c:1444 [inline]
__run_timers kernel/time/timer.c:1773 [inline]
__run_timers kernel/time/timer.c:1740 [inline]
run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
__do_softirq+0x26c/0x99d kernel/softirq.c:292
invoke_softirq kernel/softirq.c:373 [inline]
irq_exit+0x192/0x1d0 kernel/softirq.c:413
exiting_irq arch/x86/include/asm/apic.h:546 [inline]
smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
</IRQ>
RIP: 0010:slow_down_io arch/x86/include/asm/paravirt.h:42 [inline]
RIP: 0010:outb_p arch/x86/include/asm/io.h:334 [inline]
RIP: 0010:vga_io_w include/video/vga.h:209 [inline]
RIP: 0010:vga_io_rgfx include/video/vga.h:388 [inline]
RIP: 0010:setcolor drivers/video/fbdev/vga16fb.c:170 [inline]
RIP: 0010:vga_imageblit_expand drivers/video/fbdev/vga16fb.c:1164 [inline]
RIP: 0010:vga16fb_imageblit+0x91b/0x2210 drivers/video/fbdev/vga16fb.c:1260
Code: 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 0f b6 04 02 84 c0 74 09 3c 03 7f 05 e8 91 43 f7 fd 41 8b 5f 10 31 c0 ba ce 03 00 00 ee <48> c7 c2 b8 b3 73 89 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 80
RSP: 0018:ffffc900163cf5a0 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff13
RAX: 0000000000000000 RBX: 0000000000000007 RCX: ffffc90001a49000
RDX: 00000000000003ce RSI: ffffffff83b7a8ce RDI: ffffc900163cf748
RBP: ffffc900163cf73c R08: ffff88803ac523c0 R09: 0000000000000000
R10: ffffed10431bd353 R11: ffff888218de9a9f R12: 0000000000000000
R13: ffff8880a3500f00 R14: 0000000000000001 R15: ffffc900163cf738
bit_putcs_unaligned drivers/video/fbdev/core/bitblit.c:139 [inline]
bit_putcs+0x910/0xe10 drivers/video/fbdev/core/bitblit.c:188
fbcon_putcs+0x345/0x3f0 drivers/video/fbdev/core/fbcon.c:1360
do_update_region+0x398/0x630 drivers/tty/vt/vt.c:677
redraw_screen+0x646/0x770 drivers/tty/vt/vt.c:1022
fbcon_blank+0x8ca/0xc10 drivers/video/fbdev/core/fbcon.c:2421
do_unblank_screen drivers/tty/vt/vt.c:4286 [inline]
do_unblank_screen+0x23c/0x420 drivers/tty/vt/vt.c:4254
vt_ioctl+0xdc0/0x2470 drivers/tty/vt/vt_ioctl.c:490
tty_ioctl+0xedd/0x1440 drivers/tty/tty_io.c:2656
vfs_ioctl fs/ioctl.c:47 [inline]
ksys_ioctl+0x11a/0x180 fs/ioctl.c:763
__do_sys_ioctl fs/ioctl.c:772 [inline]
__se_sys_ioctl fs/ioctl.c:770 [inline]
__x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:770
do_syscall_64+0xf6/0x7d0 arch/x86/entry/common.c:294
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45c849
Code: ad b6 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 7b b6 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f91f6f81c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f91f6f826d4 RCX: 000000000045c849
RDX: 0000000000000000 RSI: 0000000000004b3a RDI: 0000000000000003
RBP: 000000000076bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 0000000000000573 R14: 00000000004c8075 R15: 000000000076bf0c
---
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 [email protected].
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> dashboard link: https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> 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: [email protected]
>
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x188/0x20d lib/dump_stack.c:118
> assign_lock_key kernel/locking/lockdep.c:880 [inline]
> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
copy_process(). This should be impossible. Very odd.
> wake_up_worker kernel/workqueue.c:836 [inline]
> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> expire_timers kernel/time/timer.c:1444 [inline]
> __run_timers kernel/time/timer.c:1773 [inline]
> __run_timers kernel/time/timer.c:1740 [inline]
> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> __do_softirq+0x26c/0x99d kernel/softirq.c:292
> invoke_softirq kernel/softirq.c:373 [inline]
> irq_exit+0x192/0x1d0 kernel/softirq.c:413
> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> </IRQ>
On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra <[email protected]> wrote:
>
> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> > git tree: upstream
> > console output: https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > dashboard link: https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > 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: [email protected]
> >
> > INFO: trying to register non-static key.
> > the code is fine but needs lockdep annotation.
> > turning off the locking correctness validator.
> > CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > Call Trace:
> > <IRQ>
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x188/0x20d lib/dump_stack.c:118
> > assign_lock_key kernel/locking/lockdep.c:880 [inline]
> > register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> > __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> > lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> > __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> > _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> > try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
>
> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> copy_process(). This should be impossible. Very odd.
The stack mentions fbdev, which is a red flag at the moment. There are
a dozen of bad bugs in fbdev and around. Just few days ago Andy
pointed to another "impossible" crash "general protection fault in
do_syscall_64" which is related to dri:
https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
There are probably more random manifestations of these bugs already,
and I guess we will be getting more.
+fbdev maintainers
> > wake_up_worker kernel/workqueue.c:836 [inline]
> > insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> > __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> > call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> > expire_timers kernel/time/timer.c:1444 [inline]
> > __run_timers kernel/time/timer.c:1773 [inline]
> > __run_timers kernel/time/timer.c:1740 [inline]
> > run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> > __do_softirq+0x26c/0x99d kernel/softirq.c:292
> > invoke_softirq kernel/softirq.c:373 [inline]
> > irq_exit+0x192/0x1d0 kernel/softirq.c:413
> > exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> > smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> > apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> > </IRQ>
>
> --
> 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 [email protected].
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20200331095737.GO20730%40hirez.programming.kicks-ass.net.
On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra <[email protected]> wrote:
>>
>> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
>>> git tree: upstream
>>> console output: https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686&u=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
>>> kernel config: https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8&u=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
>>> dashboard link: https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b&u=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
>>> 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: [email protected]
>>>
>>> INFO: trying to register non-static key.
>>> the code is fine but needs lockdep annotation.
>>> turning off the locking correctness validator.
>>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>> Call Trace:
>>> <IRQ>
>>> __dump_stack lib/dump_stack.c:77 [inline]
>>> dump_stack+0x188/0x20d lib/dump_stack.c:118
>>> assign_lock_key kernel/locking/lockdep.c:880 [inline]
>>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
>>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
>>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
>>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
>>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
>>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
>>
>> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
>> copy_process(). This should be impossible. Very odd.
>
> The stack mentions fbdev, which is a red flag at the moment. There are
> a dozen of bad bugs in fbdev and around. Just few days ago Andy
> pointed to another "impossible" crash "general protection fault in
> do_syscall_64" which is related to dri:
> https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b&u=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e&u=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
>
> There are probably more random manifestations of these bugs already,
> and I guess we will be getting more.
>
> +fbdev maintainers
Thank you for the report.
fbdev is in the maintenance mode and no new features or drivers are
being added so syzbot reports are not for a new bugs (regressions) and
are not a priority (at least to me).
I have only resources to review/merge pending fbdev patches from time
to time so any help in fixing these syzbot reports is welcomed (there
have been a few fbdev related syzbot reports recently).
Also please note that fbdev is maintained through drm-misc tree so
patches can also be handled by other drm-misc maintainers in case I'm
not available / busy with other things.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
>>> wake_up_worker kernel/workqueue.c:836 [inline]
>>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
>>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
>>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
>>> expire_timers kernel/time/timer.c:1444 [inline]
>>> __run_timers kernel/time/timer.c:1773 [inline]
>>> __run_timers kernel/time/timer.c:1740 [inline]
>>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
>>> __do_softirq+0x26c/0x99d kernel/softirq.c:292
>>> invoke_softirq kernel/softirq.c:373 [inline]
>>> irq_exit+0x192/0x1d0 kernel/softirq.c:413
>>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
>>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
>>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
>>> </IRQ>
On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
<[email protected]> wrote:
>
>
> On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra <[email protected]> wrote:
> >>
> >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> >>> Hello,
> >>>
> >>> syzbot found the following crash on:
> >>>
> >>> HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> >>> git tree: upstream
> >>> console output: https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686&u=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
> >>> kernel config: https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8&u=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> >>> dashboard link: https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b&u=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> >>> 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: [email protected]
> >>>
> >>> INFO: trying to register non-static key.
> >>> the code is fine but needs lockdep annotation.
> >>> turning off the locking correctness validator.
> >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> >>> Call Trace:
> >>> <IRQ>
> >>> __dump_stack lib/dump_stack.c:77 [inline]
> >>> dump_stack+0x188/0x20d lib/dump_stack.c:118
> >>> assign_lock_key kernel/locking/lockdep.c:880 [inline]
> >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
> >>
> >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> >> copy_process(). This should be impossible. Very odd.
> >
> > The stack mentions fbdev, which is a red flag at the moment. There are
> > a dozen of bad bugs in fbdev and around. Just few days ago Andy
> > pointed to another "impossible" crash "general protection fault in
> > do_syscall_64" which is related to dri:
> > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b&u=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e&u=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
> >
> > There are probably more random manifestations of these bugs already,
> > and I guess we will be getting more.
> >
> > +fbdev maintainers
>
> Thank you for the report.
>
> fbdev is in the maintenance mode and no new features or drivers are
> being added so syzbot reports are not for a new bugs (regressions) and
> are not a priority (at least to me).
Yup same here, I've seen a pile of syzbot reports for fbdev (and also
vt, or combinations of them since fbdev is linked to vt through fbcon)
fly by. But I really don't have to deal with these, my recommendation
to anyone who cares about security are:
- Don't enable vt
- Don't enable fbdev
All that code has been developed long ago, in a much more innocent
time. If someone wants to fix this you'd not just need to fix all the
syzbot stuff, but also ramp up a full testsuite for all the ioctl, and
all the corner-cases. Plus also fix some of the horrendous locking in
there, probably.
Multi-year effort, easily.
Regressions I'll obviously try to handle, but none of these are. It's
just syzbot has become smarter at hitting bugs in fbdev and vt
subsystems (or maybe the hw the virtual machines emulate has become
more varied, some of the reports are for fun stuff like vgacon ...).
Cheers, Daniel
> I have only resources to review/merge pending fbdev patches from time
> to time so any help in fixing these syzbot reports is welcomed (there
> have been a few fbdev related syzbot reports recently).
>
> Also please note that fbdev is maintained through drm-misc tree so
> patches can also be handled by other drm-misc maintainers in case I'm
> not available / busy with other things.
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
>
> >>> wake_up_worker kernel/workqueue.c:836 [inline]
> >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> >>> expire_timers kernel/time/timer.c:1444 [inline]
> >>> __run_timers kernel/time/timer.c:1773 [inline]
> >>> __run_timers kernel/time/timer.c:1740 [inline]
> >>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> >>> __do_softirq+0x26c/0x99d kernel/softirq.c:292
> >>> invoke_softirq kernel/softirq.c:373 [inline]
> >>> irq_exit+0x192/0x1d0 kernel/softirq.c:413
> >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> >>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> >>> </IRQ>
> _______________________________________________
> dri-devel mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Mar 31, 2020 at 2:50 PM Daniel Vetter <[email protected]> wrote:
>
> On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> >
> >
> > On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra <[email protected]> wrote:
> > >>
> > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > >>> Hello,
> > >>>
> > >>> syzbot found the following crash on:
> > >>>
> > >>> HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> > >>> git tree: upstream
> > >>> console output: https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686&u=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
> > >>> kernel config: https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8&u=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > >>> dashboard link: https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b&u=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > >>> 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: [email protected]
> > >>>
> > >>> INFO: trying to register non-static key.
> > >>> the code is fine but needs lockdep annotation.
> > >>> turning off the locking correctness validator.
> > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > >>> Call Trace:
> > >>> <IRQ>
> > >>> __dump_stack lib/dump_stack.c:77 [inline]
> > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118
> > >>> assign_lock_key kernel/locking/lockdep.c:880 [inline]
> > >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> > >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> > >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> > >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> > >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> > >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
> > >>
> > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> > >> copy_process(). This should be impossible. Very odd.
> > >
> > > The stack mentions fbdev, which is a red flag at the moment. There are
> > > a dozen of bad bugs in fbdev and around. Just few days ago Andy
> > > pointed to another "impossible" crash "general protection fault in
> > > do_syscall_64" which is related to dri:
> > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b&u=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e&u=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
> > >
> > > There are probably more random manifestations of these bugs already,
> > > and I guess we will be getting more.
> > >
> > > +fbdev maintainers
> >
> > Thank you for the report.
> >
> > fbdev is in the maintenance mode and no new features or drivers are
> > being added so syzbot reports are not for a new bugs (regressions) and
> > are not a priority (at least to me).
>
> Yup same here, I've seen a pile of syzbot reports for fbdev (and also
> vt, or combinations of them since fbdev is linked to vt through fbcon)
> fly by. But I really don't have to deal with these, my recommendation
> to anyone who cares about security are:
> - Don't enable vt
> - Don't enable fbdev
>
> All that code has been developed long ago, in a much more innocent
> time. If someone wants to fix this you'd not just need to fix all the
> syzbot stuff, but also ramp up a full testsuite for all the ioctl, and
> all the corner-cases. Plus also fix some of the horrendous locking in
> there, probably.
>
> Multi-year effort, easily.
>
> Regressions I'll obviously try to handle, but none of these are. It's
> just syzbot has become smarter at hitting bugs in fbdev and vt
> subsystems (or maybe the hw the virtual machines emulate has become
> more varied, some of the reports are for fun stuff like vgacon ...).
Forgot to mention: Just yesterday I did merge an fbcon overflow bugfix:
commit b139f8b00db4a8ea75a4174346eafa48041aa489 (HEAD ->
drm-misc-next-fixes, drm-misc/for-linux-next,
drm-misc/drm-misc-next-fixes)
Author: Qiujun Huang <[email protected]>
Date: Sun Mar 29 16:56:47 2020 +0800
fbcon: fix null-ptr-deref in fbcon_switch
There's also a pending patch in the vt subsystem to catch overflow for
unicode fonts on consoles, that's reviewed and waiting for Greg to
pick it up.
-Daniel
> Cheers, Daniel
>
> > I have only resources to review/merge pending fbdev patches from time
> > to time so any help in fixing these syzbot reports is welcomed (there
> > have been a few fbdev related syzbot reports recently).
> >
> > Also please note that fbdev is maintained through drm-misc tree so
> > patches can also be handled by other drm-misc maintainers in case I'm
> > not available / busy with other things.
> >
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >
> > >>> wake_up_worker kernel/workqueue.c:836 [inline]
> > >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> > >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> > >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> > >>> expire_timers kernel/time/timer.c:1444 [inline]
> > >>> __run_timers kernel/time/timer.c:1773 [inline]
> > >>> __run_timers kernel/time/timer.c:1740 [inline]
> > >>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> > >>> __do_softirq+0x26c/0x99d kernel/softirq.c:292
> > >>> invoke_softirq kernel/softirq.c:373 [inline]
> > >>> irq_exit+0x192/0x1d0 kernel/softirq.c:413
> > >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> > >>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> > >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> > >>> </IRQ>
> > _______________________________________________
> > dri-devel mailing list
> > [email protected]
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Tue, Mar 31, 2020 at 2:50 PM Daniel Vetter <[email protected]> wrote:
>
> On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
> <[email protected]> wrote:
> >
> >
> > On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra <[email protected]> wrote:
> > >>
> > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > >>> Hello,
> > >>>
> > >>> syzbot found the following crash on:
> > >>>
> > >>> HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> > >>> git tree: upstream
> > >>> console output: https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686&u=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
> > >>> kernel config: https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8&u=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > >>> dashboard link: https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b&u=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > >>> 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: [email protected]
> > >>>
> > >>> INFO: trying to register non-static key.
> > >>> the code is fine but needs lockdep annotation.
> > >>> turning off the locking correctness validator.
> > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > >>> Call Trace:
> > >>> <IRQ>
> > >>> __dump_stack lib/dump_stack.c:77 [inline]
> > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118
> > >>> assign_lock_key kernel/locking/lockdep.c:880 [inline]
> > >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> > >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> > >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> > >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> > >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> > >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
> > >>
> > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> > >> copy_process(). This should be impossible. Very odd.
> > >
> > > The stack mentions fbdev, which is a red flag at the moment. There are
> > > a dozen of bad bugs in fbdev and around. Just few days ago Andy
> > > pointed to another "impossible" crash "general protection fault in
> > > do_syscall_64" which is related to dri:
> > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b&u=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e&u=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
> > >
> > > There are probably more random manifestations of these bugs already,
> > > and I guess we will be getting more.
> > >
> > > +fbdev maintainers
> >
> > Thank you for the report.
> >
> > fbdev is in the maintenance mode and no new features or drivers are
> > being added so syzbot reports are not for a new bugs (regressions) and
> > are not a priority (at least to me).
>
> Yup same here, I've seen a pile of syzbot reports for fbdev (and also
> vt, or combinations of them since fbdev is linked to vt through fbcon)
> fly by. But I really don't have to deal with these, my recommendation
> to anyone who cares about security are:
> - Don't enable vt
> - Don't enable fbdev
1. How do we deliver this message to relevant people?
Because:
$ grep FBDEV syzkaller/dashboard/config/upstream-kasan.config
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
# CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
CONFIG_XEN_FBDEV_FRONTEND=y
and my current work machine:
$ grep FBDEV /boot/config-5.2.17-1-amd64
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
# CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
CONFIG_XEN_FBDEV_FRONTEND=y
2. What do we do with fbdev testing on syzbot? Is there a way to
disable all of the unsupported stuff? But if we disable it, we don't
find any regressions as well. And in the end that's what is in the
mainline kernel and is still enabled in distros (at least in the 2
real configs I can grep now).
> All that code has been developed long ago, in a much more innocent
> time. If someone wants to fix this you'd not just need to fix all the
> syzbot stuff, but also ramp up a full testsuite for all the ioctl, and
> all the corner-cases. Plus also fix some of the horrendous locking in
> there, probably.
>
> Multi-year effort, easily.
>
> Regressions I'll obviously try to handle, but none of these are. It's
> just syzbot has become smarter at hitting bugs in fbdev and vt
> subsystems (or maybe the hw the virtual machines emulate has become
> more varied, some of the reports are for fun stuff like vgacon ...).
>
> Cheers, Daniel
>
> > I have only resources to review/merge pending fbdev patches from time
> > to time so any help in fixing these syzbot reports is welcomed (there
> > have been a few fbdev related syzbot reports recently).
> >
> > Also please note that fbdev is maintained through drm-misc tree so
> > patches can also be handled by other drm-misc maintainers in case I'm
> > not available / busy with other things.
> >
> > Best regards,
> > --
> > Bartlomiej Zolnierkiewicz
> > Samsung R&D Institute Poland
> > Samsung Electronics
> >
> > >>> wake_up_worker kernel/workqueue.c:836 [inline]
> > >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> > >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> > >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> > >>> expire_timers kernel/time/timer.c:1444 [inline]
> > >>> __run_timers kernel/time/timer.c:1773 [inline]
> > >>> __run_timers kernel/time/timer.c:1740 [inline]
> > >>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> > >>> __do_softirq+0x26c/0x99d kernel/softirq.c:292
> > >>> invoke_softirq kernel/softirq.c:373 [inline]
> > >>> irq_exit+0x192/0x1d0 kernel/softirq.c:413
> > >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> > >>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> > >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> > >>> </IRQ>
> > _______________________________________________
> > dri-devel mailing list
> > [email protected]
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, Apr 1, 2020 at 10:47 AM Dmitry Vyukov <[email protected]> wrote:
>
> On Tue, Mar 31, 2020 at 2:50 PM Daniel Vetter <[email protected]> wrote:
> >
> > On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
> > <[email protected]> wrote:
> > >
> > >
> > > On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra <[email protected]> wrote:
> > > >>
> > > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > > >>> Hello,
> > > >>>
> > > >>> syzbot found the following crash on:
> > > >>>
> > > >>> HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> > > >>> git tree: upstream
> > > >>> console output: https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686&u=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
> > > >>> kernel config: https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8&u=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > > >>> dashboard link: https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b&u=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > > >>> 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: [email protected]
> > > >>>
> > > >>> INFO: trying to register non-static key.
> > > >>> the code is fine but needs lockdep annotation.
> > > >>> turning off the locking correctness validator.
> > > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > > >>> Call Trace:
> > > >>> <IRQ>
> > > >>> __dump_stack lib/dump_stack.c:77 [inline]
> > > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118
> > > >>> assign_lock_key kernel/locking/lockdep.c:880 [inline]
> > > >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> > > >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> > > >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> > > >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> > > >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> > > >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
> > > >>
> > > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> > > >> copy_process(). This should be impossible. Very odd.
> > > >
> > > > The stack mentions fbdev, which is a red flag at the moment. There are
> > > > a dozen of bad bugs in fbdev and around. Just few days ago Andy
> > > > pointed to another "impossible" crash "general protection fault in
> > > > do_syscall_64" which is related to dri:
> > > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b&u=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> > > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e&u=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
> > > >
> > > > There are probably more random manifestations of these bugs already,
> > > > and I guess we will be getting more.
> > > >
> > > > +fbdev maintainers
> > >
> > > Thank you for the report.
> > >
> > > fbdev is in the maintenance mode and no new features or drivers are
> > > being added so syzbot reports are not for a new bugs (regressions) and
> > > are not a priority (at least to me).
> >
> > Yup same here, I've seen a pile of syzbot reports for fbdev (and also
> > vt, or combinations of them since fbdev is linked to vt through fbcon)
> > fly by. But I really don't have to deal with these, my recommendation
> > to anyone who cares about security are:
> > - Don't enable vt
> > - Don't enable fbdev
>
> 1. How do we deliver this message to relevant people?
>
> Because:
>
> $ grep FBDEV syzkaller/dashboard/config/upstream-kasan.config
> CONFIG_DRM_FBDEV_EMULATION=y
> CONFIG_DRM_FBDEV_OVERALLOC=100
> # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> CONFIG_XEN_FBDEV_FRONTEND=y
>
> and my current work machine:
>
> $ grep FBDEV /boot/config-5.2.17-1-amd64
> CONFIG_DRM_FBDEV_EMULATION=y
> CONFIG_DRM_FBDEV_OVERALLOC=100
> # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> CONFIG_XEN_FBDEV_FRONTEND=y
Yeah I know it's been like this since forever. In theory you could
build a fbdev/fbcon less distro since years (the last bit for a proof
of concept was kmscon/systemd-consoled), but the amount of investment
into classic linux desktop is so little that it's impossible to get
this funded. CrOS fixed this a while ago iirc though.
I think to fix the syzbot issues all we'd need is a competent intern
for a few months, that should take care of the worst stuff. Obviously
wont include getting a test suite going, nor fixing any of the
fundamental issues. But duct-taping over all the bugs should be
possible (it's what we've been doing for well over 10 years by now in
fbdev/fbocn/vt code anyway). I'd be willing to help mentoring, but
that's about all I can do.
Adding Matthew Garret, I have discussed with him in the past finding
some funding for linux desktop stuff like this.
> 2. What do we do with fbdev testing on syzbot? Is there a way to
> disable all of the unsupported stuff? But if we disable it, we don't
> find any regressions as well. And in the end that's what is in the
> mainline kernel and is still enabled in distros (at least in the 2
> real configs I can grep now).
This would be bad I agree, but it's not any worse than the state of
things the past 10 years. That's roughly for as long as fbdev has been
in maintainance only mode, meaning "we'll apply patches if they come".
Without Bart volunteering, we wouldn't even have that much really.
-Daniel
> > All that code has been developed long ago, in a much more innocent
> > time. If someone wants to fix this you'd not just need to fix all the
> > syzbot stuff, but also ramp up a full testsuite for all the ioctl, and
> > all the corner-cases. Plus also fix some of the horrendous locking in
> > there, probably.
> >
> > Multi-year effort, easily.
> >
> > Regressions I'll obviously try to handle, but none of these are. It's
> > just syzbot has become smarter at hitting bugs in fbdev and vt
> > subsystems (or maybe the hw the virtual machines emulate has become
> > more varied, some of the reports are for fun stuff like vgacon ...).
> >
> > Cheers, Daniel
> >
> > > I have only resources to review/merge pending fbdev patches from time
> > > to time so any help in fixing these syzbot reports is welcomed (there
> > > have been a few fbdev related syzbot reports recently).
> > >
> > > Also please note that fbdev is maintained through drm-misc tree so
> > > patches can also be handled by other drm-misc maintainers in case I'm
> > > not available / busy with other things.
> > >
> > > Best regards,
> > > --
> > > Bartlomiej Zolnierkiewicz
> > > Samsung R&D Institute Poland
> > > Samsung Electronics
> > >
> > > >>> wake_up_worker kernel/workqueue.c:836 [inline]
> > > >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> > > >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> > > >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> > > >>> expire_timers kernel/time/timer.c:1444 [inline]
> > > >>> __run_timers kernel/time/timer.c:1773 [inline]
> > > >>> __run_timers kernel/time/timer.c:1740 [inline]
> > > >>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> > > >>> __do_softirq+0x26c/0x99d kernel/softirq.c:292
> > > >>> invoke_softirq kernel/softirq.c:373 [inline]
> > > >>> irq_exit+0x192/0x1d0 kernel/softirq.c:413
> > > >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> > > >>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> > > >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> > > >>> </IRQ>
> > > _______________________________________________
> > > dri-devel mailing list
> > > [email protected]
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, Apr 1, 2020 at 10:59 AM Daniel Vetter <[email protected]> wrote:
>
> On Wed, Apr 1, 2020 at 10:47 AM Dmitry Vyukov <[email protected]> wrote:
> >
> > On Tue, Mar 31, 2020 at 2:50 PM Daniel Vetter <[email protected]> wrote:
> > >
> > > On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
> > > <[email protected]> wrote:
> > > >
> > > >
> > > > On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > > > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra <[email protected]> wrote:
> > > > >>
> > > > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > > > >>> Hello,
> > > > >>>
> > > > >>> syzbot found the following crash on:
> > > > >>>
> > > > >>> HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> > > > >>> git tree: upstream
> > > > >>> console output: https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686&u=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
> > > > >>> kernel config: https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8&u=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > > > >>> dashboard link: https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b&u=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > > > >>> 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: [email protected]
> > > > >>>
> > > > >>> INFO: trying to register non-static key.
> > > > >>> the code is fine but needs lockdep annotation.
> > > > >>> turning off the locking correctness validator.
> > > > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> > > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > > > >>> Call Trace:
> > > > >>> <IRQ>
> > > > >>> __dump_stack lib/dump_stack.c:77 [inline]
> > > > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118
> > > > >>> assign_lock_key kernel/locking/lockdep.c:880 [inline]
> > > > >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> > > > >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> > > > >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> > > > >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> > > > >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> > > > >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
> > > > >>
> > > > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> > > > >> copy_process(). This should be impossible. Very odd.
> > > > >
> > > > > The stack mentions fbdev, which is a red flag at the moment. There are
> > > > > a dozen of bad bugs in fbdev and around. Just few days ago Andy
> > > > > pointed to another "impossible" crash "general protection fault in
> > > > > do_syscall_64" which is related to dri:
> > > > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b&u=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> > > > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e&u=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
> > > > >
> > > > > There are probably more random manifestations of these bugs already,
> > > > > and I guess we will be getting more.
> > > > >
> > > > > +fbdev maintainers
> > > >
> > > > Thank you for the report.
> > > >
> > > > fbdev is in the maintenance mode and no new features or drivers are
> > > > being added so syzbot reports are not for a new bugs (regressions) and
> > > > are not a priority (at least to me).
> > >
> > > Yup same here, I've seen a pile of syzbot reports for fbdev (and also
> > > vt, or combinations of them since fbdev is linked to vt through fbcon)
> > > fly by. But I really don't have to deal with these, my recommendation
> > > to anyone who cares about security are:
> > > - Don't enable vt
> > > - Don't enable fbdev
> >
> > 1. How do we deliver this message to relevant people?
> >
> > Because:
> >
> > $ grep FBDEV syzkaller/dashboard/config/upstream-kasan.config
> > CONFIG_DRM_FBDEV_EMULATION=y
> > CONFIG_DRM_FBDEV_OVERALLOC=100
> > # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> > CONFIG_XEN_FBDEV_FRONTEND=y
> >
> > and my current work machine:
> >
> > $ grep FBDEV /boot/config-5.2.17-1-amd64
> > CONFIG_DRM_FBDEV_EMULATION=y
> > CONFIG_DRM_FBDEV_OVERALLOC=100
> > # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> > CONFIG_XEN_FBDEV_FRONTEND=y
>
> Yeah I know it's been like this since forever. In theory you could
> build a fbdev/fbcon less distro since years (the last bit for a proof
> of concept was kmscon/systemd-consoled), but the amount of investment
> into classic linux desktop is so little that it's impossible to get
> this funded. CrOS fixed this a while ago iirc though.
>
> I think to fix the syzbot issues all we'd need is a competent intern
> for a few months, that should take care of the worst stuff. Obviously
> wont include getting a test suite going, nor fixing any of the
> fundamental issues. But duct-taping over all the bugs should be
> possible (it's what we've been doing for well over 10 years by now in
> fbdev/fbocn/vt code anyway). I'd be willing to help mentoring, but
> that's about all I can do.
>
> Adding Matthew Garret, I have discussed with him in the past finding
> some funding for linux desktop stuff like this.
>
> > 2. What do we do with fbdev testing on syzbot? Is there a way to
> > disable all of the unsupported stuff? But if we disable it, we don't
> > find any regressions as well. And in the end that's what is in the
> > mainline kernel and is still enabled in distros (at least in the 2
> > real configs I can grep now).
>
> This would be bad I agree, but it's not any worse than the state of
> things the past 10 years. That's roughly for as long as fbdev has been
> in maintainance only mode, meaning "we'll apply patches if they come".
> Without Bart volunteering, we wouldn't even have that much really.
Oh wrt disabling fbdev: Make sure CONFIG_FB isn't set. Unfortunately a
pile of other things select that, for convenience (like
CONFIG_DRM_KMS_FB_HELPER).
That should get rid of all the problematic fbdev code.
From what I've seen in some of the syzbot mails flying by we also have
issues in vt and console code blowing up (not just on fbcon/fbdev, but
also e.g. on vgacon). That stuff you'll still hit. But maybe you can
trick Greg KH into fixing the vt/console.c issues, he just claimed
that :-P
-Daniel
>
> > > All that code has been developed long ago, in a much more innocent
> > > time. If someone wants to fix this you'd not just need to fix all the
> > > syzbot stuff, but also ramp up a full testsuite for all the ioctl, and
> > > all the corner-cases. Plus also fix some of the horrendous locking in
> > > there, probably.
> > >
> > > Multi-year effort, easily.
> > >
> > > Regressions I'll obviously try to handle, but none of these are. It's
> > > just syzbot has become smarter at hitting bugs in fbdev and vt
> > > subsystems (or maybe the hw the virtual machines emulate has become
> > > more varied, some of the reports are for fun stuff like vgacon ...).
> > >
> > > Cheers, Daniel
> > >
> > > > I have only resources to review/merge pending fbdev patches from time
> > > > to time so any help in fixing these syzbot reports is welcomed (there
> > > > have been a few fbdev related syzbot reports recently).
> > > >
> > > > Also please note that fbdev is maintained through drm-misc tree so
> > > > patches can also be handled by other drm-misc maintainers in case I'm
> > > > not available / busy with other things.
> > > >
> > > > Best regards,
> > > > --
> > > > Bartlomiej Zolnierkiewicz
> > > > Samsung R&D Institute Poland
> > > > Samsung Electronics
> > > >
> > > > >>> wake_up_worker kernel/workqueue.c:836 [inline]
> > > > >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> > > > >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> > > > >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> > > > >>> expire_timers kernel/time/timer.c:1444 [inline]
> > > > >>> __run_timers kernel/time/timer.c:1773 [inline]
> > > > >>> __run_timers kernel/time/timer.c:1740 [inline]
> > > > >>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> > > > >>> __do_softirq+0x26c/0x99d kernel/softirq.c:292
> > > > >>> invoke_softirq kernel/softirq.c:373 [inline]
> > > > >>> irq_exit+0x192/0x1d0 kernel/softirq.c:413
> > > > >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> > > > >>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> > > > >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> > > > >>> </IRQ>
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > [email protected]
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > >
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On Wed, Apr 1, 2020 at 11:06 AM Daniel Vetter <[email protected]> wrote:
> > > > On Tue, Mar 31, 2020 at 2:18 PM Bartlomiej Zolnierkiewicz
> > > > <[email protected]> wrote:
> > > > >
> > > > >
> > > > > On 3/31/20 12:18 PM, Dmitry Vyukov wrote:
> > > > > > On Tue, Mar 31, 2020 at 11:57 AM Peter Zijlstra <[email protected]> wrote:
> > > > > >>
> > > > > >> On Mon, Mar 30, 2020 at 10:01:12PM -0700, syzbot wrote:
> > > > > >>> Hello,
> > > > > >>>
> > > > > >>> syzbot found the following crash on:
> > > > > >>>
> > > > > >>> HEAD commit: 9420e8ad Merge tag 'for-linus' of git://git.kernel.org/pub..
> > > > > >>> git tree: upstream
> > > > > >>> console output: https://protect2.fireeye.com/url?k=0756a78d-5a9a6c49-07572cc2-0cc47a314e9a-e4dc8b657d340686&u=https://syzkaller.appspot.com/x/log.txt?x=1206ed4be00000
> > > > > >>> kernel config: https://protect2.fireeye.com/url?k=43211072-1eeddbb6-43209b3d-0cc47a314e9a-3bd45a19932c37c8&u=https://syzkaller.appspot.com/x/.config?x=27392dd2975fd692
> > > > > >>> dashboard link: https://protect2.fireeye.com/url?k=bf7a6153-e2b6aa97-bf7bea1c-0cc47a314e9a-c64073ee605efb7b&u=https://syzkaller.appspot.com/bug?extid=e84d7ebd1361da13c356
> > > > > >>> 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: [email protected]
> > > > > >>>
> > > > > >>> INFO: trying to register non-static key.
> > > > > >>> the code is fine but needs lockdep annotation.
> > > > > >>> turning off the locking correctness validator.
> > > > > >>> CPU: 1 PID: 1014 Comm: syz-executor.0 Not tainted 5.6.0-rc7-syzkaller #0
> > > > > >>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> > > > > >>> Call Trace:
> > > > > >>> <IRQ>
> > > > > >>> __dump_stack lib/dump_stack.c:77 [inline]
> > > > > >>> dump_stack+0x188/0x20d lib/dump_stack.c:118
> > > > > >>> assign_lock_key kernel/locking/lockdep.c:880 [inline]
> > > > > >>> register_lock_class+0x14c4/0x1540 kernel/locking/lockdep.c:1189
> > > > > >>> __lock_acquire+0xfc/0x3ca0 kernel/locking/lockdep.c:3836
> > > > > >>> lock_acquire+0x197/0x420 kernel/locking/lockdep.c:4484
> > > > > >>> __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
> > > > > >>> _raw_spin_lock_irqsave+0x8c/0xbf kernel/locking/spinlock.c:159
> > > > > >>> try_to_wake_up+0x9f/0x17c0 kernel/sched/core.c:2547
> > > > > >>
> > > > > >> That's p->pi_lock, which gets initialized in rt_mutex_init_task() in
> > > > > >> copy_process(). This should be impossible. Very odd.
> > > > > >
> > > > > > The stack mentions fbdev, which is a red flag at the moment. There are
> > > > > > a dozen of bad bugs in fbdev and around. Just few days ago Andy
> > > > > > pointed to another "impossible" crash "general protection fault in
> > > > > > do_syscall_64" which is related to dri:
> > > > > > https://protect2.fireeye.com/url?k=0cb8ad06-517466c2-0cb92649-0cc47a314e9a-a20c11191483c65b&u=https://syzkaller.appspot.com/bug?id=0ec7b2602b1ff40f0d34f38baa4ba1640727c3d9
> > > > > > https://protect2.fireeye.com/url?k=614292e3-3c8e5927-614319ac-0cc47a314e9a-aeda6d72c01a7b0e&u=https://groups.google.com/forum/#!msg/syzkaller-bugs/ePqhfYx0-8M/Q_Urt97iAAAJ
> > > > > >
> > > > > > There are probably more random manifestations of these bugs already,
> > > > > > and I guess we will be getting more.
> > > > > >
> > > > > > +fbdev maintainers
> > > > >
> > > > > Thank you for the report.
> > > > >
> > > > > fbdev is in the maintenance mode and no new features or drivers are
> > > > > being added so syzbot reports are not for a new bugs (regressions) and
> > > > > are not a priority (at least to me).
> > > >
> > > > Yup same here, I've seen a pile of syzbot reports for fbdev (and also
> > > > vt, or combinations of them since fbdev is linked to vt through fbcon)
> > > > fly by. But I really don't have to deal with these, my recommendation
> > > > to anyone who cares about security are:
> > > > - Don't enable vt
> > > > - Don't enable fbdev
> > >
> > > 1. How do we deliver this message to relevant people?
> > >
> > > Because:
> > >
> > > $ grep FBDEV syzkaller/dashboard/config/upstream-kasan.config
> > > CONFIG_DRM_FBDEV_EMULATION=y
> > > CONFIG_DRM_FBDEV_OVERALLOC=100
> > > # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> > > CONFIG_XEN_FBDEV_FRONTEND=y
> > >
> > > and my current work machine:
> > >
> > > $ grep FBDEV /boot/config-5.2.17-1-amd64
> > > CONFIG_DRM_FBDEV_EMULATION=y
> > > CONFIG_DRM_FBDEV_OVERALLOC=100
> > > # CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM is not set
> > > CONFIG_XEN_FBDEV_FRONTEND=y
> >
> > Yeah I know it's been like this since forever. In theory you could
> > build a fbdev/fbcon less distro since years (the last bit for a proof
> > of concept was kmscon/systemd-consoled), but the amount of investment
> > into classic linux desktop is so little that it's impossible to get
> > this funded. CrOS fixed this a while ago iirc though.
> >
> > I think to fix the syzbot issues all we'd need is a competent intern
> > for a few months, that should take care of the worst stuff. Obviously
> > wont include getting a test suite going, nor fixing any of the
> > fundamental issues. But duct-taping over all the bugs should be
> > possible (it's what we've been doing for well over 10 years by now in
> > fbdev/fbocn/vt code anyway). I'd be willing to help mentoring, but
> > that's about all I can do.
> >
> > Adding Matthew Garret, I have discussed with him in the past finding
> > some funding for linux desktop stuff like this.
I will keep this in mind. We _may_ get some interns this year who
_may_ be interested in fixing Linux kernel bugs (but otherwise
extending syzkaller descriptions).
FTR, there is also some follow up on twitter re extending
https://github.com/a13xp0p0v/kconfig-hardened-check to capture such
recommendations:
https://twitter.com/dvyukov/status/1245969522869309441
https://github.com/a13xp0p0v/kconfig-hardened-check/issues/38
> > > 2. What do we do with fbdev testing on syzbot? Is there a way to
> > > disable all of the unsupported stuff? But if we disable it, we don't
> > > find any regressions as well. And in the end that's what is in the
> > > mainline kernel and is still enabled in distros (at least in the 2
> > > real configs I can grep now).
> >
> > This would be bad I agree, but it's not any worse than the state of
> > things the past 10 years. That's roughly for as long as fbdev has been
> > in maintainance only mode, meaning "we'll apply patches if they come".
> > Without Bart volunteering, we wouldn't even have that much really.
>
> Oh wrt disabling fbdev: Make sure CONFIG_FB isn't set. Unfortunately a
> pile of other things select that, for convenience (like
> CONFIG_DRM_KMS_FB_HELPER).
>
> That should get rid of all the problematic fbdev code.
>
> From what I've seen in some of the syzbot mails flying by we also have
> issues in vt and console code blowing up (not just on fbcon/fbdev, but
> also e.g. on vgacon). That stuff you'll still hit. But maybe you can
> trick Greg KH into fixing the vt/console.c issues, he just claimed
> that :-P
> -Daniel
>
> >
> > > > All that code has been developed long ago, in a much more innocent
> > > > time. If someone wants to fix this you'd not just need to fix all the
> > > > syzbot stuff, but also ramp up a full testsuite for all the ioctl, and
> > > > all the corner-cases. Plus also fix some of the horrendous locking in
> > > > there, probably.
> > > >
> > > > Multi-year effort, easily.
> > > >
> > > > Regressions I'll obviously try to handle, but none of these are. It's
> > > > just syzbot has become smarter at hitting bugs in fbdev and vt
> > > > subsystems (or maybe the hw the virtual machines emulate has become
> > > > more varied, some of the reports are for fun stuff like vgacon ...).
> > > >
> > > > Cheers, Daniel
> > > >
> > > > > I have only resources to review/merge pending fbdev patches from time
> > > > > to time so any help in fixing these syzbot reports is welcomed (there
> > > > > have been a few fbdev related syzbot reports recently).
> > > > >
> > > > > Also please note that fbdev is maintained through drm-misc tree so
> > > > > patches can also be handled by other drm-misc maintainers in case I'm
> > > > > not available / busy with other things.
> > > > >
> > > > > Best regards,
> > > > > --
> > > > > Bartlomiej Zolnierkiewicz
> > > > > Samsung R&D Institute Poland
> > > > > Samsung Electronics
> > > > >
> > > > > >>> wake_up_worker kernel/workqueue.c:836 [inline]
> > > > > >>> insert_work+0x2ad/0x3a0 kernel/workqueue.c:1337
> > > > > >>> __queue_work+0x50d/0x1280 kernel/workqueue.c:1488
> > > > > >>> call_timer_fn+0x195/0x760 kernel/time/timer.c:1404
> > > > > >>> expire_timers kernel/time/timer.c:1444 [inline]
> > > > > >>> __run_timers kernel/time/timer.c:1773 [inline]
> > > > > >>> __run_timers kernel/time/timer.c:1740 [inline]
> > > > > >>> run_timer_softirq+0x412/0x1600 kernel/time/timer.c:1786
> > > > > >>> __do_softirq+0x26c/0x99d kernel/softirq.c:292
> > > > > >>> invoke_softirq kernel/softirq.c:373 [inline]
> > > > > >>> irq_exit+0x192/0x1d0 kernel/softirq.c:413
> > > > > >>> exiting_irq arch/x86/include/asm/apic.h:546 [inline]
> > > > > >>> smp_apic_timer_interrupt+0x19e/0x600 arch/x86/kernel/apic/apic.c:1146
> > > > > >>> apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:829
> > > > > >>> </IRQ>
> > > > > _______________________________________________
> > > > > dri-devel mailing list
> > > > > [email protected]
> > > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > > >
> > > >
> > > >
> > > > --
> > > > Daniel Vetter
> > > > Software Engineer, Intel Corporation
> > > > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> >
> >
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > +41 (0) 79 365 57 48 - http://blog.ffwll.ch
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch