All of lore.kernel.org
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] arm64/debug: Fix registers on sleeping tasks
Date: Thu, 8 Mar 2018 16:43:18 +0000	[thread overview]
Message-ID: <20180308164318.GE9573@arm.com> (raw)
In-Reply-To: <CAD=FV=X4_AQFBxWpinDj5F9DUckC02dQ_2QPFQRs34e5_b00bQ@mail.gmail.com>

On Thu, Mar 08, 2018 at 08:41:59AM -0800, Doug Anderson wrote:
> Hi,
> 
> On Thu, Mar 8, 2018 at 8:19 AM, Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> > On 05/03/18 23:43, Douglas Anderson wrote:
> >>
> >> This is the equivalent of commit 001bf455d206 ("ARM: 8428/1: kgdb: Fix
> >> registers on sleeping tasks") but for arm64.  Nuff said.
> >>
> >> ...well, perhaps I could also add that task_pt_regs are userspace
> >> registers and that's not what kgdb is supposed to be reporting.  We're
> >> supposed to be reporting kernel registers.
> >>
> >> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> >
> >
> > I hacked together a (still very immature) kgdb test suite[1] around the turn
> > of the year. Whilst its not quite solid enough for me to recommend others
> > deploy it except out of curiosity... so I haven't yet started yelling about
> > test suite failures except in the privacy of my own head.
> >
> > However I can confirm that this patch fixes one of the test suite failures I
> > haven't had time to blame allocate yet!
> >
> > So...
> > Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
> 
> Thanks for your testing!  ...I'll have to check out your test suite soon.
> 
> 
> > BTW is this something that should Cc: stable?
> 
> It wouldn't hurt if this made it back to stable on a best-effort
> approach.  The problem has been there since the beginning, so it's not
> like it's fixing a regression that cropped up in a specific version.
> ...but it does fix a bug, so probably Cc stable makes sense.  I guess
> I'd leave it up to the maintainer that applies the patch?

I've already put this into -next, so I don't really want to rebase just for
this. If you think it's important, please send to stable at vger.kernel.org
once it's landed in mainline.

Will

WARNING: multiple messages have this Message-ID (diff)
From: Will Deacon <will.deacon@arm.com>
To: Doug Anderson <dianders@chromium.org>
Cc: Daniel Thompson <daniel.thompson@linaro.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Brian Norris <briannorris@chromium.org>,
	evgreen@chromium.org, swboyd@chromium.org,
	LKML <linux-kernel@vger.kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] arm64/debug: Fix registers on sleeping tasks
Date: Thu, 8 Mar 2018 16:43:18 +0000	[thread overview]
Message-ID: <20180308164318.GE9573@arm.com> (raw)
In-Reply-To: <CAD=FV=X4_AQFBxWpinDj5F9DUckC02dQ_2QPFQRs34e5_b00bQ@mail.gmail.com>

On Thu, Mar 08, 2018 at 08:41:59AM -0800, Doug Anderson wrote:
> Hi,
> 
> On Thu, Mar 8, 2018 at 8:19 AM, Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> > On 05/03/18 23:43, Douglas Anderson wrote:
> >>
> >> This is the equivalent of commit 001bf455d206 ("ARM: 8428/1: kgdb: Fix
> >> registers on sleeping tasks") but for arm64.  Nuff said.
> >>
> >> ...well, perhaps I could also add that task_pt_regs are userspace
> >> registers and that's not what kgdb is supposed to be reporting.  We're
> >> supposed to be reporting kernel registers.
> >>
> >> Signed-off-by: Douglas Anderson <dianders@chromium.org>
> >
> >
> > I hacked together a (still very immature) kgdb test suite[1] around the turn
> > of the year. Whilst its not quite solid enough for me to recommend others
> > deploy it except out of curiosity... so I haven't yet started yelling about
> > test suite failures except in the privacy of my own head.
> >
> > However I can confirm that this patch fixes one of the test suite failures I
> > haven't had time to blame allocate yet!
> >
> > So...
> > Tested-by: Daniel Thompson <daniel.thompson@linaro.org>
> 
> Thanks for your testing!  ...I'll have to check out your test suite soon.
> 
> 
> > BTW is this something that should Cc: stable?
> 
> It wouldn't hurt if this made it back to stable on a best-effort
> approach.  The problem has been there since the beginning, so it's not
> like it's fixing a regression that cropped up in a specific version.
> ...but it does fix a bug, so probably Cc stable makes sense.  I guess
> I'd leave it up to the maintainer that applies the patch?

I've already put this into -next, so I don't really want to rebase just for
this. If you think it's important, please send to stable@vger.kernel.org
once it's landed in mainline.

Will

  reply	other threads:[~2018-03-08 16:43 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-05 23:43 [PATCH v2] arm64/debug: Fix registers on sleeping tasks Douglas Anderson
2018-03-05 23:43 ` Douglas Anderson
2018-03-08 16:19 ` Daniel Thompson
2018-03-08 16:19   ` Daniel Thompson
2018-03-08 16:41   ` Doug Anderson
2018-03-08 16:41     ` Doug Anderson
2018-03-08 16:43     ` Will Deacon [this message]
2018-03-08 16:43       ` 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=20180308164318.GE9573@arm.com \
    --to=will.deacon@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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.