April 16, 2025 at 01:37, "Ihor Solodrai" <ihor.solodrai@xxxxxxxxx> wrote: > > On 4/15/25 10:05 AM, Alexei Starovoitov wrote: > > > > > On Tue, Apr 15, 2025 at 10:01 AM Ihor Solodrai <ihor.solodrai@xxxxxxxxx> wrote: > > > > > > > > On 4/15/25 9:53 AM, Jiayuan Chen wrote: > > > > > > > April 16, 2025 at 24:33, "Ihor Solodrai" <ihor.solodrai@xxxxxxxxx> wrote: > > > > "sockmap_ktls disconnect_after_delete" test has been failing on BPF CI > > > > after recent merges from netdev: > > > > * https://github.com/kernel-patches/bpf/actions/runs/14458537639 > > > > * https://github.com/kernel-patches/bpf/actions/runs/14457178732 > > > > It happens because disconnect has been disabled for TLS [1], and it > > > > renders the test case invalid. Remove it from the suite. > > > > [1] https://lore.kernel.org/netdev/20250404180334.3224206-1-kuba@xxxxxxxxxx/ > > > > Signed-off-by: Ihor Solodrai <ihor.solodrai@xxxxxxxxx> > > > > Reviewed-by: Jiayuan Chen <jiayuan.chen@xxxxxxxxx> > > > > The original selftest patch used disconnect to re-produce the endless > > loop caused by tcp_bpf_unhash, which has already been removed. > > I hope this doesn't conflict with bpf-next... > > > > > > > > I just tried applying to bpf-next, and it does indeed have a > > > conflict... Although kdiff3 merged it automatically. > > > What's the right way to resolve this? Send for bpf-next? > > > > > What commit in bpf-next does it conflict with ? > > In general, avoiding merge conflicts is preferred. > > > https://web.git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/commit/?id=05ebde1bcb50a71cd56d8edd3008f53a781146e9 > https://lore.kernel.org/bpf/20250219052015.274405-1-jiayuan.chen@xxxxxxxxx/ > It adds tests in the same file. The code to delete simply moved. > I think we can avoid conflict by applying 05ebde1bcb50 to bpf first, > if that's an option (it might depend on other changes, idk). > Then the version of the patch for bpf-next would apply to both trees. > If not, then apply only to bpf-next, and disable the test on CI? > I'm not sure whether we can cherry-pick the commit to bpf branch. I believe it would be more convenient for the maintainer to merge the patch that only removes 'ASSERT_OK(err, "disconnect");', as this change will not introduce conflicts with the bpf-next branch. Once the bpf branch is merged into bpf-next, you can then remove the entire function in the bpf-next branch.