linux-kernel - The future of kernel-patches-daemon

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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z_6bxZUiodrE45HJ@bombadil.infradead.org>
Date: Tue, 15 Apr 2025 10:47:49 -0700
From: Luis Chamberlain <mcgrof@...nel.org>
To: Song Liu <song@...nel.org>
Cc: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kdevops@...ts.linux.dev, Jim Zemlin <jzemlin@...ux-foundation.org>,
	Konstantin Ryabitsev <mricon@...nel.org>,
	Javier González <javier.gonz@...sung.com>,
	Greg Marsden <greg.marsden@...cle.com>, Tso Ted <tytso@....edu>,
	Gustavo Padovan <gus@...labora.com>,
	Alexei Starovoitov <ast@...nel.org>,
	Daniel Borkmann <daniel@...earbox.net>
Subject: The future of kernel-patches-daemon - folding under LF?

Song,

We're starting to rely on kernel-patches-deamon (kpd in short) [0] for quite a
bit of  linux-kernel subsystems and have integrated it on kdevops for them [1]
[2]. We already use it for the modules subsystem but even then that runs into
hiccups every now and then and we just have to restart it. For smaller
subsystems we've started to experiment with lei based patchwork solutions, we
started with the firmware loader, and the hope was that if that works we could
move on to memory management to leverage the automation of tests we have for
xarray, maple tree, and vmas. The lei patchwork instance which kernel.org admins
have helped us with works well, however kpd doesn't yet work with it [3], so we
can't even get that off the ground yet. In the meantime, we've been instead
relying on linux-next tags to test other subsystems like memory management so we
avoid regressions that way, instead of testing patches while on the mailing
list. But we do want to get to the point we can test things proactively for
different subsystems.

While we could look for alternatives I think we need to face the fact that we
need more kpd love. I'm convinced that the only way to scale Linux kernel-ci
work is by dividing and conquering and those can contribute to different
components do so, and kpd fits well right in, but I think we need to start
thinking about scaling it beyond just Meta. While we could just try to
contribute to it to fix lingering bugs I've noted my first issue with it,
requring CLA [4], and I don't think it makes sense to fork it from Meta. kpd the
sort of specialized daemon that also can take time to learn and believe at this
point it might make sense if kpd can be part of the LF covered toolbox we can
get support for. Ie, make it an LF project and see if we can get more help with
the sort of pipelines that fit both Meta and the kernel community.

Let me know your thoughts.

[0] https://github.com/facebookincubator/kernel-patches-daemon
[1] https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/README.md
[2] https://github.com/linux-kdevops/kdevops/blob/main/docs/kernel-ci/kernel-ci-kpd.md
[3] https://lkml.kernel.org/r/CAB=NE6X5mJJmcXjEkHyE=2f1CCA5fDDEjMFH_aMArrhom2qO8Q@mail.gmail.com
[4] https://github.com/facebookincubator/kernel-patches-daemon/issues/62

  Luis