[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190726121354.GB26088@lakrids.cambridge.arm.com>
Date: Fri, 26 Jul 2019 13:13:54 +0100
From: Mark Rutland <mark.rutland@....com>
To: Anders Roxell <anders.roxell@...aro.org>
Cc: will@...nel.org, catalin.marinas@....com,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org,
"Gustavo A. R. Silva" <gustavo@...eddedor.com>,
Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH 1/3] arm64: perf: Mark expected switch fall-through
On Fri, Jul 26, 2019 at 01:10:57PM +0100, Mark Rutland wrote:
> On Fri, Jul 26, 2019 at 01:27:16PM +0200, Anders Roxell wrote:
> > When fall-through warnings was enabled by default, commit d93512ef0f0e
> > ("Makefile: Globally enable fall-through warning"), the following
> > warnings was starting to show up:
> >
> > ../arch/arm64/kernel/hw_breakpoint.c: In function ‘hw_breakpoint_arch_parse’:
> > ../arch/arm64/kernel/hw_breakpoint.c:540:7: warning: this statement may fall
> > through [-Wimplicit-fallthrough=]
> > if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
> > ^
> > ../arch/arm64/kernel/hw_breakpoint.c:542:3: note: here
> > case 2:
> > ^~~~
> > ../arch/arm64/kernel/hw_breakpoint.c:544:7: warning: this statement may fall
> > through [-Wimplicit-fallthrough=]
> > if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2)
> > ^
> > ../arch/arm64/kernel/hw_breakpoint.c:546:3: note: here
> > default:
> > ^~~~~~~
> >
> > Rework so that the compiler doesn't warn about fall-through. Rework so
> > the code looks like the arm code. Since the comment in the function
> > indicates taht this is supposed to behave the same way as arm32 because
>
> Typo: s/taht/that/
>
> > it handles 32-bit tasks also.
> >
> > Cc: stable@...r.kernel.org # v3.16+
> > Fixes: 6ee33c2712fc ("ARM: hw_breakpoint: correct and simplify alignment fixup code")
> > Signed-off-by: Anders Roxell <anders.roxell@...aro.org>
>
> The patch itself looks fine, but I don't think this needs a CC to
> stable, nor does it require that fixes tag, as there's no functional
> problem.
Hmm... I now see I spoke too soon, and this is making the 1-byte
breakpoint work at a 3-byte offset.
Given that:
Acked-by: Mark Rutland <mark.rutland@....com>
... and the fixes and stable tags are appropriate for that portion of
the patch.
Sorry for the noise.
Thanks,
Mark.
> > ---
> > arch/arm64/kernel/hw_breakpoint.c | 11 +++++++----
> > 1 file changed, 7 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/hw_breakpoint.c b/arch/arm64/kernel/hw_breakpoint.c
> > index dceb84520948..ea616adf1cf1 100644
> > --- a/arch/arm64/kernel/hw_breakpoint.c
> > +++ b/arch/arm64/kernel/hw_breakpoint.c
> > @@ -535,14 +535,17 @@ int hw_breakpoint_arch_parse(struct perf_event *bp,
> > case 0:
> > /* Aligned */
> > break;
> > - case 1:
> > - /* Allow single byte watchpoint. */
> > - if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
> > - break;
> > case 2:
> > /* Allow halfword watchpoints and breakpoints. */
> > if (hw->ctrl.len == ARM_BREAKPOINT_LEN_2)
> > break;
> > + /* Fall through */
> > + case 1:
> > + case 3:
> > + /* Allow single byte watchpoint. */
> > + if (hw->ctrl.len == ARM_BREAKPOINT_LEN_1)
> > + break;
> > + /* Fall through */
> > default:
> > return -EINVAL;
> > }
> > --
> > 2.20.1
> >
Powered by blists - more mailing lists