On Fri, Jul 24, 2020 at 6:38 AM Willem de Bruijn <willemdebruijn.ker...@gmail.com> wrote: > > On Fri, Jul 24, 2020 at 2:13 AM Kuniyuki Iwashima <kun...@amazon.co.jp> wrote: > > > > From: David Miller <da...@davemloft.net> > > Date: Thu, 23 Jul 2020 15:10:51 -0700 (PDT) > > > From: Kuniyuki Iwashima <kun...@amazon.co.jp> > > > Date: Thu, 23 Jul 2020 01:52:27 +0900 > > > > > > > This patch removes an unnecessary variable in udp[46]_lib_lookup2() and > > > > makes it easier to resolve a merge conflict with bpf-next reported in > > > > the link below. > > > > > > > > Link: > > > > https://lore.kernel.org/linux-next/20200722132143.700a5...@canb.auug.org.au/ > > > > Fixes: efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.") > > > > Signed-off-by: Kuniyuki Iwashima <kun...@amazon.co.jp> > > > > Signed-off-by: Jakub Sitnicki <ja...@cloudflare.com> > > > > Cc: Willem de Bruijn <willemdebruijn.ker...@gmail.com> > > > > > > This doesn't apply to net-next. > > > > Yes. I think this kind of patch should be submitted to net-next, but this > > is for the net tree. Please let me add more description. > > > > Currently, the net and net-next trees conflict in udp[46]_lib_lookup2() > > between > > > > efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.") > > > > and > > > > 7629c73a1466 ("udp: Extract helper for selecting socket from reuseport > > group") > > 2a08748cd384 ("udp6: Extract helper for selecting socket from reuseport > > group") > > . > > > > The conflict is reported in the link[0] and Jakub suggested how to resolve > > it[1]. To ease the merge conflict, Jakub and I have to send follow up > > patches to > > the bpf-next and net trees. > > > > Now, his patchset (7629c73a1466 and 2a08748cd384) to bpf-next is merged > > into net-next, and his follow up patch is applied in bpf-next[2]. > > > > I fixed a bug in efc6b6f6c311, but it introduced an unnecessary variable > > and made the conflict worse. So I sent this follow up patch to net tree. > > > > However, I do not know the best way to resolve the conflict, so any comments > > are welcome. > > Perhaps simpler is to apply this change to bpf-next:
I'm fine whichever way. Could you please submit an official patch?
