On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov <[email protected]> wrote:
> Hello,
>
> The following program triggers GPF in drm_getcap:
>
> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <fcntl.h>
> #include <stddef.h>
> #include <stdint.h>
> #include <sys/ioctl.h>
> #include <sys/stat.h>
> #include <sys/syscall.h>
> #include <sys/types.h>
> #include <unistd.h>
>
> int main()
> {
> int fd = open("/dev/dri/card0", O_RDONLY);
> uint64_t data[2] = {0x11, 0x80};
> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
> return 0;
> }
>
>
> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
> Modules linked in:
> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: ffff8800310dc540 task.stack: ffff88003cbc0000
> RIP: 0010:[<ffffffff834ca87b>] [<ffffffff834ca87b>]
> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
> RSP: 0018:ffff88003cbc7c28 EFLAGS: 00010202
> RAX: 0000000000000058 RBX: ffff88003cbc7cf8 RCX: ffffc90001db0000
> RDX: 000000000000005d RSI: ffff88003cbc7cf8 RDI: 00000000000002c0
> RBP: ffff88003cbc7c50 R08: ffffed0007978fa1 R09: ffffed0007978fa0
> R10: ffff88003cbc7d07 R11: ffffed0007978fa1 R12: fffffffffffffff0
> R13: dffffc0000000000 R14: ffff88003bcc6850 R15: fffffffffffffff2
> FS: 00007fcbf4e03700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00000000006dce00 CR3: 0000000066135000 CR4: 00000000000006e0
> DR0: 000000000000001e DR1: 000000000000001e DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
> Stack:
> ffff88003c26db00 ffff88003cbc7cf8 ffffffff875a3000 ffffffff88cf0ee0
> fffffffffffffff2 ffff88003cbc7dc0 ffffffff834cb57c 000000000000e200
> 1ffff10000000001 ffffffff875a1ba0 ffffffff882ae930 0000000000000010
> Call Trace:
> [<ffffffff834cb57c>] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [<ffffffff818a331c>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [<ffffffff818a429f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [<ffffffff86e1a8c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
> RIP [<ffffffff834ca87b>] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
> RSP <ffff88003cbc7c28>
> ---[ end trace c6e1afa8cd73b880 ]---
>
>
> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
ping
Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
Hi
On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov <[email protected]> wrote:
> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov <[email protected]> wrote:
>> Hello,
>>
>> The following program triggers GPF in drm_getcap:
>>
>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>> #include <fcntl.h>
>> #include <stddef.h>
>> #include <stdint.h>
>> #include <sys/ioctl.h>
>> #include <sys/stat.h>
>> #include <sys/syscall.h>
>> #include <sys/types.h>
>> #include <unistd.h>
>>
>> int main()
>> {
>> int fd = open("/dev/dri/card0", O_RDONLY);
>> uint64_t data[2] = {0x11, 0x80};
>> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>> return 0;
>> }
>>
>>
>> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>> Modules linked in:
>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> task: ffff8800310dc540 task.stack: ffff88003cbc0000
>> RIP: 0010:[<ffffffff834ca87b>] [<ffffffff834ca87b>]
>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>> RSP: 0018:ffff88003cbc7c28 EFLAGS: 00010202
>> RAX: 0000000000000058 RBX: ffff88003cbc7cf8 RCX: ffffc90001db0000
>> RDX: 000000000000005d RSI: ffff88003cbc7cf8 RDI: 00000000000002c0
>> RBP: ffff88003cbc7c50 R08: ffffed0007978fa1 R09: ffffed0007978fa0
>> R10: ffff88003cbc7d07 R11: ffffed0007978fa1 R12: fffffffffffffff0
>> R13: dffffc0000000000 R14: ffff88003bcc6850 R15: fffffffffffffff2
>> FS: 00007fcbf4e03700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>> CR2: 00000000006dce00 CR3: 0000000066135000 CR4: 00000000000006e0
>> DR0: 000000000000001e DR1: 000000000000001e DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
>> Stack:
>> ffff88003c26db00 ffff88003cbc7cf8 ffffffff875a3000 ffffffff88cf0ee0
>> fffffffffffffff2 ffff88003cbc7dc0 ffffffff834cb57c 000000000000e200
>> 1ffff10000000001 ffffffff875a1ba0 ffffffff882ae930 0000000000000010
>> Call Trace:
>> [<ffffffff834cb57c>] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>> [< inline >] vfs_ioctl fs/ioctl.c:43
>> [<ffffffff818a331c>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>> [<ffffffff818a429f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>> [<ffffffff86e1a8c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>> RIP [<ffffffff834ca87b>] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>> RSP <ffff88003cbc7c28>
>> ---[ end trace c6e1afa8cd73b880 ]---
>>
>>
>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>
> ping
>
> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
I suspect this is because we run drm_for_each_crtc() in
drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
mode_config is not initialized). @danvet, how about always
initializing mode_config to 0/empty/dummy?
Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
Thanks
David
On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann <[email protected]> wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov <[email protected]> wrote:
>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov <[email protected]> wrote:
>>> Hello,
>>>
>>> The following program triggers GPF in drm_getcap:
>>>
>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>> #include <fcntl.h>
>>> #include <stddef.h>
>>> #include <stdint.h>
>>> #include <sys/ioctl.h>
>>> #include <sys/stat.h>
>>> #include <sys/syscall.h>
>>> #include <sys/types.h>
>>> #include <unistd.h>
>>>
>>> int main()
>>> {
>>> int fd = open("/dev/dri/card0", O_RDONLY);
>>> uint64_t data[2] = {0x11, 0x80};
>>> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>>> return 0;
>>> }
>>>
>>>
>>> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>>> Modules linked in:
>>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> task: ffff8800310dc540 task.stack: ffff88003cbc0000
>>> RIP: 0010:[<ffffffff834ca87b>] [<ffffffff834ca87b>]
>>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>> RSP: 0018:ffff88003cbc7c28 EFLAGS: 00010202
>>> RAX: 0000000000000058 RBX: ffff88003cbc7cf8 RCX: ffffc90001db0000
>>> RDX: 000000000000005d RSI: ffff88003cbc7cf8 RDI: 00000000000002c0
>>> RBP: ffff88003cbc7c50 R08: ffffed0007978fa1 R09: ffffed0007978fa0
>>> R10: ffff88003cbc7d07 R11: ffffed0007978fa1 R12: fffffffffffffff0
>>> R13: dffffc0000000000 R14: ffff88003bcc6850 R15: fffffffffffffff2
>>> FS: 00007fcbf4e03700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>> CR2: 00000000006dce00 CR3: 0000000066135000 CR4: 00000000000006e0
>>> DR0: 000000000000001e DR1: 000000000000001e DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
>>> Stack:
>>> ffff88003c26db00 ffff88003cbc7cf8 ffffffff875a3000 ffffffff88cf0ee0
>>> fffffffffffffff2 ffff88003cbc7dc0 ffffffff834cb57c 000000000000e200
>>> 1ffff10000000001 ffffffff875a1ba0 ffffffff882ae930 0000000000000010
>>> Call Trace:
>>> [<ffffffff834cb57c>] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>>> [< inline >] vfs_ioctl fs/ioctl.c:43
>>> [<ffffffff818a331c>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>>> [<ffffffff818a429f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>>> [<ffffffff86e1a8c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
>>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>>> RIP [<ffffffff834ca87b>] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>> RSP <ffff88003cbc7c28>
>>> ---[ end trace c6e1afa8cd73b880 ]---
>>>
>>>
>>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>>
>> ping
>>
>> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>
> I suspect this is because we run drm_for_each_crtc() in
> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
> mode_config is not initialized). @danvet, how about always
> initializing mode_config to 0/empty/dummy?
>
> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
CONFIG_DRM_LEGACY is enabled.
How can I understand what driver is used?
This happens inside of qemu. This is the device:
crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0
Hi
On Sat, Nov 26, 2016 at 6:50 PM, Dmitry Vyukov <[email protected]> wrote:
> On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann <[email protected]> wrote:
>> Hi
>>
>> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov <[email protected]> wrote:
>>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov <[email protected]> wrote:
>>>> Hello,
>>>>
>>>> The following program triggers GPF in drm_getcap:
>>>>
>>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>>> #include <fcntl.h>
>>>> #include <stddef.h>
>>>> #include <stdint.h>
>>>> #include <sys/ioctl.h>
>>>> #include <sys/stat.h>
>>>> #include <sys/syscall.h>
>>>> #include <sys/types.h>
>>>> #include <unistd.h>
>>>>
>>>> int main()
>>>> {
>>>> int fd = open("/dev/dri/card0", O_RDONLY);
>>>> uint64_t data[2] = {0x11, 0x80};
>>>> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>>>> return 0;
>>>> }
>>>>
>>>>
>>>> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>>>> Modules linked in:
>>>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>>> task: ffff8800310dc540 task.stack: ffff88003cbc0000
>>>> RIP: 0010:[<ffffffff834ca87b>] [<ffffffff834ca87b>]
>>>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>>> RSP: 0018:ffff88003cbc7c28 EFLAGS: 00010202
>>>> RAX: 0000000000000058 RBX: ffff88003cbc7cf8 RCX: ffffc90001db0000
>>>> RDX: 000000000000005d RSI: ffff88003cbc7cf8 RDI: 00000000000002c0
>>>> RBP: ffff88003cbc7c50 R08: ffffed0007978fa1 R09: ffffed0007978fa0
>>>> R10: ffff88003cbc7d07 R11: ffffed0007978fa1 R12: fffffffffffffff0
>>>> R13: dffffc0000000000 R14: ffff88003bcc6850 R15: fffffffffffffff2
>>>> FS: 00007fcbf4e03700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> CR2: 00000000006dce00 CR3: 0000000066135000 CR4: 00000000000006e0
>>>> DR0: 000000000000001e DR1: 000000000000001e DR2: 0000000000000000
>>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
>>>> Stack:
>>>> ffff88003c26db00 ffff88003cbc7cf8 ffffffff875a3000 ffffffff88cf0ee0
>>>> fffffffffffffff2 ffff88003cbc7dc0 ffffffff834cb57c 000000000000e200
>>>> 1ffff10000000001 ffffffff875a1ba0 ffffffff882ae930 0000000000000010
>>>> Call Trace:
>>>> [<ffffffff834cb57c>] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>>>> [< inline >] vfs_ioctl fs/ioctl.c:43
>>>> [<ffffffff818a331c>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>>>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>>>> [<ffffffff818a429f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>>>> [<ffffffff86e1a8c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
>>>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>>>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>>>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>>>> RIP [<ffffffff834ca87b>] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>>> RSP <ffff88003cbc7c28>
>>>> ---[ end trace c6e1afa8cd73b880 ]---
>>>>
>>>>
>>>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>>>
>>> ping
>>>
>>> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>>
>> I suspect this is because we run drm_for_each_crtc() in
>> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
>> mode_config is not initialized). @danvet, how about always
>> initializing mode_config to 0/empty/dummy?
>>
>> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
>
>
> CONFIG_DRM_LEGACY is enabled.
>
> How can I understand what driver is used?
> This happens inside of qemu. This is the device:
> crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0
Usually by looking into `dmesg` and grepping for 'card0', or by inspecting:
/sys/class/drm/card0/device/
or more importantly looking at the symlink:
/sys/class/drm/card0/device/driver
Thanks
David
grep "card0" dmesg:
[ 5.298617] device: 'card0': device_add
[ 5.298946] PM: Adding info for No Bus:card0
[ 6.436178] device: 'card0': device_add
[ 6.436488] PM: Adding info for No Bus:card0
# ls -l /dev/dri/card0
crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0
# ls -lt /sys/class/drm/card0/device/
ls: cannot access /sys/class/drm/card0/device/: No such file or directory
# ls -lt /sys/class/drm/card0/device/driver
ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory
On Sat, Nov 26, 2016 at 7:02 PM, David Herrmann <[email protected]> wrote:
> Hi
>
> On Sat, Nov 26, 2016 at 6:50 PM, Dmitry Vyukov <[email protected]> wrote:
>> On Sat, Nov 26, 2016 at 6:35 PM, David Herrmann <[email protected]> wrote:
>>> Hi
>>>
>>> On Sat, Nov 26, 2016 at 6:17 PM, Dmitry Vyukov <[email protected]> wrote:
>>>> On Fri, Sep 9, 2016 at 1:56 PM, Dmitry Vyukov <[email protected]> wrote:
>>>>> Hello,
>>>>>
>>>>> The following program triggers GPF in drm_getcap:
>>>>>
>>>>> // autogenerated by syzkaller (http://github.com/google/syzkaller)
>>>>> #include <fcntl.h>
>>>>> #include <stddef.h>
>>>>> #include <stdint.h>
>>>>> #include <sys/ioctl.h>
>>>>> #include <sys/stat.h>
>>>>> #include <sys/syscall.h>
>>>>> #include <sys/types.h>
>>>>> #include <unistd.h>
>>>>>
>>>>> int main()
>>>>> {
>>>>> int fd = open("/dev/dri/card0", O_RDONLY);
>>>>> uint64_t data[2] = {0x11, 0x80};
>>>>> ioctl(fd, 0xc010640cul /*DRM_IOCTL_GET_CAP*/, data);
>>>>> return 0;
>>>>> }
>>>>>
>>>>>
>>>>> general protection fault: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN
>>>>> Modules linked in:
>>>>> CPU: 1 PID: 5745 Comm: syz-executor Not tainted 4.8.0-rc5-next-20160905+ #14
>>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>>>> task: ffff8800310dc540 task.stack: ffff88003cbc0000
>>>>> RIP: 0010:[<ffffffff834ca87b>] [<ffffffff834ca87b>]
>>>>> drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>>>> RSP: 0018:ffff88003cbc7c28 EFLAGS: 00010202
>>>>> RAX: 0000000000000058 RBX: ffff88003cbc7cf8 RCX: ffffc90001db0000
>>>>> RDX: 000000000000005d RSI: ffff88003cbc7cf8 RDI: 00000000000002c0
>>>>> RBP: ffff88003cbc7c50 R08: ffffed0007978fa1 R09: ffffed0007978fa0
>>>>> R10: ffff88003cbc7d07 R11: ffffed0007978fa1 R12: fffffffffffffff0
>>>>> R13: dffffc0000000000 R14: ffff88003bcc6850 R15: fffffffffffffff2
>>>>> FS: 00007fcbf4e03700(0000) GS:ffff88003ed00000(0000) knlGS:0000000000000000
>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>>> CR2: 00000000006dce00 CR3: 0000000066135000 CR4: 00000000000006e0
>>>>> DR0: 000000000000001e DR1: 000000000000001e DR2: 0000000000000000
>>>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
>>>>> Stack:
>>>>> ffff88003c26db00 ffff88003cbc7cf8 ffffffff875a3000 ffffffff88cf0ee0
>>>>> fffffffffffffff2 ffff88003cbc7dc0 ffffffff834cb57c 000000000000e200
>>>>> 1ffff10000000001 ffffffff875a1ba0 ffffffff882ae930 0000000000000010
>>>>> Call Trace:
>>>>> [<ffffffff834cb57c>] drm_ioctl+0x54c/0xaf0 drivers/gpu/drm/drm_ioctl.c:728
>>>>> [< inline >] vfs_ioctl fs/ioctl.c:43
>>>>> [<ffffffff818a331c>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
>>>>> [< inline >] SYSC_ioctl fs/ioctl.c:690
>>>>> [<ffffffff818a429f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
>>>>> [<ffffffff86e1a8c0>] entry_SYSCALL_64_fastpath+0x23/0xc1
>>>>> Code: 3c 28 00 0f 85 88 01 00 00 49 8b 44 24 10 49 39 c6 4c 8d 60 f0
>>>>> 74 82 e8 64 19 10 fe 49 8d bc 24 d0 02 00 00 48 89 f8 48 c1 e8 03 <42>
>>>>> 80 3c 28 00 0f 85 6f 01 00 00 4d 8b bc 24 d0 02 00 00 49 8d
>>>>> RIP [<ffffffff834ca87b>] drm_getcap+0x34b/0x4f0 drivers/gpu/drm/drm_ioctl.c:260
>>>>> RSP <ffff88003cbc7c28>
>>>>> ---[ end trace c6e1afa8cd73b880 ]---
>>>>>
>>>>>
>>>>> On commit 4affa544adb8077403893e62b9e327fcf87de6f7 (Sep 8) of linux-next.
>>>>
>>>> ping
>>>>
>>>> Still happens on 16ae16c6e5616c084168740990fc508bda6655d4 (Nov 24).
>>>
>>> I suspect this is because we run drm_for_each_crtc() in
>>> drm_getcap(DRM_PAGE_FLIP_TARGET) on a legacy driver (meaning
>>> mode_config is not initialized). @danvet, how about always
>>> initializing mode_config to 0/empty/dummy?
>>>
>>> Dmitry, what driver do you run this on? And is CONFIG_DRM_LEGACY enabled?
>>
>>
>> CONFIG_DRM_LEGACY is enabled.
>>
>> How can I understand what driver is used?
>> This happens inside of qemu. This is the device:
>> crw-rw---T 1 root video 226, 0 Nov 26 17:45 /dev/dri/card0
>
> Usually by looking into `dmesg` and grepping for 'card0', or by inspecting:
>
> /sys/class/drm/card0/device/
>
> or more importantly looking at the symlink:
>
> /sys/class/drm/card0/device/driver
>
> Thanks
> David
Hi
On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov <[email protected]> wrote:
> grep "card0" dmesg:
> [ 5.298617] device: 'card0': device_add
> [ 5.298946] PM: Adding info for No Bus:card0
> [ 6.436178] device: 'card0': device_add
> [ 6.436488] PM: Adding info for No Bus:card0
>
>
> # ls -l /dev/dri/card0
> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0
>
> # ls -lt /sys/class/drm/card0/device/
> ls: cannot access /sys/class/drm/card0/device/: No such file or directory
>
> # ls -lt /sys/class/drm/card0/device/driver
> ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory
Looks like vgem. Something like this should help:
https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2
I wonder whether it would be more appropriate to return -ENOTSUPP rather than 0.
Thanks
David
On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann <[email protected]> wrote:
> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov <[email protected]> wrote:
>> grep "card0" dmesg:
>> [ 5.298617] device: 'card0': device_add
>> [ 5.298946] PM: Adding info for No Bus:card0
>> [ 6.436178] device: 'card0': device_add
>> [ 6.436488] PM: Adding info for No Bus:card0
>>
>>
>> # ls -l /dev/dri/card0
>> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0
>>
>> # ls -lt /sys/class/drm/card0/device/
>> ls: cannot access /sys/class/drm/card0/device/: No such file or directory
>>
>> # ls -lt /sys/class/drm/card0/device/driver
>> ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory
>
> Looks like vgem. Something like this should help:
>
> https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2
>
> I wonder whether it would be more appropriate to return -ENOTSUPP rather than 0.
Seems a bit overkill, but can't hurt. This is most likely a
regression, probably introduced in
commit f837297ad82480024d3ad08cd84f6670bcafa862
Author: Michel Dänzer <[email protected]>
Date: Mon Aug 8 16:23:39 2016 +0900
drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2
Michel, can you pls take care of this? Either with a minimal fix, or
by adopting David's patch?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
On 28/11/16 03:55 PM, Daniel Vetter wrote:
> On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann <[email protected]> wrote:
>> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov <[email protected]> wrote:
>>> grep "card0" dmesg:
>>> [ 5.298617] device: 'card0': device_add
>>> [ 5.298946] PM: Adding info for No Bus:card0
>>> [ 6.436178] device: 'card0': device_add
>>> [ 6.436488] PM: Adding info for No Bus:card0
>>>
>>>
>>> # ls -l /dev/dri/card0
>>> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0
>>>
>>> # ls -lt /sys/class/drm/card0/device/
>>> ls: cannot access /sys/class/drm/card0/device/: No such file or directory
>>>
>>> # ls -lt /sys/class/drm/card0/device/driver
>>> ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory
>>
>> Looks like vgem. Something like this should help:
>>
>> https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2
>>
>> I wonder whether it would be more appropriate to return -ENOTSUPP rather than 0.
Can't see how that would matter FWIW.
> Seems a bit overkill, but can't hurt. This is most likely a
> regression, probably introduced in
>
> commit f837297ad82480024d3ad08cd84f6670bcafa862
> Author: Michel Dänzer <[email protected]>
> Date: Mon Aug 8 16:23:39 2016 +0900
>
> drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2
>
> Michel, can you pls take care of this? Either with a minimal fix, or
> by adopting David's patch?
Can't we just use David's patch as-is? If not, I think Dmitry or someone
else would be better equipped than me to extract a minimal fix from it
and test it.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
On Mon, Nov 28, 2016 at 8:14 AM, Michel Dänzer <[email protected]> wrote:
> On 28/11/16 03:55 PM, Daniel Vetter wrote:
>> On Sat, Nov 26, 2016 at 7:22 PM, David Herrmann <[email protected]> wrote:
>>> On Sat, Nov 26, 2016 at 7:07 PM, Dmitry Vyukov <[email protected]> wrote:
>>>> grep "card0" dmesg:
>>>> [ 5.298617] device: 'card0': device_add
>>>> [ 5.298946] PM: Adding info for No Bus:card0
>>>> [ 6.436178] device: 'card0': device_add
>>>> [ 6.436488] PM: Adding info for No Bus:card0
>>>>
>>>>
>>>> # ls -l /dev/dri/card0
>>>> crw-rw---T 1 root video 226, 0 Nov 26 18:05 /dev/dri/card0
>>>>
>>>> # ls -lt /sys/class/drm/card0/device/
>>>> ls: cannot access /sys/class/drm/card0/device/: No such file or directory
>>>>
>>>> # ls -lt /sys/class/drm/card0/device/driver
>>>> ls: cannot access /sys/class/drm/card0/device/driver: No such file or directory
>>>
>>> Looks like vgem. Something like this should help:
>>>
>>> https://gist.github.com/dvdhrm/1bcdf4f3485aa1614a0198a7b90515e2
>>>
>>> I wonder whether it would be more appropriate to return -ENOTSUPP rather than 0.
>
> Can't see how that would matter FWIW.
>
>
>> Seems a bit overkill, but can't hurt. This is most likely a
>> regression, probably introduced in
>>
>> commit f837297ad82480024d3ad08cd84f6670bcafa862
>> Author: Michel Dänzer <[email protected]>
>> Date: Mon Aug 8 16:23:39 2016 +0900
>>
>> drm: Add DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE/RELATIVE flags v2
>>
>> Michel, can you pls take care of this? Either with a minimal fix, or
>> by adopting David's patch?
>
> Can't we just use David's patch as-is? If not, I think Dmitry or someone
> else would be better equipped than me to extract a minimal fix from it
> and test it.
I know nothing about DRM code. Reproducer is attached to the first email.