* Re: [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 [not found] ` <01c7bc6b-dc6d-5eca-401a-8869e02f7c2a@molgen.mpg.de> @ 2019-08-10 21:11 ` Paul Menzel 2019-08-11 6:22 ` Thomas Gleixner 0 siblings, 1 reply; 7+ messages in thread From: Paul Menzel @ 2019-08-10 21:11 UTC (permalink / raw) To: Thomas Gleixner, Jacob Pan, Len Brown; +Cc: x86, LKML, linux-pm [+ INTEL IDLE DRIVER] Dear Linux folks, On 10.08.19 20:28, Paul Menzel wrote: > On 10.08.19 19:31, Thomas Gleixner wrote: > >> On Sat, 10 Aug 2019, Paul Menzel wrote: >>> >>> I have no idea, who to report this to, so I please refer me to the >>> correct >>> list. >> >> I have no idea yet either :) >> >>> With Linux 5.2.7 from Debian Sid/unstable and PowerTOP 2.10, executing >>> >>> sudo powertop --auto-tune >>> >>> causes a NULL pointer dereference, and the graphical session crashes >>> due to an >>> effect on the i915 driver. It worked in the past with the 4.19 series >>> from >>> Debian. >>> >>> Here is the trace, and please find all Linux kernel logs attached. >>> >>>> [ 2027.170589] BUG: kernel NULL pointer dereference, address: >>>> 0000000000000000 >>>> [ 2027.170600] #PF: supervisor instruction fetch in kernel mode >>>> [ 2027.170604] #PF: error_code(0x0010) - not-present page >>>> [ 2027.170609] PGD 0 P4D 0 [ 2027.170619] Oops: 0010 [#1] SMP PTI >> ... >>>> [ 2027.170730] do_dentry_open+0x13a/0x370 >> >> If you have compiled with debug info, please decode the line: >> >> linux/scripts/faddr2line vmlinux do_dentry_open+0x13a/0x370 >> >> That gives us the fops pointer which is NULL. > > Hah, luckily it’s reproducible. > > ``` > $ scripts/faddr2line /usr/lib/debug/boot/vmlinux-5.2.0-2-amd64 > do_dentry_open+0x13a/0x370 > do_dentry_open+0x13a/0x370: > do_dentry_open at fs/open.c:799 > ``` > >>>> [ 2027.170745] path_openat+0x2c6/0x1480 >>>> [ 2027.170757] ? terminate_walk+0xe6/0x100 >>>> [ 2027.170767] ? path_lookupat.isra.48+0xa3/0x220 >>>> [ 2027.170779] ? reuse_swap_page+0x105/0x320 >>>> [ 2027.170791] do_filp_open+0x93/0x100 >>>> [ 2027.170804] ? __check_object_size+0x15d/0x189 >>>> [ 2027.170816] do_sys_open+0x184/0x220 >>>> [ 2027.170828] do_syscall_64+0x53/0x130 >>>> [ 2027.170837] entry_SYSCALL_64_after_hwframe+0x44/0xa9 >> >> That's an open crashing. We just don't know which file. Is the machine >> completely hosed after that or is it just the graphics stuff dying? > > No, the graphical login manager showed up, and I could log back in, and > continue using hte machine. > >> If it's not completely dead then instead of running it from your >> graphical >> desktop you could switch to a VGA terminal Alt+Ctrl+F1 (or whatever >> function key your distro maps to) after boot and run powertop with strace >> from there: >> >> strace -f -o xxx.log powertop >> >> With a bit of luck xxx.log should contain the information about the >> file it >> tries to open. > > ``` > 2157 access("/sys/class/drm/card0/power/rc6_residency_ms", R_OK) = 0 > 2157 openat(AT_FDCWD, > "/sys/kernel/debug/tracing/events/power/cpu_idle/id", O_RDONLY) = ? > 2157 +++ killed by SIGKILL +++ > ``` > >> Alternatively if you have a serial console you can enable the >> sys_enter_open* tracepoints: >> >> # echo 1 >/sys/kernel/debug/tracing/events/syscalls/sys_enter_open >> # echo 1 >/sys/kernel/debug/tracing/events/syscalls/sys_enter_openat >> >> Either add 'ftrace_dump_on_oops' to the kernel command line or enable it >> from the shell: >> >> # echo 1 > /proc/sys/kernel/ftrace_dump_on_oops >> >> Then run powertop. After the crash it will take some time to spill out >> the trace buffer over serial, but it will pinpoint the offending file. > > I do not have serial console on this device. For the record. It is also reproducible with Linux 5.2.6, and trying to print the file contents with cat already fails. ``` $ sudo ls -l /sys/kernel/debug/tracing/events/power/cpu_idle/id -r--r--r-- 1 root root 0 Aug 10 23:05 /sys/kernel/debug/tracing/events/power/cpu_idle/id $ sudo cat /sys/kernel/debug/tracing/events/power/cpu_idle/id Killed ``` Kind regards, Paul ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 2019-08-10 21:11 ` [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 Paul Menzel @ 2019-08-11 6:22 ` Thomas Gleixner 2019-08-11 9:46 ` Salvatore Bonaccorso 0 siblings, 1 reply; 7+ messages in thread From: Thomas Gleixner @ 2019-08-11 6:22 UTC (permalink / raw) To: Paul Menzel; +Cc: Jacob Pan, Len Brown, x86, LKML, linux-pm, Steven Rostedt [-- Attachment #1: Type: text/plain, Size: 4162 bytes --] On Sat, 10 Aug 2019, Paul Menzel wrote: Cc+ Steven > [+ INTEL IDLE DRIVER] > > Dear Linux folks, > > > On 10.08.19 20:28, Paul Menzel wrote: > > > On 10.08.19 19:31, Thomas Gleixner wrote: > > > > > On Sat, 10 Aug 2019, Paul Menzel wrote: > > > > > > > > I have no idea, who to report this to, so I please refer me to the > > > > correct > > > > list. > > > > > > I have no idea yet either :) > > > > > > > With Linux 5.2.7 from Debian Sid/unstable and PowerTOP 2.10, executing > > > > > > > > sudo powertop --auto-tune > > > > > > > > causes a NULL pointer dereference, and the graphical session crashes due > > > > to an > > > > effect on the i915 driver. It worked in the past with the 4.19 series > > > > from > > > > Debian. > > > > > > > > Here is the trace, and please find all Linux kernel logs attached. > > > > > > > > > [ 2027.170589] BUG: kernel NULL pointer dereference, address: > > > > > 0000000000000000 > > > > > [ 2027.170600] #PF: supervisor instruction fetch in kernel mode > > > > > [ 2027.170604] #PF: error_code(0x0010) - not-present page > > > > > [ 2027.170609] PGD 0 P4D 0 [ 2027.170619] Oops: 0010 [#1] SMP PTI > > > ... > > > > > [ 2027.170730] do_dentry_open+0x13a/0x370 > > > > > > If you have compiled with debug info, please decode the line: > > > > > > linux/scripts/faddr2line vmlinux do_dentry_open+0x13a/0x370 > > > > > > That gives us the fops pointer which is NULL. > > > > Hah, luckily it’s reproducible. > > > > ``` > > $ scripts/faddr2line /usr/lib/debug/boot/vmlinux-5.2.0-2-amd64 > > do_dentry_open+0x13a/0x370 > > do_dentry_open+0x13a/0x370: > > do_dentry_open at fs/open.c:799 > > ``` > > > > > > > [ 2027.170745] path_openat+0x2c6/0x1480 > > > > > [ 2027.170757] ? terminate_walk+0xe6/0x100 > > > > > [ 2027.170767] ? path_lookupat.isra.48+0xa3/0x220 > > > > > [ 2027.170779] ? reuse_swap_page+0x105/0x320 > > > > > [ 2027.170791] do_filp_open+0x93/0x100 > > > > > [ 2027.170804] ? __check_object_size+0x15d/0x189 > > > > > [ 2027.170816] do_sys_open+0x184/0x220 > > > > > [ 2027.170828] do_syscall_64+0x53/0x130 > > > > > [ 2027.170837] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > That's an open crashing. We just don't know which file. Is the machine > > > completely hosed after that or is it just the graphics stuff dying? > > > > No, the graphical login manager showed up, and I could log back in, and > > continue using hte machine. > > > > > If it's not completely dead then instead of running it from your graphical > > > desktop you could switch to a VGA terminal Alt+Ctrl+F1 (or whatever > > > function key your distro maps to) after boot and run powertop with strace > > > from there: > > > > > > strace -f -o xxx.log powertop > > > > > > With a bit of luck xxx.log should contain the information about the file > > > it > > > tries to open. > > > > ``` > > 2157 access("/sys/class/drm/card0/power/rc6_residency_ms", R_OK) = 0 > > 2157 openat(AT_FDCWD, "/sys/kernel/debug/tracing/events/power/cpu_idle/id", > > O_RDONLY) = ? > > 2157 +++ killed by SIGKILL +++ > > ``` > > > > > Alternatively if you have a serial console you can enable the > > > sys_enter_open* tracepoints: > > > > > > # echo 1 >/sys/kernel/debug/tracing/events/syscalls/sys_enter_open > > > # echo 1 >/sys/kernel/debug/tracing/events/syscalls/sys_enter_openat > > > > > > Either add 'ftrace_dump_on_oops' to the kernel command line or enable it > > > from the shell: > > > > > > # echo 1 > /proc/sys/kernel/ftrace_dump_on_oops > > > > > > Then run powertop. After the crash it will take some time to spill out the > > > trace buffer over serial, but it will pinpoint the offending file. > > > > I do not have serial console on this device. > > For the record. It is also reproducible with Linux 5.2.6, and trying to print > the file contents with cat already fails. > > ``` > $ sudo ls -l /sys/kernel/debug/tracing/events/power/cpu_idle/id > -r--r--r-- 1 root root 0 Aug 10 23:05 > /sys/kernel/debug/tracing/events/power/cpu_idle/id > $ sudo cat /sys/kernel/debug/tracing/events/power/cpu_idle/id > Killed > ``` > > > Kind regards, > > Paul > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 2019-08-11 6:22 ` Thomas Gleixner @ 2019-08-11 9:46 ` Salvatore Bonaccorso 2019-08-11 12:58 ` Thomas Gleixner 0 siblings, 1 reply; 7+ messages in thread From: Salvatore Bonaccorso @ 2019-08-11 9:46 UTC (permalink / raw) To: Thomas Gleixner Cc: Paul Menzel, Jacob Pan, Len Brown, x86, LKML, linux-pm, Steven Rostedt, Matthew Garrett hi, On Sun, Aug 11, 2019 at 08:22:35AM +0200, Thomas Gleixner wrote: > On Sat, 10 Aug 2019, Paul Menzel wrote: > > Cc+ Steven > > > [+ INTEL IDLE DRIVER] > > > > Dear Linux folks, > > > > > > On 10.08.19 20:28, Paul Menzel wrote: > > > > > On 10.08.19 19:31, Thomas Gleixner wrote: > > > > > > > On Sat, 10 Aug 2019, Paul Menzel wrote: > > > > > > > > > > I have no idea, who to report this to, so I please refer me to the > > > > > correct > > > > > list. > > > > > > > > I have no idea yet either :) > > > > > > > > > With Linux 5.2.7 from Debian Sid/unstable and PowerTOP 2.10, executing > > > > > > > > > > sudo powertop --auto-tune > > > > > > > > > > causes a NULL pointer dereference, and the graphical session crashes due > > > > > to an > > > > > effect on the i915 driver. It worked in the past with the 4.19 series > > > > > from > > > > > Debian. > > > > > > > > > > Here is the trace, and please find all Linux kernel logs attached. > > > > > > > > > > > [ 2027.170589] BUG: kernel NULL pointer dereference, address: > > > > > > 0000000000000000 > > > > > > [ 2027.170600] #PF: supervisor instruction fetch in kernel mode > > > > > > [ 2027.170604] #PF: error_code(0x0010) - not-present page > > > > > > [ 2027.170609] PGD 0 P4D 0 [ 2027.170619] Oops: 0010 [#1] SMP PTI > > > > ... > > > > > > [ 2027.170730] do_dentry_open+0x13a/0x370 > > > > > > > > If you have compiled with debug info, please decode the line: > > > > > > > > linux/scripts/faddr2line vmlinux do_dentry_open+0x13a/0x370 > > > > > > > > That gives us the fops pointer which is NULL. > > > > > > Hah, luckily it’s reproducible. > > > > > > ``` > > > $ scripts/faddr2line /usr/lib/debug/boot/vmlinux-5.2.0-2-amd64 > > > do_dentry_open+0x13a/0x370 > > > do_dentry_open+0x13a/0x370: > > > do_dentry_open at fs/open.c:799 > > > ``` > > > > > > > > > [ 2027.170745] path_openat+0x2c6/0x1480 > > > > > > [ 2027.170757] ? terminate_walk+0xe6/0x100 > > > > > > [ 2027.170767] ? path_lookupat.isra.48+0xa3/0x220 > > > > > > [ 2027.170779] ? reuse_swap_page+0x105/0x320 > > > > > > [ 2027.170791] do_filp_open+0x93/0x100 > > > > > > [ 2027.170804] ? __check_object_size+0x15d/0x189 > > > > > > [ 2027.170816] do_sys_open+0x184/0x220 > > > > > > [ 2027.170828] do_syscall_64+0x53/0x130 > > > > > > [ 2027.170837] entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > > > That's an open crashing. We just don't know which file. Is the machine > > > > completely hosed after that or is it just the graphics stuff dying? > > > > > > No, the graphical login manager showed up, and I could log back in, and > > > continue using hte machine. > > > > > > > If it's not completely dead then instead of running it from your graphical > > > > desktop you could switch to a VGA terminal Alt+Ctrl+F1 (or whatever > > > > function key your distro maps to) after boot and run powertop with strace > > > > from there: > > > > > > > > strace -f -o xxx.log powertop > > > > > > > > With a bit of luck xxx.log should contain the information about the file > > > > it > > > > tries to open. > > > > > > ``` > > > 2157 access("/sys/class/drm/card0/power/rc6_residency_ms", R_OK) = 0 > > > 2157 openat(AT_FDCWD, "/sys/kernel/debug/tracing/events/power/cpu_idle/id", > > > O_RDONLY) = ? > > > 2157 +++ killed by SIGKILL +++ > > > ``` > > > > > > > Alternatively if you have a serial console you can enable the > > > > sys_enter_open* tracepoints: > > > > > > > > # echo 1 >/sys/kernel/debug/tracing/events/syscalls/sys_enter_open > > > > # echo 1 >/sys/kernel/debug/tracing/events/syscalls/sys_enter_openat > > > > > > > > Either add 'ftrace_dump_on_oops' to the kernel command line or enable it > > > > from the shell: > > > > > > > > # echo 1 > /proc/sys/kernel/ftrace_dump_on_oops > > > > > > > > Then run powertop. After the crash it will take some time to spill out the > > > > trace buffer over serial, but it will pinpoint the offending file. > > > > > > I do not have serial console on this device. > > > > For the record. It is also reproducible with Linux 5.2.6, and trying to print > > the file contents with cat already fails. > > > > ``` > > $ sudo ls -l /sys/kernel/debug/tracing/events/power/cpu_idle/id > > -r--r--r-- 1 root root 0 Aug 10 23:05 > > /sys/kernel/debug/tracing/events/power/cpu_idle/id > > $ sudo cat /sys/kernel/debug/tracing/events/power/cpu_idle/id > > Killed > > ``` This seems to be related to https://bugs.debian.org/934304 (in particular https://bugs.debian.org/934304#29). The mentioned patch features/all/lockdown/0031-tracefs-Restrict-tracefs-when-the-kernel-is-locked-d.patch is a backport of https://patchwork.kernel.org/patch/11069661/ with only change that it is converted back to the non-LSM lockdown API. Regards, Salvatore ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 2019-08-11 9:46 ` Salvatore Bonaccorso @ 2019-08-11 12:58 ` Thomas Gleixner 2019-08-11 15:33 ` Salvatore Bonaccorso 0 siblings, 1 reply; 7+ messages in thread From: Thomas Gleixner @ 2019-08-11 12:58 UTC (permalink / raw) To: Salvatore Bonaccorso Cc: Paul Menzel, Jacob Pan, Len Brown, x86, LKML, linux-pm, Steven Rostedt, Matthew Garrett Salvatore, On Sun, 11 Aug 2019, Salvatore Bonaccorso wrote: > On Sun, Aug 11, 2019 at 08:22:35AM +0200, Thomas Gleixner wrote: > > On Sat, 10 Aug 2019, Paul Menzel wrote: > > > For the record. It is also reproducible with Linux 5.2.6, and trying to print > > > the file contents with cat already fails. > > > > > > ``` > > > $ sudo ls -l /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > -r--r--r-- 1 root root 0 Aug 10 23:05 > > > /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > $ sudo cat /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > Killed > > > ``` > > This seems to be related to https://bugs.debian.org/934304 (in > particular https://bugs.debian.org/934304#29). The mentioned patch > features/all/lockdown/0031-tracefs-Restrict-tracefs-when-the-kernel-is-locked-d.patch > is a backport of https://patchwork.kernel.org/patch/11069661/ with > only change that it is converted back to the non-LSM lockdown API. So that's a debian kernel specific issue? Thanks, tglx ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 2019-08-11 12:58 ` Thomas Gleixner @ 2019-08-11 15:33 ` Salvatore Bonaccorso 2019-08-12 15:28 ` Steven Rostedt 0 siblings, 1 reply; 7+ messages in thread From: Salvatore Bonaccorso @ 2019-08-11 15:33 UTC (permalink / raw) To: Thomas Gleixner Cc: Paul Menzel, Jacob Pan, Len Brown, x86, LKML, linux-pm, Steven Rostedt, Matthew Garrett Thomas, On Sun, Aug 11, 2019 at 02:58:15PM +0200, Thomas Gleixner wrote: > Salvatore, > > On Sun, 11 Aug 2019, Salvatore Bonaccorso wrote: > > On Sun, Aug 11, 2019 at 08:22:35AM +0200, Thomas Gleixner wrote: > > > On Sat, 10 Aug 2019, Paul Menzel wrote: > > > > For the record. It is also reproducible with Linux 5.2.6, and trying to print > > > > the file contents with cat already fails. > > > > > > > > ``` > > > > $ sudo ls -l /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > > -r--r--r-- 1 root root 0 Aug 10 23:05 > > > > /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > > $ sudo cat /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > > Killed > > > > ``` > > > > This seems to be related to https://bugs.debian.org/934304 (in > > particular https://bugs.debian.org/934304#29). The mentioned patch > > features/all/lockdown/0031-tracefs-Restrict-tracefs-when-the-kernel-is-locked-d.patch > > is a backport of https://patchwork.kernel.org/patch/11069661/ with > > only change that it is converted back to the non-LSM lockdown API. > > So that's a debian kernel specific issue? "yes". A kernel build without the above patch does not exhibit the issue. So the issue is specific to that lockdown patch ("tracefs: Restrict tracefs when the kernel is locked down"). Steven and Matthew are both CC'ed. Regards, Salvatore ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 2019-08-11 15:33 ` Salvatore Bonaccorso @ 2019-08-12 15:28 ` Steven Rostedt 2019-08-12 16:24 ` Matthew Garrett 0 siblings, 1 reply; 7+ messages in thread From: Steven Rostedt @ 2019-08-12 15:28 UTC (permalink / raw) To: Salvatore Bonaccorso Cc: Thomas Gleixner, Paul Menzel, Jacob Pan, Len Brown, x86, LKML, linux-pm, Matthew Garrett On Sun, 11 Aug 2019 17:33:26 +0200 Salvatore Bonaccorso <carnil@debian.org> wrote: > Thomas, > > On Sun, Aug 11, 2019 at 02:58:15PM +0200, Thomas Gleixner wrote: > > Salvatore, > > > > On Sun, 11 Aug 2019, Salvatore Bonaccorso wrote: > > > On Sun, Aug 11, 2019 at 08:22:35AM +0200, Thomas Gleixner wrote: > > > > On Sat, 10 Aug 2019, Paul Menzel wrote: > > > > > For the record. It is also reproducible with Linux 5.2.6, and trying to print > > > > > the file contents with cat already fails. > > > > > > > > > > ``` > > > > > $ sudo ls -l /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > > > -r--r--r-- 1 root root 0 Aug 10 23:05 > > > > > /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > > > $ sudo cat /sys/kernel/debug/tracing/events/power/cpu_idle/id > > > > > Killed > > > > > ``` > > > > > > This seems to be related to https://bugs.debian.org/934304 (in > > > particular https://bugs.debian.org/934304#29). The mentioned patch > > > features/all/lockdown/0031-tracefs-Restrict-tracefs-when-the-kernel-is-locked-d.patch > > > is a backport of https://patchwork.kernel.org/patch/11069661/ with > > > only change that it is converted back to the non-LSM lockdown API. > > > > So that's a debian kernel specific issue? > > "yes". A kernel build without the above patch does not exhibit the > issue. So the issue is specific to that lockdown patch ("tracefs: > Restrict tracefs when the kernel is locked down"). > > Steven and Matthew are both CC'ed. From what I understand, Matthew's "lockdown" work is to prevent the system from doing anything to see what is happening in the kernel. This includes tracefs. This looks like it is working as designed. Perhaps it's something in debian setup that needs to keep tracefs from being selected as "lockdown", otherwise anything that tries to access it, will have these issues. -- Steve ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 2019-08-12 15:28 ` Steven Rostedt @ 2019-08-12 16:24 ` Matthew Garrett 0 siblings, 0 replies; 7+ messages in thread From: Matthew Garrett @ 2019-08-12 16:24 UTC (permalink / raw) To: Steven Rostedt Cc: Salvatore Bonaccorso, Thomas Gleixner, Paul Menzel, Jacob Pan, Len Brown, x86, LKML, linux-pm On Mon, Aug 12, 2019 at 8:29 AM Steven Rostedt <rostedt@goodmis.org> wrote: > From what I understand, Matthew's "lockdown" work is to prevent the > system from doing anything to see what is happening in the kernel. This > includes tracefs. This looks like it is working as designed. Oopsing the kernel isn't working as designed. Ben has a patch to fix this. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-08-12 16:24 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <4b54ff1e-f18b-3c58-7caa-945a0775c24c@molgen.mpg.de>
[not found] ` <alpine.DEB.2.21.1908101910280.7324@nanos.tec.linutronix.de>
[not found] ` <01c7bc6b-dc6d-5eca-401a-8869e02f7c2a@molgen.mpg.de>
2019-08-10 21:11 ` [Linux 5.2.x] /sys/kernel/debug/tracing/events/power/cpu_idle/id: BUG: kernel NULL pointer dereference, address: 0000000000000000 Paul Menzel
2019-08-11 6:22 ` Thomas Gleixner
2019-08-11 9:46 ` Salvatore Bonaccorso
2019-08-11 12:58 ` Thomas Gleixner
2019-08-11 15:33 ` Salvatore Bonaccorso
2019-08-12 15:28 ` Steven Rostedt
2019-08-12 16:24 ` Matthew Garrett
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).