Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()")
From: Peter Zijlstra <peterz@infradead.org>
Date: 2021-01-29 18:00:55
Also in:
lkml
Possibly related (same subject, not in this thread)
- 2021-01-29 · Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") · Nikolay Borisov <hidden>
- 2021-01-29 · Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") · Alexei Starovoitov <hidden>
- 2021-01-28 · Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") · Peter Zijlstra <peterz@infradead.org>
- 2021-01-28 · Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") · Josh Poimboeuf <hidden>
- 2021-01-28 · Re: kprobes broken since 0d00449c7a28 ("x86: Replace ist_enter() with nmi_enter()") · Nikolay Borisov <hidden>
On Fri, Jan 29, 2021 at 09:45:48AM -0800, Alexei Starovoitov wrote:
Same things apply to bpf side. We can statically prove safety for ftrace and kprobe attaching whereas to deal with NMI situation we have to use run-time checks for recursion prevention, etc.
I have no idea what you're saying. You can attach to functions that are called with random locks held, you can create kprobes in some very sensitive places. What can you staticlly prove about that?