| Message ID | 20230614111752.74207e28@canb.auug.org.au (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | linux-next: manual merge of the net-next tree with the net tree | expand |
| Context | Check | Description |
|---|---|---|
| netdev/tree_selection | success | Not a local patch |
Hi Stephen, On 14/06/2023 03:17, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the net-next tree got a conflict in: > > tools/testing/selftests/net/mptcp/mptcp_join.sh > > between commits: > > 47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported") > 425ba803124b ("selftests: mptcp: join: support RM_ADDR for used endpoints or not") > > from the net tree and commits: > > 45b1a1227a7a ("mptcp: introduces more address related mibs") > 0639fa230a21 ("selftests: mptcp: add explicit check for new mibs") > > from the net-next tree. > > I fixed it up (I think - see below) and can carry the fix as necessary. > This is now fixed as far as linux-next is concerned, but any non trivial > conflicts should be mentioned to your upstream maintainer when your tree > is submitted for merging. You may also want to consider cooperating > with the maintainer of the conflicting tree to minimise any particularly > complex conflicts. Thank you for the conflicts resolution. If I'm not mistaken, it looks good except the last chunk where the new call to chk_rm_tx_nr() should go inside the 'if' statement. So instead of this bit you have on your side: > @@@ -2394,12 -2290,8 +2399,13 @@@ remove_tests( > pm_nl_add_endpoint $ns2 10.0.4.2 flags subflow > run_tests $ns1 $ns2 10.0.1.1 0 -8 -8 slow > chk_join_nr 3 3 3 > + chk_rm_tx_nr 0 > - chk_rm_nr 0 3 simult > + > + if mptcp_lib_kversion_ge 5.18; then > + chk_rm_nr 0 3 simult > + else > + chk_rm_nr 3 3 > + fi > fi > > # addresses flush We should have: > @@@ -2394,12 -2290,8 +2399,13 @@@ remove_tests( > pm_nl_add_endpoint $ns2 10.0.4.2 flags subflow > run_tests $ns1 $ns2 10.0.1.1 0 -8 -8 slow > chk_join_nr 3 3 3 > - chk_rm_tx_nr 0 > - chk_rm_nr 0 3 simult > + > + if mptcp_lib_kversion_ge 5.18; then > ++ chk_rm_tx_nr 0 > + chk_rm_nr 0 3 simult > + else > + chk_rm_nr 3 3 > + fi > fi > > # addresses flush ("chk_rm_tx_nr 0" needs to be inside the 'if') I added a note about the conflicts on the cover-letter: https://lore.kernel.org/netdev/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@tessares.net/ Maybe it was not a good place? I didn't know where to put it as there were multiple patches that were conflicting with each others even if the major conflicts were between 47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported") and 0639fa230a21 ("selftests: mptcp: add explicit check for new mibs"). I guess next time I should add a comment referring to the cover-letter in the patches creating conflicts. Cheers, Matt
Hi Matthieu, On Wed, 14 Jun 2023 10:51:16 +0200 Matthieu Baerts <matthieu.baerts@tessares.net> wrote: > > Thank you for the conflicts resolution. If I'm not mistaken, it looks > good except the last chunk where the new call to chk_rm_tx_nr() should > go inside the 'if' statement. So instead of this bit you have on your side: Thanks for checking this. I will amend my resolution in linux-next from tomorrow.
On Wed, 14 Jun 2023 10:51:16 +0200 Matthieu Baerts wrote: > I added a note about the conflicts on the cover-letter: > > https://lore.kernel.org/netdev/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@tessares.net/ > > Maybe it was not a good place? I didn't know where to put it as there > were multiple patches that were conflicting with each others even if the > major conflicts were between 47867f0a7e83 ("selftests: mptcp: join: skip > check if MIB counter not supported") and 0639fa230a21 ("selftests: > mptcp: add explicit check for new mibs"). I guess next time I should add > a comment referring to the cover-letter in the patches creating conflicts. Hm, yeah, I think the cover letter may not be the best way. Looks like Stephen didn't use it, anyway, and it confused patchwork. No better idea where to put it tho :( Maybe a link to a git rerere resolution uploaded somewhere we can wget from easily?
Hi Jakub, On 14/06/2023 19:41, Jakub Kicinski wrote: > On Wed, 14 Jun 2023 10:51:16 +0200 Matthieu Baerts wrote: >> I added a note about the conflicts on the cover-letter: >> >> https://lore.kernel.org/netdev/20230609-upstream-net-20230610-mptcp-selftests-support-old-kernels-part-3-v1-0-2896fe2ee8a3@tessares.net/ >> >> Maybe it was not a good place? I didn't know where to put it as there >> were multiple patches that were conflicting with each others even if the >> major conflicts were between 47867f0a7e83 ("selftests: mptcp: join: skip >> check if MIB counter not supported") and 0639fa230a21 ("selftests: >> mptcp: add explicit check for new mibs"). I guess next time I should add >> a comment referring to the cover-letter in the patches creating conflicts. > > Hm, yeah, I think the cover letter may not be the best way. > Looks like Stephen didn't use it, anyway, and it confused patchwork. > No better idea where to put it tho :( > > Maybe a link to a git rerere resolution uploaded somewhere we can wget > from easily? Good idea, I didn't think about git rerere! I will try to remember about that next time :) Cheers, Matt
diff --cc tools/testing/selftests/net/mptcp/mptcp_join.sh index 0ae8cafde439,85474e029784..000000000000 --- a/tools/testing/selftests/net/mptcp/mptcp_join.sh
Hi all, Today's linux-next merge of the net-next tree got a conflict in: tools/testing/selftests/net/mptcp/mptcp_join.sh between commits: 47867f0a7e83 ("selftests: mptcp: join: skip check if MIB counter not supported") 425ba803124b ("selftests: mptcp: join: support RM_ADDR for used endpoints or not") from the net tree and commits: 45b1a1227a7a ("mptcp: introduces more address related mibs") 0639fa230a21 ("selftests: mptcp: add explicit check for new mibs") from the net-next tree. I fixed it up (I think - see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts.