On Tue, 2023-07-18 at 15:23 +0200, Greg KH wrote:
> On Tue, Jul 18, 2023 at 03:31:25PM +0300, Eduard Zingerman wrote:
> > On Tue, 2023-07-18 at 01:57 +0300, Eduard Zingerman wrote:
> > > [...]
> > > Still, when I cherry-pick [0,1,2,3] `./test_progs -a setget_sockopt` is failing.
> > > I'll investigate this failure but don't think I'll finish today.
> > >
> > > ---
> > >
> > > Alternatively, if the goal is to minimize amount of changes, we can
> > > disable or modify the 'precise: ST insn causing spi > allocated_stack'.
> > >
> > > ---
> > >
> > > Commits (in chronological order):
> > > [0] be2ef8161572 ("bpf: allow precision tracking for programs with subprogs")
> > > [1] f63181b6ae79 ("bpf: stop setting precise in current state")
> > > [2] 7a830b53c17b ("bpf: aggressively forget precise markings during state checkpointing")
> > > [3] 4f999b767769 ("selftests/bpf: make test_align selftest more robust")
> > > [4] 07d90c72efbe ("Merge branch 'BPF verifier precision tracking improvements'")
> > > [5] ecdf985d7615 ("bpf: track immediate values written to stack by BPF_ST instruction")
> >
> > I made a mistake, while resolving merge conflict for [0] yesterday.
> > After correction the `./test_progs -a setget_sockopt` passes.
> > I also noted that the following tests fail on v6.1.36:
> >
> > ./test_progs -a sk_assign,fexit_bpf2bpf
> >
> > These tests are fixed by back-porting the following upstream commits:
> > - 7ce878ca81bc ("selftests/bpf: Fix sk_assign on s390x")
> > - 63d78b7e8ca2 ("selftests/bpf: Workaround verification failure for fexit_bpf2bpf/func_replace_return_code")
> >
> > I pushed modified version of v6.1.36 to my github account, it has
> > test_verifier, test_progs, test_progs-no_alu32 and test_maps passing
> > (on my x86 setup):
> >
> > https://github.com/eddyz87/bpf/commits/v6.1.36-with-fixes
> >
> > Do you need any additional actions from my side?
>
> I don't understand, what can I do with a github link? Can you send us
> the patches backported so we can apply them to the stable tree?
Sorry, I'm not familiar with procedure for stable tree patches or
who decides what's being picked.
Looks like this situation is "Option 3" from [1], rigth?
After reading that page I'm not sure:
- can I bundle all the necessary commits as a patch-set?
- a few commits need merging, others could be cherry-picked,
is it possible to submit all of them with [ Upstream commit ... ] marks?
Also, as I wrote above, there are two possible solutions:
- backport above mentioned patches
- adjust the test log
[1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
>
> thanks,
>
> greg k-h
