[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8b184218-6880-204e-a9dd-e627c5ca92ca@synopsys.com>
Date: Tue, 18 Jun 2019 08:56:33 -0700
From: Vineet Gupta <Vineet.Gupta1@...opsys.com>
To: <linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
Eugeniy Paltsev <Eugeniy.Paltsev@...opsys.com>
CC: Anshuman Khandual <anshuman.khandual@....com>,
Fenghua Yu <fenghua.yu@...el.com>,
arcml <linux-snps-arc@...ts.infradead.org>,
"Masami Hiramatsu" <mhiramat@...nel.org>
Subject: Re: [PATCH] mm: Generalize and rename notify_page_fault() as
kprobe_page_fault()
+CC Masami San, Eugeniy
On 6/13/19 10:57 AM, Vineet Gupta wrote:
> On 6/13/19 3:07 AM, Anshuman Khandual wrote:
>> Questions:
>>
>> AFAICT there is no equivalent of erstwhile notify_page_fault() during page
>> fault handling in arc and mips archs which can call this generic function.
>> Please let me know if that is not the case.
>
> For ARC do_page_fault() is entered for MMU exceptions (TLB Miss, access violations
> r/w/x etc). kprobes uses a combination of UNIMP_S and TRAP_S instructions which
> don't funnel into do_page_fault().
>
> UINMP_S leads to
>
> instr_service
> do_insterror_or_kprobe
> notify_die(DIE_IERR)
> kprobe_exceptions_notify
> arc_kprobe_handler
>
>
> TRAP_S 2 leads to
>
> EV_Trap
> do_non_swi_trap
> trap_is_kprobe
> notify_die(DIE_TRAP)
> kprobe_exceptions_notify
> arc_post_kprobe_handler
>
> But indeed we are *not* calling into kprobe_fault_handler() - from eithet of those
> paths and not sure if the existing arc*_kprobe_handler() combination does the
> equivalent in tandem.
@Eugeniy can you please investigate this - do we have krpobes bit rot in ARC port.
-Vineet
Powered by blists - more mailing lists