[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANP3RGed9Vbu=8HfLyNs9zwA=biqgyew=+2tVxC6BAx2ktzNxA@mail.gmail.com>
Date: Wed, 15 Jun 2022 09:57:35 -0700
From: Maciej Żenczykowski <maze@...gle.com>
To: Linux NetDev <netdev@...r.kernel.org>,
BPF Mailing List <bpf@...r.kernel.org>,
Maciej Żenczykowski <maze@...gle.com>,
Stanislav Fomichev <sdf@...gle.com>,
Alexei Starovoitov <ast@...nel.org>,
Martin KaFai Lau <kafai@...com>,
Sasha Levin <sashal@...nel.org>,
Carlos Llamas <cmllamas@...gle.com>
Subject: Re: Curious bpf regression in 5.18 already fixed in stable 5.18.3
On Wed, Jun 15, 2022 at 9:45 AM Maciej Żenczykowski
<zenczykowski@...il.com> wrote:
>
> Are you folks aware that:
>
> 'bpf: Move rcu lock management out of BPF_PROG_RUN routines'
>
> fixes a weird regression where sendmsg with an egress tc bpf program
> denying it was returning EFAULT instead of EPERM
>
> I've confirmed vanilla 5.18.0 is broken, and all it takes is
> cherrypicking that specific stable 5.18.x patch [
> 710a8989b4b4067903f5b61314eda491667b6ab3 ] to fix behaviour.
>
> This was not a flaky failure... but a 100% reproducible behavioural
> breakage/failure in the test case at
> https://cs.android.com/android/platform/superproject/+/master:kernel/tests/net/test/bpf_test.py;l=517
> (where 5.18 would return EFAULT instead of EPERM)
I bisected on 5.18.x to find the fixing CL, so I don't know which CL
actually caused the breakage.
sdf says:
5.15 is where they rewrote defines to funcs, so there is still
something else involved it seems
b8bd3ee1971d1edbc53cf322c149ca0227472e56 this is where we added EFAULT in 5.16
(we've added a mechanism to return custom errno, I wonder if some of
that is related)
and that this EFAULT breakage is not something he was expecting to fix...
so it's some sort of unintended consequence.
I recall that:
- vanilla 5.15 and 5.16 are definitely good
- I think the only regression in 5.17 is an unrelated icmp socket one
- so from a bpf perspective it was also good.
- 5.18 had 3 regressions: icmp sockets, the pf_key regression (fixed
via revert in 5.18.4) plus this bpf one
The bad pf_key change being reverted in 5.18.4 is why I even switched
from dev/test against 5.18 to against 5.18.4
and noticed that this was already fixed before I could even report it...
Powered by blists - more mailing lists