[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAADnVQJWm_CJobz71_FRPTFeVojHLgmYmQA4tVhOg3MDP2V2Dw@mail.gmail.com>
Date: Fri, 6 Sep 2024 15:41:47 -0700
From: Alexei Starovoitov <alexei.starovoitov@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Philo Lu <lulie@...ux.alibaba.com>, bpf <bpf@...r.kernel.org>,
Eric Dumazet <edumazet@...gle.com>, Steven Rostedt <rostedt@...dmis.org>,
Masami Hiramatsu <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Martin KaFai Lau <martin.lau@...ux.dev>, Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>, Andrii Nakryiko <andrii@...nel.org>, Eddy Z <eddyz87@...il.com>,
Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>,
Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
"David S. Miller" <davem@...emloft.net>, Paolo Abeni <pabeni@...hat.com>, Mykola Lysenko <mykolal@...com>,
Shuah Khan <shuah@...nel.org>, Maxime Coquelin <mcoquelin.stm32@...il.com>,
Alexandre Torgue <alexandre.torgue@...s.st.com>, Kui-Feng Lee <thinker.li@...il.com>,
Juntong Deng <juntong.deng@...look.com>, jrife@...gle.com,
Alan Maguire <alan.maguire@...cle.com>, Dave Marchevsky <davemarchevsky@...com>,
Daniel Xu <dxu@...uu.xyz>, Viktor Malik <vmalik@...hat.com>,
Cupertino Miranda <cupertino.miranda@...cle.com>, Matt Bobrowski <mattbobrowski@...gle.com>,
Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Network Development <netdev@...r.kernel.org>,
linux-trace-kernel <linux-trace-kernel@...r.kernel.org>
Subject: Re: [PATCH bpf-next v2 3/5] tcp: Use skb__nullable in trace_tcp_send_reset
On Fri, Sep 6, 2024 at 3:23 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Thu, 5 Sep 2024 17:26:42 -0700 Alexei Starovoitov wrote:
> > Yes, it's a bit of a whack a mole and eventually we can get rid of it
> > with a smarter verifier (likely) or smarter objtool (unlikely).
> > Long term we should be able to analyze body of TP_fast_assign
> > automatically and conclude whether it's handling NULL for pointer
> > arguments or not. bpf verifier can easily do it for bpf code.
> > We just need to compile TP_fast_assign() as a tiny bpf snippet.
> > This is work in progress.
>
> Can we not wait for that work to conclude, then? AFAIU this whole
> patch set is just a minor quality of life improvement for BPF progs
> at the expense of carrying questionable changes upstream.
> I don't see the urgency.
The urgency is now because the situation is dire.
The verifier assumes that skb is not null and will remove
if (!skb) check assuming that it's a dead code.
This patch set adds trusted stuff and fixes this issue too
which is the more important part.
Also it's not clear how long it will take to do 'dual compile'.
It's showing promise atm, but timelines are not certain.
If you recall I pushed for 'dual compile' for the last several years and
only now we found time to work on it.
Powered by blists - more mailing lists