Re: [5.10, 5.15] New bpf kselftest failure

[Luiz Capitulino <luizcap@amazon.com>]

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
>