[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160907134120.7bjzgk3f2ntvl3qy@localhost>
Date: Wed, 7 Sep 2016 14:41:21 +0100
From: Catalin Marinas <catalin.marinas@....com>
To: David Long <dave.long@...aro.org>
Cc: Pratyush Anand <panand@...hat.com>, Yang Shi <yang.shi@...aro.org>,
steve.capper@...aro.org, srikar@...ux.vnet.ibm.com,
Suzuki K Poulose <suzuki.poulose@....com>,
vijaya.kumar@...iumnetworks.com, will.deacon@....com,
linux-kernel@...r.kernel.org, oleg@...hat.com,
Sandeepa Prabhu <sandeepa.s.prabhu@...il.com>,
linux@....linux.org.uk, wcohen@...hat.com,
Anna-Maria Gleixner <anna-maria@...utronix.de>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 3/5] arm64: Handle TRAP_HWBRKPT for user mode as well
On Tue, Sep 06, 2016 at 05:36:18PM -0400, David Long wrote:
> On 09/06/2016 12:11 PM, Catalin Marinas wrote:
> > On Tue, Aug 02, 2016 at 11:00:07AM +0530, Pratyush Anand wrote:
> > > --- a/arch/arm64/kernel/debug-monitors.c
> > > +++ b/arch/arm64/kernel/debug-monitors.c
> > > @@ -246,6 +246,8 @@ static void send_user_sigtrap(int si_code)
> > > static int single_step_handler(unsigned long addr, unsigned int esr,
> > > struct pt_regs *regs)
> > > {
> > > + bool handler_found = false;
> > > +
> > > /*
> > > * If we are stepping a pending breakpoint, call the hw_breakpoint
> > > * handler first.
> > > @@ -253,7 +255,14 @@ static int single_step_handler(unsigned long addr, unsigned int esr,
> > > if (!reinstall_suspended_bps(regs))
> > > return 0;
> > >
> > > - if (user_mode(regs)) {
> > > +#ifdef CONFIG_KPROBES
> > > + if (kprobe_single_step_handler(regs, esr) == DBG_HOOK_HANDLED)
> > > + handler_found = true;
> > > +#endif
> > > + if (!handler_found && call_step_hook(regs, esr) == DBG_HOOK_HANDLED)
> > > + handler_found = true;
> > > +
> > > + if (!handler_found && user_mode(regs)) {
> > > send_user_sigtrap(TRAP_HWBKPT);
> >
> > Could we register kprobe_single_step_handler() via register_set_hook()
> > and only invoke call_step_hook() above?
>
> I seem to recall a criticism of doing that in a much earlier kprobes64 patch
> of mine. The concern was that it would cause unnecessarily more kernel
> functions to be kprobes-blacklisted. Hence the hardcoded check and call.
Ah, ok. I missed this aspect.
--
Catalin
Powered by blists - more mailing lists