Hi Daniel, On Fri, Aug 23, 2024 at 11:57:06PM GMT, Daniel Xu wrote: [...] > > On Fri, Aug 23, 2024 at 01:53:48AM GMT, bot+bpf-ci@xxxxxxxxxx wrote: > > [...] > >> CI has tested the following submission: > >> Status: CONFLICT > >> Name: [stable,6.6,2/2] selftests/bpf: Add a test to verify previous stacksafe() fix > >> Patchwork: https://patchwork.kernel.org/project/netdevbpf/list/?series=882411&state=* > >> PR: https://github.com/kernel-patches/bpf/pull/7584 > >> > >> Please rebase your submission onto the most recent upstream change and resubmit > >> the patch to get it tested again. > > > > It seems the BPF CI picks up stable patches and tries to apply it on top > > of bpf-next, which fails to due conflict. Could a filter be added to CI > > so these are ignored instead? (Or have BPF CI apply and test against > > stable/linux-*, but that seems too much to ask) > > > > OTOH if maintainers and reviewers prefers stable backport not to be sent > > to the BPF mailing list, I will drop the CC to BPF mailing list in the > > future. > > [...] > > Thanks for reporting. > > The way kernel-patches-daemon (KPD) works is it periodically looks on > patchwork for patchsets delegated to BPF tree. If there's a specific tag > (bpf, bpf-next, bpf-net, for-next) it'll apply the series to that > branch. If not, there's an ordered list of branches to try. bpf-next is > first on that list which is why you're seeing the conflicts. > > From KPD side, the simplest way would be to not have backports show > up on patchwork. I think it makes sense - it is not really being sent > for review. > > We could probably add additional logic to ignore stable backports as > well. Up to the maintainers. I don't really have an opinion. Thanks for the explanations. I didn't realize that patchwork was involved. Seems like the best action for now is to drop BPF mailing list when sending stable backports, this also avoids cluttering Netdev + BPF patchwork and keep it development focused. (I think backports still need reviewing, but that's probably a different discussion) Shung-Hsi
