From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Michal Hocko <mhocko@suse.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Will Deacon <will.deacon@arm.com>,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, Russell King <linux@armlinux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Ingo Molnar <mingo@redhat.com>, James Hogan <jhogan@kernel.org>,
linux-snps-arc@lists.infradead.org,
Fenghua Yu <fenghua.yu@intel.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrey Konovalov <andreyknvl@google.com>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Christophe Leroy <christophe.leroy@c-s.fr>,
Tony Luck <tony.luck@intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Date: Fri, 14 Jun 2019 05:27:44 +0000 [thread overview]
Message-ID: <c3316aca-2005-e092-80f6-ebd7652bd04f@arm.com> (raw)
In-Reply-To: <20190613130408.3091869d8e50d0524157523f@linux-foundation.org>
On 06/14/2019 01:34 AM, Andrew Morton wrote:
> On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>> 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?
Matthew had suggested that (nokprobe_-inline) based on current x86
implementation. But every architecture already had an inlined definition
which I did not want to deviate from.
>
> 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.
I would believe so. No one has complained yet :)
WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linux-snps-arc@lists.infradead.org, linux-mips@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
linux-sh@vger.kernel.org, sparclinux@vger.kernel.org,
x86@kernel.org, Michal Hocko <mhocko@suse.com>,
Matthew Wilcox <willy@infradead.org>,
Mark Rutland <mark.rutland@arm.com>,
Christophe Leroy <christophe.leroy@c-s.fr>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrey Konovalov <andreyknvl@google.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Paul Mackerras <paulus@samba.org>,
Russell King <linux@armlinux.org.uk>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will.deacon@arm.com>,
Tony Luck <tony.luck@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
"David S. Miller" <davem@davemloft.net>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Andy Lutomirski <luto@kernel.org>,
Dave Hansen <dave.hansen@linux.intel.com>,
Vineet Gupta <vgupta@synopsys.com>,
James Hogan <jhogan@kernel.org>,
Paul Burton <paul.burton@mips.com>,
Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Date: Fri, 14 Jun 2019 10:45:44 +0530 [thread overview]
Message-ID: <c3316aca-2005-e092-80f6-ebd7652bd04f@arm.com> (raw)
In-Reply-To: <20190613130408.3091869d8e50d0524157523f@linux-foundation.org>
On 06/14/2019 01:34 AM, Andrew Morton wrote:
> On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>> 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?
Matthew had suggested that (nokprobe_-inline) based on current x86
implementation. But every architecture already had an inlined definition
which I did not want to deviate from.
>
> 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.
I would believe so. No one has complained yet :)
WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Michal Hocko <mhocko@suse.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Will Deacon <will.deacon@arm.com>,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
x86@kernel.org, Russell King <linux@armlinux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Ingo Molnar <mingo@redhat.com>, James Hogan <jhogan@kernel.org>,
linux-snps-arc@lists.infradead.org,
Fenghua Yu <fenghua.yu@intel.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrey Konovalov <andreyknvl@google.com>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Tony Luck <tony.luck@intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Date: Fri, 14 Jun 2019 10:45:44 +0530 [thread overview]
Message-ID: <c3316aca-2005-e092-80f6-ebd7652bd04f@arm.com> (raw)
In-Reply-To: <20190613130408.3091869d8e50d0524157523f@linux-foundation.org>
On 06/14/2019 01:34 AM, Andrew Morton wrote:
> On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>> 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?
Matthew had suggested that (nokprobe_-inline) based on current x86
implementation. But every architecture already had an inlined definition
which I did not want to deviate from.
>
> 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.
I would believe so. No one has complained yet :)
WARNING: multiple messages have this Message-ID (diff)
From: anshuman.khandual@arm.com (Anshuman Khandual)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Date: Fri, 14 Jun 2019 10:45:44 +0530 [thread overview]
Message-ID: <c3316aca-2005-e092-80f6-ebd7652bd04f@arm.com> (raw)
In-Reply-To: <20190613130408.3091869d8e50d0524157523f@linux-foundation.org>
On 06/14/2019 01:34 AM, Andrew Morton wrote:
> On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>> 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?
Matthew had suggested that (nokprobe_-inline) based on current x86
implementation. But every architecture already had an inlined definition
which I did not want to deviate from.
>
> 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.
I would believe so. No one has complained yet :)
WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Michal Hocko <mhocko@suse.com>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Will Deacon <will.deacon@arm.com>,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
Paul Mackerras <paulus@samba.org>,
sparclinux@vger.kernel.org, linux-s390@vger.kernel.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Michael Ellerman <mpe@ellerman.id.au>,
x86@kernel.org, Russell King <linux@armlinux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Ingo Molnar <mingo@redhat.com>, James Hogan <jhogan@kernel.org>,
linux-snps-arc@lists.infradead.org,
Fenghua Yu <fenghua.yu@intel.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Andrey Konovalov <andreyknvl@google.com>,
Andy Lutomirski <luto@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
linux-arm-kernel@lists.infradead.org,
Christophe Leroy <christophe.leroy@c-s.fr>,
Tony Luck <tony.luck@intel.com>,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Date: Fri, 14 Jun 2019 10:45:44 +0530 [thread overview]
Message-ID: <c3316aca-2005-e092-80f6-ebd7652bd04f@arm.com> (raw)
In-Reply-To: <20190613130408.3091869d8e50d0524157523f@linux-foundation.org>
On 06/14/2019 01:34 AM, Andrew Morton wrote:
> On Thu, 13 Jun 2019 15:37:24 +0530 Anshuman Khandual <anshuman.khandual@arm.com> wrote:
>
>> 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?
Matthew had suggested that (nokprobe_-inline) based on current x86
implementation. But every architecture already had an inlined definition
which I did not want to deviate from.
>
> 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.
I would believe so. No one has complained yet :)
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-06-14 5:27 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-13 10:07 [PATCH] mm: Generalize and rename notify_page_fault() as kprobe_page_fault() Anshuman Khandual
2019-06-13 10:19 ` Anshuman Khandual
2019-06-13 10:07 ` Anshuman Khandual
2019-06-13 10:07 ` Anshuman Khandual
2019-06-13 10:07 ` Anshuman Khandual
2019-06-13 17:57 ` Vineet Gupta
2019-06-13 17:57 ` Vineet Gupta
2019-06-13 17:57 ` Vineet Gupta
2019-06-13 17:57 ` Vineet Gupta
2019-06-13 17:57 ` Vineet Gupta
2019-06-18 15:56 ` Vineet Gupta
2019-06-18 15:56 ` Vineet Gupta
2019-06-18 15:56 ` Vineet Gupta
2019-06-20 7:19 ` Masami Hiramatsu
2019-06-20 7:19 ` Masami Hiramatsu
2019-06-20 7:19 ` Masami Hiramatsu
2019-06-13 20:04 ` Andrew Morton
2019-06-13 20:04 ` Andrew Morton
2019-06-13 20:04 ` Andrew Morton
2019-06-13 20:04 ` Andrew Morton
2019-06-13 20:04 ` Andrew Morton
2019-06-14 5:15 ` Anshuman Khandual [this message]
2019-06-14 5:27 ` Anshuman Khandual
2019-06-14 5:15 ` Anshuman Khandual
2019-06-14 5:15 ` Anshuman Khandual
2019-06-14 5:15 ` Anshuman Khandual
2019-06-29 14:50 ` Guenter Roeck
2019-06-29 14:50 ` Guenter Roeck
2019-06-29 14:50 ` Guenter Roeck
2019-06-29 14:50 ` Guenter Roeck
2019-06-29 14:50 ` Guenter Roeck
2019-06-30 4:41 ` Anshuman Khandual
2019-06-30 4:53 ` Anshuman Khandual
2019-06-30 4:41 ` Anshuman Khandual
2019-06-30 4:41 ` Anshuman Khandual
2019-06-30 4:41 ` Anshuman Khandual
2019-07-01 9:35 ` [DRAFT] mm/kprobes: Add generic kprobe_fault_handler() fallback definition Anshuman Khandual
2019-07-01 13:28 ` Guenter Roeck
2019-07-03 5:35 ` Anshuman Khandual
2019-07-03 12:59 ` Guenter Roeck
2019-07-03 14:11 ` Anshuman Khandual
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c3316aca-2005-e092-80f6-ebd7652bd04f@arm.com \
--to=anshuman.khandual@arm.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=catalin.marinas@arm.com \
--cc=christophe.leroy@c-s.fr \
--cc=dave.hansen@linux.intel.com \
--cc=davem@davemloft.net \
--cc=fenghua.yu@intel.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jhogan@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=paul.burton@mips.com \
--cc=paulus@samba.org \
--cc=peterz@infradead.org \
--cc=ralf@linux-mips.org \
--cc=schwidefsky@de.ibm.com \
--cc=sfr@canb.auug.org.au \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=vgupta@synopsys.com \
--cc=will.deacon@arm.com \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=ysato@users.sourceforge.jp \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.