linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Pratyush Anand <panand@redhat.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	William Cohen <wcohen@redhat.com>,
	Steve Capper <steve.capper@linaro.org>,
	David Long <dave.long@linaro.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: Query: ARM64: Behavior of el1_dbg exception while executing el0_dbg
Date: Mon, 12 Jan 2015 17:30:05 +0000	[thread overview]
Message-ID: <20150112173005.GK13360@arm.com> (raw)
In-Reply-To: <54B00C39.1070809@redhat.com>

On Fri, Jan 09, 2015 at 05:13:29PM +0000, Pratyush Anand wrote:
> 
> 
> On Friday 09 January 2015 09:16 PM, Will Deacon wrote:
> > On Thu, Jan 08, 2015 at 05:28:37PM +0000, Pratyush Anand wrote:
> >> On Thursday 08 January 2015 09:53 PM, Will Deacon wrote:
> >>> On Thu, Jan 08, 2015 at 01:15:58PM +0000, Pratyush Anand wrote:
> >>>> I am trying to test following scenario, which seems valid to me. But I
> >>>> am very new to ARM64 as well as to debugging tools, so seeking expert's
> >>>> comment here.
> >>>>
> >>>> -- I have inserted a kprobe to the function uprobe_breakpoint_handler
> >>>> which is called from elo_dbg
> >>>> (el0_dbg->do_debug_exception->brk_handler->call_break_hook->uprobe_breakpoint_handler)
> >>>>
> >>>> -- kprobe is enabled.
> >>>>
> >>>> -- an uprobe is inserted into a test application and enabled.
> >>>>
> >>>> So, when uprobe is enabled and test code execution reaches to probe
> >>>> instruction, it executes uprobe breakpoint instruction and el0_dbg
> >>>> exception is raised.
> >>>>
> >>>> When control reaches to start of uprobe_breakpoint_handler and it
> >>>> executes first instruction (which has been replaced with a kprobe
> >>>> breakpoint instruction), el1_dbg exception is raised.
> >>>
> >>> Hmm, debug exceptions should be masked at this point so I don't see why
> >>> you're taking the second debug exception.
> >>>
> >>
> >> So, you mean to say that when an exception which has been taken from
> >> lower exception level (EL0) is being executed, then we keep masked also
> >> the exception from current exception level (EL1)...
> >
> > Yeah, if you look at entry.S then you'll see that neither el0_dbg or el1_dbg
> > re-enable debug exceptions (masked automatically by the CPU after taking the
> > exception) until *after* the handling has completed. This is to prevent
> > recursive debug exceptions, which I don't see how we can reasonable handle.
> 
> May be I am missing something, but my observation on silicon is 
> different. Please have a look at git log of HEAD of following branch, 
> which says that el1_dbg exception has been raised while el0_dbg was 
> executing. Do not know what I am missing..
> 
> https://github.com/pratyushanand/linux/tree/ml_arm64_uprobe_devel_debug_kprobe_insertion_at_uprobe_breakpoint_handler

That page just says "Failed to load latest commit information." for me.

Regardless, I think you need to debug further and found out if PSTATE.D is
getting cleared and, if so, who is responsible for that. Somebody could be
enabling IRQs, for example, which will then unmask debug exceptions in
el1_irq.

Will

  reply	other threads:[~2015-01-12 17:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <54AE830E.1090000@redhat.com>
     [not found] ` <20150108162312.GO11583@arm.com>
     [not found]   ` <54AEBE45.9080203@redhat.com>
     [not found]     ` <20150109154635.GG11258@arm.com>
2015-01-09 17:13       ` Query: ARM64: Behavior of el1_dbg exception while executing el0_dbg Pratyush Anand
2015-01-12 17:30         ` Will Deacon [this message]
2015-01-12 19:25           ` William Cohen
2015-01-13  6:46           ` Pratyush Anand
2015-01-13 15:52             ` Catalin Marinas
2015-01-13 17:53               ` Pratyush Anand
2015-01-15 16:47                 ` Pratyush Anand
2015-01-16 12:00                   ` Pratyush Anand
2015-01-16 14:55                     ` Pratyush Anand
2015-01-16 16:22                     ` Will Deacon
2015-01-19  6:10                       ` Pratyush Anand
2015-01-19 10:11                         ` Will Deacon

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=20150112173005.GK13360@arm.com \
    --to=will.deacon@arm.com \
    --cc=dave.long@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=panand@redhat.com \
    --cc=steve.capper@linaro.org \
    --cc=wcohen@redhat.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).