On 2023-07-18 09:52, Eduard Zingerman wrote:
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.
I'm by no means an authority here, but I'll try to help with what I would
do myself.
Looks like this situation is "Option 3" from [1], rigth?
Right.
After reading that page I'm not sure:
- can I bundle all the necessary commits as a patch-set?
Yes.
- a few commits need merging, others could be cherry-picked,
is it possible to submit all of them with [ Upstream commit ... ] marks?
Yes.
Also, as I wrote above, there are two possible solutions:
- backport above mentioned patches
- adjust the test log
I think we want to avoid deviating from upstream (Linus tree), but I'm not
sure if there are valid exceptions.
- Luiz
[1] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
thanks,
greg k-h
