Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
From: Andrew Morton <akpm@linux-foundation.org>
Date: 2019-06-13 20:04:14
Also in:
linux-arm-kernel, linux-mips, linux-mm, linux-s390, linux-sh, lkml, sparclinux
On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual [off-list ref] wrote:
quoted hunk ↗ jump to hunk
Architectures which support kprobes have very similar boilerplate around calling kprobe_fault_handler(). Use a helper function in kprobes.h to unify them, based on the x86 code. This changes the behaviour for other architectures when preemption is enabled. Previously, they would have disabled preemption while calling the kprobe handler. However, preemption would be disabled if this fault was due to a kprobe, so we know the fault was not due to a kprobe handler and can simply return failure. This behaviour was introduced in the commit a980c0ef9f6d ("x86/kprobes: Refactor kprobes_fault() like kprobe_exceptions_notify()") ...--- a/arch/arm/mm/fault.c +++ b/arch/arm/mm/fault.c@@ -30,28 +30,6 @@ #ifdef CONFIG_MMU -#ifdef CONFIG_KPROBES -static inline int notify_page_fault(struct pt_regs *regs, unsigned int fsr)
Some architectures make this `static inline'. Others make it `nokprobes_inline', others make it `static inline __kprobes'. The latter seems weird - why try to put an inline function into .kprobes.text? So.. what's the best thing to do here? You chose `static nokprobe_inline' - is that the best approach, if so why? Does kprobe_page_fault() actually need to be inlined? Also, some architectures had notify_page_fault returning int, others bool. You chose bool and that seems appropriate and all callers are OK with that.