From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
Before the fixup: $echo BUG > /sys/kernel/debug/provoke-crash/DIRECT lkdtm: Performing direct entry BUG ------------[ cut here ]------------ kernel BUG at drivers/misc/lkdtm/bugs.c:78! handle_break, 256. Kernel BUG [#1] Modules linked in: CPU: 0 PID: 104 Comm: echo Not tainted 6.4.0-rc1-00055-g0ca05a4b079f-dirty #30 Hardware name: riscv-virtio,qemu (DT) epc : lkdtm_BUG+0x6/0x8 ra : lkdtm_do_action+0x14/0x1c epc : ffffffff8055c730 ra : ffffffff8087e188 sp : ff200000007dbd40 gp : ffffffff81500878 tp : ff600000028ebac0 t0 : 6500000000000000 t1 : 000000000000006c t2 : 6550203a6d74646b s0 : ff200000007dbd50 s1 : ffffffff814bfc80 a0 : ffffffff814bfc80 a1 : ff6000001ffd8608 a2 : ff6000001ffdb870 a3 : 0000000000000000 a4 : 0000000000000000 a5 : ffffffff8055c72a a6 : 0000000000000032 a7 : 0000000000000038 s2 : 0000000000000004 s3 : 00000000556371a0 s4 : ff200000007dbe70 s5 : ff60000002090000 s6 : 00000000556371a0 s7 : 0000000000000030 s8 : 000000007fffec78 s9 : 0000000000000007 s10: 0000000055637530 s11: 0000000000000001 t3 : ffffffff81513ed7 t4 : ffffffff81513ed7 t5 : ffffffff81513ed8 t6 : ff200000007dbb88 status: 0000000100000120 badaddr: 0000000000000000 cause: 0000000000000003 [<ffffffff8055c730>] lkdtm_BUG+0x6/0x8 Code: 0513 6b05 b097 0031 80e7 e960 b705 1141 e422 0800 (9002) 1141 ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Aiee, killing interrupt handler! ---[ end Kernel panic - not syncing: Aiee, killing interrupt handler! ]---
(Dead in the kernel side.)
After the fixup: $echo BUG > /sys/kernel/debug/provoke-crash/DIRECT lkdtm: Performing direct entry BUG ------------[ cut here ]------------ kernel BUG at drivers/misc/lkdtm/bugs.c:78! Kernel BUG [#13] Modules linked in: CPU: 0 PID: 129 Comm: echo Tainted: G D 6.4.0-rc1-00055-g0ca05a4b079f-dirty #34 Hardware name: riscv-virtio,qemu (DT) epc : lkdtm_BUG+0x6/0x8 ra : lkdtm_do_action+0x14/0x1c epc : ffffffff8055c71c ra : ffffffff8087e170 sp : ff200000007e3d40 gp : ffffffff81500878 tp : ff600000028ebac0 t0 : 6500000000000000 t1 : 000000000000006c t2 : 6550203a6d74646b s0 : ff200000007e3d50 s1 : ffffffff814bfc80 a0 : ffffffff814bfc80 a1 : ff6000001ffd8608 a2 : ff6000001ffdb870 a3 : 0000000000000000 a4 : 0000000000000000 a5 : ffffffff8055c716 a6 : 0000000000000032 a7 : 0000000000000038 s2 : 0000000000000004 s3 : 00000000556371a0 s4 : ff200000007e3e70 s5 : ff60000002090000 s6 : 00000000556371a0 s7 : 0000000000000030 s8 : 000000007fffec78 s9 : 0000000000000007 s10: 0000000055637530 s11: 0000000000000001 t3 : ffffffff81513ed7 t4 : ffffffff81513ed7 t5 : ffffffff81513ed8 t6 : ff200000007e3b88 status: 0000000100000120 badaddr: 0000000000000000 cause: 0000000000000003 [<ffffffff8055c71c>] lkdtm_BUG+0x6/0x8 Code: 0513 6945 b097 0031 80e7 e920 b705 1141 e422 0800 (9002) 1141 ---[ end trace 0000000000000000 ]--- note: echo[129] exited with irqs disabled Segmentation fault
(Resume to the shell normally.)
Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Reported-by: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Guo Ren guoren@linux.alibaba.com Signed-off-by: Guo Ren guoren@kernel.org Cc: stable@vger.kernel.org --- arch/riscv/kernel/traps.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index efc6b649985a..ed0eb9452f9e 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -18,6 +18,7 @@ #include <linux/irq.h> #include <linux/kexec.h> #include <linux/entry-common.h> +#include <linux/context_tracking.h>
#include <asm/asm-prototypes.h> #include <asm/bug.h> @@ -257,11 +258,11 @@ asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs)
irqentry_exit_to_user_mode(regs); } else { - irqentry_state_t state = irqentry_nmi_enter(regs); + enum ctx_state prev_state = exception_enter();
handle_break(regs);
- irqentry_nmi_exit(regs, state); + exception_exit(prev_state); } }
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
<snip>
Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Reported-by: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Guo Ren guoren@linux.alibaba.com Signed-off-by: Guo Ren guoren@kernel.org Cc: stable@vger.kernel.org
I pushed this though the kgdb test suite that originally found the problem (although it didn't occur to me when I reported it that the problem was nothing to do with kgdb ;-) ). So FWIW:
Tested-by: Daniel Thompson daniel.thompson@linaro.org
Daniel.
On Mon, Jul 3, 2023 at 6:29 PM Daniel Thompson daniel.thompson@linaro.org wrote:
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
<snip>
Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Reported-by: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Guo Ren guoren@linux.alibaba.com Signed-off-by: Guo Ren guoren@kernel.org Cc: stable@vger.kernel.org
I pushed this though the kgdb test suite that originally found the problem (although it didn't occur to me when I reported it that the problem was nothing to do with kgdb ;-) ). So FWIW:
Tested-by: Daniel Thompson daniel.thompson@linaro.org
Thx for the report & tested-by.
Daniel.
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
This doesn't explain much if anything :/
I'm confused (probably because I don't know RISC-V very well), what's EBREAK and how does it happen?
Specifically, if EBREAK can happen inside an local_irq_disable() region, then the below change is actively wrong. Any exception/interrupt that can happen while local_irq_disable() must be treated like an NMI.
If that makes kdb unhappy, fix kdb.
Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Reported-by: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Guo Ren guoren@linux.alibaba.com Signed-off-by: Guo Ren guoren@kernel.org Cc: stable@vger.kernel.org
arch/riscv/kernel/traps.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index efc6b649985a..ed0eb9452f9e 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -18,6 +18,7 @@ #include <linux/irq.h> #include <linux/kexec.h> #include <linux/entry-common.h> +#include <linux/context_tracking.h> #include <asm/asm-prototypes.h> #include <asm/bug.h> @@ -257,11 +258,11 @@ asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs) irqentry_exit_to_user_mode(regs); } else {
irqentry_state_t state = irqentry_nmi_enter(regs);
enum ctx_state prev_state = exception_enter();handle_break(regs);
irqentry_nmi_exit(regs, state);
exception_exit(prev_state);} -- 2.36.1
On Tue, Jul 04, 2023 at 06:40:03PM +0200, Peter Zijlstra wrote:
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
This doesn't explain much if anything :/
I'm confused (probably because I don't know RISC-V very well), what's EBREAK and how does it happen?
Among other things ebreak is part of the BUG() macro (although it is also used to programmatically enter kgdb).
Specifically, if EBREAK can happen inside an local_irq_disable() region, then the below change is actively wrong. Any exception/interrupt that can happen while local_irq_disable() must be treated like an NMI.
If that makes kdb unhappy, fix kdb.
The only relationship this problem has to kgdb/kdb is that is was found using the kgdb test suite. However the panic is absolutely nothing to do with kgdb.
I would never normally be so sure regarding the absence of bugs in kgdb but in this case it can be reproduced when kgdb is not enabled in the KConfig which I think puts it in the clear!
Reproduction is simply:
/bin/echo BUG > /sys/kernel/debug/provoke-crash/DIRECT
Above will panic the kernel but, absent options specifically requesting a panic, this should kill the echo process rather than killing the kernel.
Daniel.
On Wed, Jul 5, 2023 at 12:40 AM Peter Zijlstra peterz@infradead.org wrote:
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
This doesn't explain much if anything :/
I'm confused (probably because I don't know RISC-V very well), what's EBREAK and how does it happen?
EBREAK is just an instruction of riscv which would rise breakpoint exception.
Specifically, if EBREAK can happen inside an local_irq_disable() region, then the below change is actively wrong. Any exception/interrupt that can happen while local_irq_disable() must be treated like an NMI.
When the ebreak happend out of local_irq_disable region, but __nmi_enter forces handle_break() into in_interupt() state. So how about:
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index f910dfccbf5d..69f7043a98b9 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -18,6 +18,7 @@ #include <linux/irq.h> #include <linux/kexec.h> #include <linux/entry-common.h> +#include <linux/context_tracking.h>
#include <asm/asm-prototypes.h> #include <asm/bug.h> @@ -285,12 +286,18 @@ asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs) handle_break(regs);
irqentry_exit_to_user_mode(regs); - } else { + } else if (in_interrupt()){ irqentry_state_t state = irqentry_nmi_enter(regs);
handle_break(regs);
irqentry_nmi_exit(regs, state); + } else { + enum ctx_state prev_state = exception_enter(); + + handle_break(regs); + + exception_exit(prev_state); } }
If that makes kdb unhappy, fix kdb.
Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Reported-by: Daniel Thompson daniel.thompson@linaro.org Signed-off-by: Guo Ren guoren@linux.alibaba.com Signed-off-by: Guo Ren guoren@kernel.org Cc: stable@vger.kernel.org
arch/riscv/kernel/traps.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index efc6b649985a..ed0eb9452f9e 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -18,6 +18,7 @@ #include <linux/irq.h> #include <linux/kexec.h> #include <linux/entry-common.h> +#include <linux/context_tracking.h>
#include <asm/asm-prototypes.h> #include <asm/bug.h> @@ -257,11 +258,11 @@ asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs)
irqentry_exit_to_user_mode(regs); } else {
irqentry_state_t state = irqentry_nmi_enter(regs);
enum ctx_state prev_state = exception_enter(); handle_break(regs);
irqentry_nmi_exit(regs, state);
exception_exit(prev_state); }}
-- 2.36.1
-- Best Regards Guo Ren
On Sun, Jul 09, 2023 at 10:30:22AM +0800, Guo Ren wrote:
On Wed, Jul 5, 2023 at 12:40 AM Peter Zijlstra peterz@infradead.org wrote:
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
This doesn't explain much if anything :/
I'm confused (probably because I don't know RISC-V very well), what's EBREAK and how does it happen?
EBREAK is just an instruction of riscv which would rise breakpoint exception.
Specifically, if EBREAK can happen inside an local_irq_disable() region, then the below change is actively wrong. Any exception/interrupt that can happen while local_irq_disable() must be treated like an NMI.
When the ebreak happend out of local_irq_disable region, but __nmi_enter forces handle_break() into in_interupt() state. So how
And why is that a problem? I think I'm missing something fundamental here...
about:
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index f910dfccbf5d..69f7043a98b9 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -18,6 +18,7 @@ #include <linux/irq.h> #include <linux/kexec.h> #include <linux/entry-common.h> +#include <linux/context_tracking.h>
#include <asm/asm-prototypes.h> #include <asm/bug.h> @@ -285,12 +286,18 @@ asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs) handle_break(regs);
irqentry_exit_to_user_mode(regs);
} else {
} else if (in_interrupt()){ irqentry_state_t state = irqentry_nmi_enter(regs); handle_break(regs); irqentry_nmi_exit(regs, state);} else {enum ctx_state prev_state = exception_enter();handle_break(regs);exception_exit(prev_state); }}
That's wrong. If you want to make it conditional, you have to look at !(regs->status & SR_IE) (that's the interrupt enable flag of the interrupted context, right?)
When you hit an EBREAK when IRQs were disabled, you must be NMI like.
But making it conditional like this makes it really hard to write a handler though, it basically must assume it will be NMI contetx (because it can't know) so there is no point in sometimes not doing NMI context.
On Mon, Jul 10, 2023 at 4:02 PM Peter Zijlstra peterz@infradead.org wrote:
On Sun, Jul 09, 2023 at 10:30:22AM +0800, Guo Ren wrote:
On Wed, Jul 5, 2023 at 12:40 AM Peter Zijlstra peterz@infradead.org wrote:
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
This doesn't explain much if anything :/
I'm confused (probably because I don't know RISC-V very well), what's EBREAK and how does it happen?
EBREAK is just an instruction of riscv which would rise breakpoint exception.
Specifically, if EBREAK can happen inside an local_irq_disable() region, then the below change is actively wrong. Any exception/interrupt that can happen while local_irq_disable() must be treated like an NMI.
When the ebreak happend out of local_irq_disable region, but __nmi_enter forces handle_break() into in_interupt() state. So how
And why is that a problem? I think I'm missing something fundamental here...
The irqentry_nmi_enter() would force the current context to get in_interrupt=true, although ebreak happens in the context which is in_interrupt=false. A lot of checking codes, such as: if (in_interrupt()) panic("Fatal exception in interrupt"); It would make the kernel panic, but we don't panic; we want back to the shell. eg: echo BUG > /sys/kernel/debug/provoke-crash/DIRECT
about:
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index f910dfccbf5d..69f7043a98b9 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -18,6 +18,7 @@ #include <linux/irq.h> #include <linux/kexec.h> #include <linux/entry-common.h> +#include <linux/context_tracking.h>
#include <asm/asm-prototypes.h> #include <asm/bug.h> @@ -285,12 +286,18 @@ asmlinkage __visible __trap_section void do_trap_break(struct pt_regs *regs) handle_break(regs);
irqentry_exit_to_user_mode(regs);
} else {
} else if (in_interrupt()){ irqentry_state_t state = irqentry_nmi_enter(regs); handle_break(regs); irqentry_nmi_exit(regs, state);} else {enum ctx_state prev_state = exception_enter();handle_break(regs);exception_exit(prev_state); }}
That's wrong. If you want to make it conditional, you have to look at !(regs->status & SR_IE) (that's the interrupt enable flag of the interrupted context, right?)
When you hit an EBREAK when IRQs were disabled, you must be NMI like.
But making it conditional like this makes it really hard to write a handler though, it basically must assume it will be NMI contetx (because it can't know) so there is no point in sometimes not doing NMI context.
On Mon, Jul 17, 2023 at 07:33:25AM +0800, Guo Ren wrote:
On Mon, Jul 10, 2023 at 4:02 PM Peter Zijlstra peterz@infradead.org wrote:
On Sun, Jul 09, 2023 at 10:30:22AM +0800, Guo Ren wrote:
On Wed, Jul 5, 2023 at 12:40 AM Peter Zijlstra peterz@infradead.org wrote:
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
This doesn't explain much if anything :/
I'm confused (probably because I don't know RISC-V very well), what's EBREAK and how does it happen?
EBREAK is just an instruction of riscv which would rise breakpoint exception.
Specifically, if EBREAK can happen inside an local_irq_disable() region, then the below change is actively wrong. Any exception/interrupt that can happen while local_irq_disable() must be treated like an NMI.
When the ebreak happend out of local_irq_disable region, but __nmi_enter forces handle_break() into in_interupt() state. So how
And why is that a problem? I think I'm missing something fundamental here...
The irqentry_nmi_enter() would force the current context to get in_interrupt=true, although ebreak happens in the context which is in_interrupt=false. A lot of checking codes, such as: if (in_interrupt()) panic("Fatal exception in interrupt");
Why would you do that?!?
Are you're trying to differentiate between an exception and an interrupt?
You *could* have ebreak in an interrupt, right? So why panic the machine if that happens?
It would make the kernel panic, but we don't panic; we want back to the shell. eg: echo BUG > /sys/kernel/debug/provoke-crash/DIRECT
On Mon, Jul 17, 2023 at 6:45 PM Peter Zijlstra peterz@infradead.org wrote:
On Mon, Jul 17, 2023 at 07:33:25AM +0800, Guo Ren wrote:
On Mon, Jul 10, 2023 at 4:02 PM Peter Zijlstra peterz@infradead.org wrote:
On Sun, Jul 09, 2023 at 10:30:22AM +0800, Guo Ren wrote:
On Wed, Jul 5, 2023 at 12:40 AM Peter Zijlstra peterz@infradead.org wrote:
On Sat, Jul 01, 2023 at 10:57:07PM -0400, guoren@kernel.org wrote:
From: Guo Ren guoren@linux.alibaba.com
The irqentry_nmi_enter/exit would force the current context into in_interrupt. That would trigger the kernel to dead panic, but the kdb still needs "ebreak" to debug the kernel.
Move irqentry_nmi_enter/exit to exception_enter/exit could correct handle_break of the kernel side.
This doesn't explain much if anything :/
I'm confused (probably because I don't know RISC-V very well), what's EBREAK and how does it happen?
EBREAK is just an instruction of riscv which would rise breakpoint exception.
Specifically, if EBREAK can happen inside an local_irq_disable() region, then the below change is actively wrong. Any exception/interrupt that can happen while local_irq_disable() must be treated like an NMI.
When the ebreak happend out of local_irq_disable region, but __nmi_enter forces handle_break() into in_interupt() state. So how
And why is that a problem? I think I'm missing something fundamental here...
The irqentry_nmi_enter() would force the current context to get in_interrupt=true, although ebreak happens in the context which is in_interrupt=false. A lot of checking codes, such as: if (in_interrupt()) panic("Fatal exception in interrupt");
Why would you do that?!?
Are you're trying to differentiate between an exception and an interrupt?
You *could* have ebreak in an interrupt, right? So why panic the machine if that happens?
Do you mean the below patch? Yes, it could fix up.
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c index f910dfccbf5d..92899db6696b 100644 --- a/arch/riscv/kernel/traps.c +++ b/arch/riscv/kernel/traps.c @@ -85,8 +85,6 @@ void die(struct pt_regs *regs, const char *str) spin_unlock_irqrestore(&die_lock, flags); oops_exit();
- if (in_interrupt()) - panic("Fatal exception in interrupt"); if (panic_on_oops) panic("Fatal exception"); if (ret != NOTIFY_STOP) diff --git a/kernel/exit.c b/kernel/exit.c index edb50b4c9972..a46a1aef66ce 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -940,8 +940,6 @@ void __noreturn make_task_dead(int signr) struct task_struct *tsk = current; unsigned int limit;
- if (unlikely(in_interrupt())) - panic("Aiee, killing interrupt handler!"); if (unlikely(!tsk->pid)) panic("Attempted to kill the idle task!");
But how does x86 deal with it without kernel/exit.c modifcation?
It would make the kernel panic, but we don't panic; we want back to the shell. eg: echo BUG > /sys/kernel/debug/provoke-crash/DIRECT
linux-stable-mirror@lists.linaro.org
-
Daniel Thompson -
Guo Ren -
guoren＠kernel.org
-
Peter Zijlstra