Thread (7 messages) 7 messages, 2 authors, 2019-06-03

Re: [RFC] mm: Generalize notify_page_fault()

From: Anshuman Khandual <hidden>
Date: 2019-06-03 04:53:21
Also in: linux-arm-kernel, linux-mm, linux-s390, linux-sh, lkml, sparclinux


On 05/31/2019 11:18 PM, Matthew Wilcox wrote:
On Fri, May 31, 2019 at 02:17:43PM +0530, Anshuman Khandual wrote:
quoted
On 05/30/2019 07:09 PM, Matthew Wilcox wrote:
quoted
On Thu, May 30, 2019 at 05:31:15PM +0530, Anshuman Khandual wrote:
quoted
On 05/30/2019 04:36 PM, Matthew Wilcox wrote:
quoted
The two handle preemption differently.  Why is x86 wrong and this one
correct?
Here it expects context to be already non-preemptible where as the proposed
generic function makes it non-preemptible with a preempt_[disable|enable]()
pair for the required code section, irrespective of it's present state. Is
not this better ?
git log -p arch/x86/mm/fault.c

search for 'kprobes'.

tell me what you think.
Are you referring to these following commits

a980c0ef9f6d ("x86/kprobes: Refactor kprobes_fault() like kprobe_exceptions_notify()")
b506a9d08bae ("x86: code clarification patch to Kprobes arch code")

In particular the later one (b506a9d08bae). It explains how the invoking context
in itself should be non-preemptible for the kprobes processing context irrespective
of whether kprobe_running() or perhaps smp_processor_id() is safe or not. Hence it
does not make much sense to continue when original invoking context is preemptible.
Instead just bail out earlier. This seems to be making more sense than preempt
disable-enable pair. If there are no concerns about this change from other platforms,
I will change the preemption behavior in proposed generic function next time around.
Exactly.

So, any of the arch maintainers know of a reason they behave differently
from x86 in this regard?  Or can Anshuman use the x86 implementation
for all the architectures supporting kprobes?
So the generic notify_page_fault() will be like this.

int __kprobes notify_page_fault(struct pt_regs *regs, unsigned int trap)
{
        int ret = 0;

        /*
         * To be potentially processing a kprobe fault and to be allowed
         * to call kprobe_running(), we have to be non-preemptible.
         */
        if (kprobes_built_in() && !preemptible() && !user_mode(regs)) {
                if (kprobe_running() && kprobe_fault_handler(regs, trap))
                        ret = 1;
        }
        return ret;
}
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help