linux-kernel - Re: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CAPhsuW5HYYvGoFO2L81EBkHDmozxxjpmdRh+GPrAxea-+91YNQ@mail.gmail.com>
Date: Wed, 16 Apr 2025 22:28:06 -0700
From: Song Liu <song@...nel.org>
To: Luis Chamberlain <mcgrof@...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: Re: The future of kernel-patches-daemon - folding under LF?

Hi Luis,

How about we discuss different options over a video conference?
We have a BPF office hour scheduled every Thursday at 9am PST.
Would this time work for folks?

Thanks,
Song


On Tue, Apr 15, 2025 at 10:47 AM Luis Chamberlain <mcgrof@...nel.org> wrote:
>
> 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