Re: [PATCH 5.5 000/171] 5.5.14-rc2 review

From: Greg Kroah-Hartman
Date: Wed Apr 01 2020 - 02:11:37 EST


On Wed, Apr 01, 2020 at 04:18:41AM +0530, Naresh Kamboju wrote:
> On Tue, 31 Mar 2020 at 21:02, Greg Kroah-Hartman
> <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >
> > This is the start of the stable review cycle for the 5.5.14 release.
> > There are 171 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Thu, 02 Apr 2020 14:12:02 +0000.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.5.14-rc2.gz
> > or in the git tree and branch at:
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-5.5.y
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
>
>
> Results from Linaroâs test farm.
> Regressions on x86_64 and i386.
>
> selftests bpf test_verifier reports as failed.
> This test PASSED on v5.5.13
>
> #554/p jgt32: range bound deduction, reg op imm FAIL
> Failed to load prog 'Success'!
> R8 unbounded memory access, make sure to bounds check any array access
> into a map
> verification time 141 usec
> stack depth 8
> processed 16 insns (limit 1000000) max_states_per_insn 0 total_states
> 1 peak_states 1 mark_read 1
> #555/p jgt32: range bound deduction, reg1 op reg2, reg1 unknown FAIL
> Failed to load prog 'Success'!
> R8 unbounded memory access, make sure to bounds check any array access
> into a map
> verification time 94 usec
> stack depth 8
> processed 17 insns (limit 1000000) max_states_per_insn 0 total_states
> 1 peak_states 1 mark_read 1
> #556/p jle32: range bound deduction, reg1 op reg2, reg2 unknown FAIL
> Failed to load prog 'Success'!
> R8 unbounded memory access, make sure to bounds check any array access
> into a map
> verification time 68 usec
> stack depth 8
> processed 17 insns (limit 1000000) max_states_per_insn 0 total_states
> 1 peak_states 1 mark_read 1

Can you run 'git bisect' to find the offending patch?

thanks,

greg k-h