[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191016211943.GD856391@kroah.com>
Date: Wed, 16 Oct 2019 14:19:43 -0700
From: Greg KH <gregkh@...uxfoundation.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Mark-PK Tsai <mark-pk.tsai@...iatek.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
jolsa@...hat.com, namhyung@...nel.org,
Matthias Brugger <matthias.bgg@...il.com>,
Alix Wu <alix.wu@...iatek.com>,
YJ Chiang <yj.chiang@...iatek.com>,
LKML <linux-kernel@...r.kernel.org>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] perf/hw_breakpoint: Fix arch_hw_breakpoint
use-before-initialization
On Thu, Oct 10, 2019 at 10:44:13AM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Sep 5, 2019 at 11:01 PM Mark-PK Tsai <mark-pk.tsai@...iatek.com> wrote:
> >
> > If we disable the compiler's auto-initialization feature
> > (-fplugin-arg-structleak_plugin-byref or -ftrivial-auto-var-init=pattern)
> > is disabled, arch_hw_breakpoint may be used before initialization after
> > the change 9a4903dde2c86.
> > (perf/hw_breakpoint: Split attribute parse and commit)
> >
> > On our arm platform, the struct step_ctrl in arch_hw_breakpoint, which
> > used to be zero-initialized by kzalloc, may be used in
> > arch_install_hw_breakpoint without initialization.
> >
> > Signed-off-by: Mark-PK Tsai <mark-pk.tsai@...iatek.com>
> > Cc: YJ Chiang <yj.chiang@...iatek.com>
> > Cc: Alix Wu <alix.wu@...iatek.com>
> > ---
> > kernel/events/hw_breakpoint.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> Stable should pick this up, please. It landed in mainline as commit
> 310aa0a25b33 ("perf/hw_breakpoint: Fix arch_hw_breakpoint
> use-before-initialization").
>
> * I have confirmed that it cleanly applies to and fixes a kernel based
> on v4.19.75, so picking it back to kernels 4.19+ is the easiest.
>
> * I have confirmed that my test shows that hardware breakpoints fail
> on my arm32 test machine on v4.18.20 and on v4.17.0. They last worked
> on 4.16. Picking this patch alone is not sufficient to make 4.17 and
> 4.18 work again. Bisecting shows that the first breakage was the
> merge resolution that happened in commit 2d074918fb15 ("Merge branch
> 'perf/urgent' into perf/core"). Specifically both parents of that
> merge passed my test but the result of the merge didn't pass my test.
> If anyone cares about 4.17 and 4.18 at this point, I will leave it as
> an exercise to them to try to get them working again.
Now queued up to 4.19.y, thanks.
greg k-h
Powered by blists - more mailing lists