From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anshuman Khandual Date: Tue, 11 Jun 2019 05:26:00 +0000 Subject: Re: [RFC V3] mm: Generalize and rename notify_page_fault() as kprobe_page_fault() Message-Id: <7b0a7afd-2776-0d95-19c5-3e15959744eb@arm.com> List-Id: References: <1559903655-5609-1-git-send-email-anshuman.khandual@arm.com> <97e9c9b3-89c8-d378-4730-841a900e6800@arm.com> <8dd6168592437378ff4a7c204e0f2962d002b44f.camel@linux.ibm.com> In-Reply-To: <8dd6168592437378ff4a7c204e0f2962d002b44f.camel@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Leonardo Bras , Christophe Leroy , linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Mark Rutland , Michal Hocko , linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org, Peter Zijlstra , Catalin Marinas , Dave Hansen , Heiko Carstens , Paul Mackerras , sparclinux@vger.kernel.org, linux-s390@vger.kernel.org, Yoshinori Sato , x86@kernel.org, Russell King , Matthew Wilcox , Ingo Molnar , Andrey Konovalov , Fenghua Yu , Stephen Rothwell , Will Deacon , Andy Lutomirski , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, Tony Luck , Martin Schwidefsky , Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" 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.