netdev - On the NACKs on P4TC patches

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAM0EoMmsB5jHZ=4oJc_Yzm=RFDUHWh9yexdG6_bPFS4_CFuiog@mail.gmail.com>
Date: Tue, 21 May 2024 08:35:07 -0400
From: Jamal Hadi Salim <jhs@...atatu.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Alexei Starovoitov <alexei.starovoitov@...il.com>, 
	Network Development <netdev@...r.kernel.org>, "Chatterjee, Deb" <deb.chatterjee@...el.com>, 
	Anjali Singhai Jain <anjali.singhai@...el.com>, "Limaye, Namrata" <namrata.limaye@...el.com>, 
	tom Herbert <tom@...anda.io>, Marcelo Ricardo Leitner <mleitner@...hat.com>, 
	"Shirshyad, Mahesh" <Mahesh.Shirshyad@....com>, "Osinski, Tomasz" <tomasz.osinski@...el.com>, 
	Jiri Pirko <jiri@...nulli.us>, Cong Wang <xiyou.wangcong@...il.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Vlad Buslov <vladbu@...dia.com>, Simon Horman <horms@...nel.org>, 
	Khalid Manaa <khalidm@...dia.com>, Toke Høiland-Jørgensen <toke@...hat.com>, 
	Victor Nogueira <victor@...atatu.com>, Pedro Tammela <pctammela@...atatu.com>, 
	"Jain, Vipin" <Vipin.Jain@....com>, "Daly, Dan" <dan.daly@...el.com>, 
	Andy Fingerhut <andy.fingerhut@...il.com>, Chris Sommers <chris.sommers@...sight.com>, 
	Matty Kadosh <mattyk@...dia.com>, bpf <bpf@...r.kernel.org>, lwn@....net
Subject: On the NACKs on P4TC patches

As stated a few times, we strongly disagree with the nature of the
Nacks from Alexei, Daniel and John. We dont think there is good ground
for the Nacks.

A brief history on the P4TC patches:

We posted V1 in January 2023. The main objection then was that we
needed to use eBPF. After some discussion and investigation on our
part we found that using kfuncs would satisfy our goals as well as the
objections raised. We posted 28 RFC patches looking for feedback from
eBPF and other folks with V2 in May 2023 - these patches were not
ready but we were nevertheless soliciting for feedback. By Version 7
in October/2023 we removed the RFC tag (meaning we are asking for
inclusion). In Version 8 we sent the first 15 patches as series
1(following netdev rules that allow only 15 patches); 5 of these
patches are trivial tc core patches. Starting with V8 and upto V14 the
releases were mostly suggested changes (much thanks to folks who made
suggestions for technical changes) and at one point it was a bug fix
for an issue caught by our syzkaller instance.

When it seemed like Paolo was heading towards applying series 1 given
the feedback, Alexei nacked patch 14 when we released V14, see:
https://lore.kernel.org/bpf/20240404122338.372945-5-jhs@mojatatu.com/
V15 only change was adding Alexei's nack. V15 was followed by Daniel
and then John also nacking the same patch 14. V16's only change was to
add these extra Nacks.

At that point(v16) i asked for the series to be applied despite the
Nacks because, frankly, the Nacks have no merit. Paolo was not
comfortable applying patches with Nacks and tried to mediate. In his
mediation effort he asked if we could remove eBPF - and our answer was
no because after all that time we have become dependent on it and
frankly there was no technical reason not to use eBPF. Paolo then
asked if we could satisfy one of the points Alexei raised in terms of
clearing table entries when an eBPF program was unloaded. We spent a
week investigating and came to a conclusion that we could do it as a
compromise (even though it is not something fitting to our
requirements and there is existing code that we copied from doing
exactly what Alexei is objecting to). Alexei rejected this offer. This
puts Paolo in a difficult position because it is clear there is no
compromise to be had. I feel we are in uncharted teritory.

Since we are in a quagmire, I am asking for a third party mediator to
review the objections and validate if they have merit.
I have created a web page to capture all the objections raised by the
3 gents over a period of time at:
https://github.com/p4tc-dev/pushback-patches
If any of the 3 people feel i have misrepresented their objections or
missed an important detail please let me know and i will fix the page.

cheers,
jamal