All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonardo Bras <leonardo@linux.ibm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.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>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	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>,
	Andrey Konovalov <andreyknvl@google.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Will Deacon <will.deacon@arm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Tony Luck <tony.luck@intel.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Date: Tue, 11 Jun 2019 17:31:12 +0000	[thread overview]
Message-ID: <bec5983d50e37953b3962a6e53fca0a243c7158b.camel@linux.ibm.com> (raw)
In-Reply-To: <7b0a7afd-2776-0d95-19c5-3e15959744eb@arm.com>

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Tue, 2019-06-11 at 10:44 +0530, Anshuman Khandual wrote:
> 
> On 06/10/2019 08:57 PM, Leonardo Bras wrote:
> > On Mon, 2019-06-10 at 08:09 +0530, Anshuman Khandual wrote:
> > > > > +    /*
> > > > > +     * 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))
> > > > 
> > > > don't need an 'if A if B', can do 'if A && B'
> > > 
> > > Which will make it a very lengthy condition check.
> > 
> > Well, is there any problem line-breaking the if condition?
> > 
> > if (A && B && C &&
> >     D && E )
> > 
> > Also, if it's used only to decide the return value, maybe would be fine
> > to do somethink like that:
> > 
> > return (A && B && C &&
> >         D && E ); 
> 
> Got it. But as Dave and Matthew had pointed out earlier, the current x86
> implementation has better readability. Hence will probably stick with it.
> 
Sure, I agree with them. It's way more readable.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Leonardo Bras <leonardo@linux.ibm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.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>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	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>,
	Andrey Konovalov <andreyknvl@google.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Will Deacon <will.deacon@arm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Tony Luck <tony.luck@intel.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Date: Tue, 11 Jun 2019 14:31:12 -0300	[thread overview]
Message-ID: <bec5983d50e37953b3962a6e53fca0a243c7158b.camel@linux.ibm.com> (raw)
In-Reply-To: <7b0a7afd-2776-0d95-19c5-3e15959744eb@arm.com>

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

On Tue, 2019-06-11 at 10:44 +0530, Anshuman Khandual wrote:
> 
> On 06/10/2019 08:57 PM, Leonardo Bras wrote:
> > On Mon, 2019-06-10 at 08:09 +0530, Anshuman Khandual wrote:
> > > > > +    /*
> > > > > +     * 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))
> > > > 
> > > > don't need an 'if A if B', can do 'if A && B'
> > > 
> > > Which will make it a very lengthy condition check.
> > 
> > Well, is there any problem line-breaking the if condition?
> > 
> > if (A && B && C &&
> >     D && E )
> > 
> > Also, if it's used only to decide the return value, maybe would be fine
> > to do somethink like that:
> > 
> > return (A && B && C &&
> >         D && E ); 
> 
> Got it. But as Dave and Matthew had pointed out earlier, the current x86
> implementation has better readability. Hence will probably stick with it.
> 
Sure, I agree with them. It's way more readable.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Leonardo Bras <leonardo@linux.ibm.com>
To: Anshuman Khandual <anshuman.khandual@arm.com>,
	Christophe Leroy <christophe.leroy@c-s.fr>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.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>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	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>,
	Andrey Konovalov <andreyknvl@google.com>,
	Fenghua Yu <fenghua.yu@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Will Deacon <will.deacon@arm.com>,
	Andy Lutomirski <luto@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arm-kernel@lists.infradead.org,
	Tony Luck <tony.luck@intel.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linuxppc-dev@lists.ozlabs.org,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault()
Date: Tue, 11 Jun 2019 14:31:12 -0300	[thread overview]
Message-ID: <bec5983d50e37953b3962a6e53fca0a243c7158b.camel@linux.ibm.com> (raw)
In-Reply-To: <7b0a7afd-2776-0d95-19c5-3e15959744eb@arm.com>


[-- Attachment #1.1: Type: text/plain, Size: 1165 bytes --]

On Tue, 2019-06-11 at 10:44 +0530, Anshuman Khandual wrote:
> 
> On 06/10/2019 08:57 PM, Leonardo Bras wrote:
> > On Mon, 2019-06-10 at 08:09 +0530, Anshuman Khandual wrote:
> > > > > +    /*
> > > > > +     * 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))
> > > > 
> > > > don't need an 'if A if B', can do 'if A && B'
> > > 
> > > Which will make it a very lengthy condition check.
> > 
> > Well, is there any problem line-breaking the if condition?
> > 
> > if (A && B && C &&
> >     D && E )
> > 
> > Also, if it's used only to decide the return value, maybe would be fine
> > to do somethink like that:
> > 
> > return (A && B && C &&
> >         D && E ); 
> 
> Got it. But as Dave and Matthew had pointed out earlier, the current x86
> implementation has better readability. Hence will probably stick with it.
> 
Sure, I agree with them. It's way more readable.

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2019-06-11 17:31 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-07 10:34 [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault() Anshuman Khandual
2019-06-07 10:46 ` Anshuman Khandual
2019-06-07 10:34 ` Anshuman Khandual
2019-06-07 10:34 ` Anshuman Khandual
2019-06-07 12:03 ` Stephen Rothwell
2019-06-07 12:03   ` Stephen Rothwell
2019-06-07 12:03   ` Stephen Rothwell
2019-06-07 12:03   ` Stephen Rothwell
2019-06-10  2:23   ` Anshuman Khandual
2019-06-10  2:35     ` Anshuman Khandual
2019-06-10  2:23     ` Anshuman Khandual
2019-06-10  2:23     ` Anshuman Khandual
2019-06-07 15:06 ` Dave Hansen
2019-06-07 15:06   ` Dave Hansen
2019-06-07 15:06   ` Dave Hansen
2019-06-07 15:06   ` Dave Hansen
2019-06-10  4:36   ` Anshuman Khandual
2019-06-10  4:48     ` Anshuman Khandual
2019-06-10  4:36     ` Anshuman Khandual
2019-06-10  4:36     ` Anshuman Khandual
2019-06-07 15:31 ` Christophe Leroy
2019-06-07 15:31   ` Christophe Leroy
2019-06-07 15:31   ` Christophe Leroy
2019-06-07 15:31   ` Christophe Leroy
2019-06-10  2:39   ` Anshuman Khandual
2019-06-10  2:51     ` Anshuman Khandual
2019-06-10  2:39     ` Anshuman Khandual
2019-06-10  2:39     ` Anshuman Khandual
2019-06-10 15:27     ` Leonardo Bras
2019-06-10 15:27       ` Leonardo Bras
2019-06-10 15:27       ` Leonardo Bras
2019-06-10 15:27       ` Leonardo Bras
2019-06-11  5:14       ` Anshuman Khandual
2019-06-11  5:26         ` Anshuman Khandual
2019-06-11  5:14         ` Anshuman Khandual
2019-06-11  5:14         ` Anshuman Khandual
2019-06-11 17:31         ` Leonardo Bras [this message]
2019-06-11 17:31           ` Leonardo Bras
2019-06-11 17:31           ` Leonardo Bras
2019-06-11  4:46     ` Christophe Leroy
2019-06-11  4:46       ` Christophe Leroy
2019-06-11  4:46       ` Christophe Leroy
2019-06-11  4:46       ` Christophe Leroy
2019-06-11  5:15       ` Anshuman Khandual
2019-06-11  5:27         ` Anshuman Khandual
2019-06-11  5:15         ` Anshuman Khandual
2019-06-11  5:15         ` Anshuman Khandual
2019-06-07 20:12 ` Matthew Wilcox
2019-06-07 20:12   ` Matthew Wilcox
2019-06-07 20:12   ` Matthew Wilcox
2019-06-07 20:12   ` Matthew Wilcox
2019-06-10  4:34   ` Anshuman Khandual
2019-06-10  4:46     ` Anshuman Khandual
2019-06-10  4:34     ` Anshuman Khandual
2019-06-10  4:34     ` Anshuman Khandual
2019-06-10  4:34     ` Anshuman Khandual
2019-06-10  4:57     ` Dave Hansen
2019-06-10  4:57       ` Dave Hansen
2019-06-10  4:57       ` Dave Hansen
2019-06-10  4:57       ` Dave Hansen
2019-06-10  4:57       ` Dave Hansen
2019-06-10  5:06       ` Anshuman Khandual
2019-06-10  5:18         ` Anshuman Khandual
2019-06-10  5:06         ` Anshuman Khandual
2019-06-10  5:06         ` Anshuman Khandual
2019-06-10  5:06         ` 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=bec5983d50e37953b3962a6e53fca0a243c7158b.camel@linux.ibm.com \
    --to=leonardo@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=andreyknvl@google.com \
    --cc=anshuman.khandual@arm.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=linux-arm-kernel@lists.infradead.org \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.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=paulus@samba.org \
    --cc=peterz@infradead.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=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.