linux-next: manual merge of the bpf-next tree with the net tree

linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4501 bytes --]

Hi all,

Today's linux-next merge of the bpf-next tree got a conflict in:

  tools/lib/bpf/Makefile

between commit:

  1bd63524593b ("libbpf: handle symbol versioning properly for libbpf.a")

from the net tree and commits:

  5c26f9a78358 ("libbpf: Don't use cxx to test_libpf target")
  793a349cd819 ("libbpf: Add C/LDFLAGS to libbpf.so and test_libpf targets")

from the bpf-next tree.

I fixed it up (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.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/lib/bpf/Makefile
index 56ce6292071b,75b538577c17..000000000000
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@@ -143,7 -133,9 +143,9 @@@ LIB_TARGET	:= $(addprefix $(OUTPUT),$(L
  LIB_FILE	:= $(addprefix $(OUTPUT),$(LIB_FILE))
  PC_FILE		:= $(addprefix $(OUTPUT),$(PC_FILE))
  
+ TAGS_PROG := $(if $(shell which etags 2>/dev/null),etags,ctags)
+ 
 -GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
 +GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
  			   cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
  			   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
  			   sort -u | wc -l)
@@@ -165,7 -149,7 +159,7 @@@ all: fixde
  
  all_cmd: $(CMD_TARGETS) check
  
- $(BPF_IN_SHARED): force elfdep bpfdep
 -$(BPF_IN): force elfdep bpfdep bpf_helper_defs.h
++$(BPF_IN_SHARED): force elfdep bpfdep bpf_helper_defs.h
  	@(test -f ../../include/uapi/linux/bpf.h -a -f ../../../include/uapi/linux/bpf.h && ( \
  	(diff -B ../../include/uapi/linux/bpf.h ../../../include/uapi/linux/bpf.h >/dev/null) || \
  	echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from latest version at 'include/uapi/linux/bpf.h'" >&2 )) || true
@@@ -181,24 -165,26 +175,29 @@@
  	@(test -f ../../include/uapi/linux/if_xdp.h -a -f ../../../include/uapi/linux/if_xdp.h && ( \
  	(diff -B ../../include/uapi/linux/if_xdp.h ../../../include/uapi/linux/if_xdp.h >/dev/null) || \
  	echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h' differs from latest version at 'include/uapi/linux/if_xdp.h'" >&2 )) || true
 -	$(Q)$(MAKE) $(build)=libbpf
 +	$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(SHARED_OBJDIR) CFLAGS="$(CFLAGS) $(SHLIB_FLAGS)"
 +
 +$(BPF_IN_STATIC): force elfdep bpfdep
 +	$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(STATIC_OBJDIR)
  
+ bpf_helper_defs.h: $(srctree)/include/uapi/linux/bpf.h
+ 	$(Q)$(srctree)/scripts/bpf_helpers_doc.py --header 		\
+ 		--file $(srctree)/include/uapi/linux/bpf.h > bpf_helper_defs.h
+ 
  $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION)
  
 -$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN)
 +$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN_SHARED)
- 	$(QUIET_LINK)$(CC) --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
- 				    -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
+ 	$(QUIET_LINK)$(CC) $(LDFLAGS) \
+ 		--shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
+ 		-Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
  	@ln -sf $(@F) $(OUTPUT)libbpf.so
  	@ln -sf $(@F) $(OUTPUT)libbpf.so.$(LIBBPF_MAJOR_VERSION)
  
 -$(OUTPUT)libbpf.a: $(BPF_IN)
 +$(OUTPUT)libbpf.a: $(BPF_IN_STATIC)
  	$(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^
  
- $(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a
- 	$(QUIET_LINK)$(CXX) $(INCLUDES) $^ -lelf -o $@
+ $(OUTPUT)test_libbpf: test_libbpf.c $(OUTPUT)libbpf.a
+ 	$(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $(INCLUDES) $^ -lelf -o $@
  
  $(OUTPUT)libbpf.pc:
  	$(QUIET_GEN)sed -e "s|@PREFIX@|$(prefix)|" \
@@@ -268,9 -259,9 +272,10 @@@ config-clean
  	$(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
  
  clean:
- 	$(call QUIET_CLEAN, libbpf) $(RM) -rf $(TARGETS) $(CXX_TEST_TARGET) \
 -	$(call QUIET_CLEAN, libbpf) $(RM) $(CMD_TARGETS) \
++	$(call QUIET_CLEAN, libbpf) $(RM) -rf $(CMD_TARGETS) \
  		*.o *~ *.a *.so *.so.$(LIBBPF_MAJOR_VERSION) .*.d .*.cmd \
- 		*.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR)
 -		*.pc LIBBPF-CFLAGS bpf_helper_defs.h
++		*.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR) \
++		bpf_helper_defs.h
  	$(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
  
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 4889 bytes --]

Hi all,

This is now a conflict between the net and net-next trees.

On Mon, 14 Oct 2019 10:32:32 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/lib/bpf/Makefile
> 
> between commit:
> 
>   1bd63524593b ("libbpf: handle symbol versioning properly for libbpf.a")
> 
> from the net tree and commits:
> 
>   5c26f9a78358 ("libbpf: Don't use cxx to test_libpf target")
>   793a349cd819 ("libbpf: Add C/LDFLAGS to libbpf.so and test_libpf targets")
> 
> from the bpf-next tree.
> 
> I fixed it up (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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc tools/lib/bpf/Makefile
> index 56ce6292071b,75b538577c17..000000000000
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@@ -143,7 -133,9 +143,9 @@@ LIB_TARGET	:= $(addprefix $(OUTPUT),$(L
>   LIB_FILE	:= $(addprefix $(OUTPUT),$(LIB_FILE))
>   PC_FILE		:= $(addprefix $(OUTPUT),$(PC_FILE))
>   
> + TAGS_PROG := $(if $(shell which etags 2>/dev/null),etags,ctags)
> + 
>  -GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
>  +GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN_SHARED) | \
>   			   cut -d "@" -f1 | sed 's/_v[0-9]_[0-9]_[0-9].*//' | \
>   			   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {print $$8}' | \
>   			   sort -u | wc -l)
> @@@ -165,7 -149,7 +159,7 @@@ all: fixde
>   
>   all_cmd: $(CMD_TARGETS) check
>   
> - $(BPF_IN_SHARED): force elfdep bpfdep
>  -$(BPF_IN): force elfdep bpfdep bpf_helper_defs.h
> ++$(BPF_IN_SHARED): force elfdep bpfdep bpf_helper_defs.h
>   	@(test -f ../../include/uapi/linux/bpf.h -a -f ../../../include/uapi/linux/bpf.h && ( \
>   	(diff -B ../../include/uapi/linux/bpf.h ../../../include/uapi/linux/bpf.h >/dev/null) || \
>   	echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/bpf.h' differs from latest version at 'include/uapi/linux/bpf.h'" >&2 )) || true
> @@@ -181,24 -165,26 +175,29 @@@
>   	@(test -f ../../include/uapi/linux/if_xdp.h -a -f ../../../include/uapi/linux/if_xdp.h && ( \
>   	(diff -B ../../include/uapi/linux/if_xdp.h ../../../include/uapi/linux/if_xdp.h >/dev/null) || \
>   	echo "Warning: Kernel ABI header at 'tools/include/uapi/linux/if_xdp.h' differs from latest version at 'include/uapi/linux/if_xdp.h'" >&2 )) || true
>  -	$(Q)$(MAKE) $(build)=libbpf
>  +	$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(SHARED_OBJDIR) CFLAGS="$(CFLAGS) $(SHLIB_FLAGS)"
>  +
>  +$(BPF_IN_STATIC): force elfdep bpfdep
>  +	$(Q)$(MAKE) $(build)=libbpf OUTPUT=$(STATIC_OBJDIR)
>   
> + bpf_helper_defs.h: $(srctree)/include/uapi/linux/bpf.h
> + 	$(Q)$(srctree)/scripts/bpf_helpers_doc.py --header 		\
> + 		--file $(srctree)/include/uapi/linux/bpf.h > bpf_helper_defs.h
> + 
>   $(OUTPUT)libbpf.so: $(OUTPUT)libbpf.so.$(LIBBPF_VERSION)
>   
>  -$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN)
>  +$(OUTPUT)libbpf.so.$(LIBBPF_VERSION): $(BPF_IN_SHARED)
> - 	$(QUIET_LINK)$(CC) --shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
> - 				    -Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
> + 	$(QUIET_LINK)$(CC) $(LDFLAGS) \
> + 		--shared -Wl,-soname,libbpf.so.$(LIBBPF_MAJOR_VERSION) \
> + 		-Wl,--version-script=$(VERSION_SCRIPT) $^ -lelf -o $@
>   	@ln -sf $(@F) $(OUTPUT)libbpf.so
>   	@ln -sf $(@F) $(OUTPUT)libbpf.so.$(LIBBPF_MAJOR_VERSION)
>   
>  -$(OUTPUT)libbpf.a: $(BPF_IN)
>  +$(OUTPUT)libbpf.a: $(BPF_IN_STATIC)
>   	$(QUIET_LINK)$(RM) $@; $(AR) rcs $@ $^
>   
> - $(OUTPUT)test_libbpf: test_libbpf.cpp $(OUTPUT)libbpf.a
> - 	$(QUIET_LINK)$(CXX) $(INCLUDES) $^ -lelf -o $@
> + $(OUTPUT)test_libbpf: test_libbpf.c $(OUTPUT)libbpf.a
> + 	$(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) $(INCLUDES) $^ -lelf -o $@
>   
>   $(OUTPUT)libbpf.pc:
>   	$(QUIET_GEN)sed -e "s|@PREFIX@|$(prefix)|" \
> @@@ -268,9 -259,9 +272,10 @@@ config-clean
>   	$(Q)$(MAKE) -C $(srctree)/tools/build/feature/ clean >/dev/null
>   
>   clean:
> - 	$(call QUIET_CLEAN, libbpf) $(RM) -rf $(TARGETS) $(CXX_TEST_TARGET) \
>  -	$(call QUIET_CLEAN, libbpf) $(RM) $(CMD_TARGETS) \
> ++	$(call QUIET_CLEAN, libbpf) $(RM) -rf $(CMD_TARGETS) \
>   		*.o *~ *.a *.so *.so.$(LIBBPF_MAJOR_VERSION) .*.d .*.cmd \
> - 		*.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR)
>  -		*.pc LIBBPF-CFLAGS bpf_helper_defs.h
> ++		*.pc LIBBPF-CFLAGS $(SHARED_OBJDIR) $(STATIC_OBJDIR) \
> ++		bpf_helper_defs.h
>   	$(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
>   
>   

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Alexei Starovoitov]

On Wed, Mar 27, 2024 at 6:55 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got a conflict in:
>
>   kernel/bpf/arena.c
>
> between commit:
>
>   ee498a38f317 ("bpf: Clarify bpf_arena comments.")
>
> from the net tree and commit:
>
>   45a683b2d815 ("bpf,arena: Use helper sizeof_field in struct accessors")
>
> from the bpf-next tree.
>
> I fixed it up (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.

Thanks for headsup.
We'll fix it up when bpf-next gets ffwded in a day or two.

linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

Hi all,

Today's linux-next merge of the bpf-next tree got a conflict in:

  kernel/bpf/arena.c

between commit:

  ee498a38f317 ("bpf: Clarify bpf_arena comments.")

from the net tree and commit:

  45a683b2d815 ("bpf,arena: Use helper sizeof_field in struct accessors")

from the bpf-next tree.

I fixed it up (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.

-- 
Cheers,
Stephen Rothwell

diff --cc kernel/bpf/arena.c
index 343c3456c8dd,af5cae640669..000000000000
--- a/kernel/bpf/arena.c
+++ b/kernel/bpf/arena.c
@@@ -37,8 -37,8 +37,8 @@@
   */
  
  /* number of bytes addressable by LDX/STX insn with 16-bit 'off' field */
- #define GUARD_SZ (1ull << sizeof(((struct bpf_insn *)0)->off) * 8)
+ #define GUARD_SZ (1ull << sizeof_field(struct bpf_insn, off) * 8)
 -#define KERN_VM_SZ ((1ull << 32) + GUARD_SZ)
 +#define KERN_VM_SZ (SZ_4G + GUARD_SZ)
  
  struct bpf_arena {
  	struct bpf_map map;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

Hi all,

Today's linux-next merge of the bpf-next tree got a conflict in:

  include/linux/bpf.h

between commit:

  1f6e04a1c7b8 ("bpf: Fix offset calculation error in __copy_map_value and zero_map_value")

from the net tree and commit:

  e5feed0f64f7 ("bpf: Fix copy_map_value, zero_map_value")

from the bpf-next tree.

I fixed it up (I just used the latter) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

Hi all,

Today's linux-next merge of the bpf-next tree got a conflict in:

  tools/testing/selftests/bpf/DENYLIST.s390x

between commit:

  27e23836ce22 ("selftests/bpf: Add lru_bug to s390x deny list")

from the net tree and commit:

  1c636b6277a2 ("selftests/bpf: Add test cases for htab update")

from the bpf-next tree.

I fixed it up (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.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/testing/selftests/bpf/DENYLIST.s390x
index 5cadfbdadf36,ba02b559ca68..000000000000
--- a/tools/testing/selftests/bpf/DENYLIST.s390x
+++ b/tools/testing/selftests/bpf/DENYLIST.s390x
@@@ -65,4 -65,7 +65,8 @@@ send_signa
  select_reuseport                         # intermittently fails on new s390x setup
  xdp_synproxy                             # JIT does not support calling kernel function                                (kfunc)
  unpriv_bpf_disabled                      # fentry
 +lru_bug                                  # prog 'printk': failed to auto-attach: -524
+ setget_sockopt                           # attach unexpected error: -524                                               (trampoline)
+ cb_refs                                  # expected error message unexpected error: -524                               (trampoline)
+ cgroup_hierarchical_stats                # JIT does not support calling kernel function                                (kfunc)
+ htab_update                              # failed to attach: ERROR: strerror_r(-524)=22                                (trampoline)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 795 bytes --]

Hi all,

Today's linux-next merge of the bpf-next tree got a conflict in:

  net/core/filter.c

between commit:

  1227c1771dd2 ("net: Fix data-races around sysctl_[rw]mem_(max|default).")

from the net tree and commit:

  29003875bd5b ("bpf: Change bpf_setsockopt(SOL_SOCKET) to reuse sk_setsockopt()")

from the bpf-next tree.

I fixed it up (I dropped the former patches changes to this file) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

Hi all,

On Wed, 22 Jul 2020 13:21:43 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the bpf-next tree got conflicts in:
> 
>   net/ipv4/udp.c
>   net/ipv6/udp.c
> 
> between commit:
> 
>   efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.")
> 
> from the net tree and commits:
> 
>   7629c73a1466 ("udp: Extract helper for selecting socket from reuseport group")
>   2a08748cd384 ("udp6: Extract helper for selecting socket from reuseport group")
> 
> from the bpf-next tree.
> 
> I fixed it up (I wasn't sure how to proceed, so I used the latter
> version) 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.

This is now a conflict between the net-next and net trees.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Alexei Starovoitov]

On Wed, Jul 22, 2020 at 8:50 AM Willem de Bruijn
<willemdebruijn.kernel@gmail.com> wrote:
>
> > TBH, I don't what is the preferred way to handle it. Perhaps DaveM or
> > Alexei/Daniel can say what would make their life easiest?
>
> Good point.
>
> With the above, there still remains a merge conflict, of course. But
> then we can take bpf-next as is, so I think it would save a separate
> patch to net. But not sure whether that helps anything. It does add an
> unnecessary variable.

whichever way is easier to deal with merge conflict....
currently bpf-next PR is pending.
but we can drop it and merge one more patch into bpf-next?
But reading through the read it doesn't sound that it will help the
merge conflict..
An alternative could be to drop PR and rebase the whole bpf-next to net-next
and deal with conflicts there...
Or I can rebase bpf-next and drop Jakub's series and he can resubmit them
without conflicts? I guess that's the easiest for me and for Dave.

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Willem de Bruijn]

On Wed, Jul 22, 2020 at 11:25 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>
> On Wed, Jul 22, 2020 at 05:05 PM CEST, Willem de Bruijn wrote:
> > On Wed, Jul 22, 2020 at 11:02 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
> >>
> >> On Wed, Jul 22, 2020 at 04:42 PM CEST, Kuniyuki Iwashima wrote:
> >> > Can I submit a patch to net tree that rewrites udp[46]_lib_lookup2() to
> >> > use only 'result' ?
> >>
> >> Feel free. That should make the conflict resolution even easier later
> >> on.
> >
> > Thanks for the detailed analysis, Jakub.
> >
> > Would it be easier to fix this wholly in bpf-next, by introducing
> > reuseport_result there?
>
> Did you mean replicating the Kuniyuki fix in bpf-next, or just
> introducing the intermediate 'reuseport_result' var?
>
> I'm assuming the former, so that the conflict resolving later on will
> reduce to selecting everything from bpf-next side.

Indeed. Since you are already adding a patch to bpf-next to move the
reuseport_has_conns check back. At the same time, it can introduce
reuseport_result:

                if (score > badness) {
                        reuseport_result = lookup_reuseport(net, sk,
skb, saddr, sport, daddr, hnum);
                        if (reuseport_result && !reuseport_has_conns(sk, false))
                                return reuseport_result;

                        result = reuseport_result ? : sk;
                        badness = score;
                }

> TBH, I don't what is the preferred way to handle it. Perhaps DaveM or
> Alexei/Daniel can say what would make their life easiest?

Good point.

With the above, there still remains a merge conflict, of course. But
then we can take bpf-next as is, so I think it would save a separate
patch to net. But not sure whether that helps anything. It does add an
unnecessary variable.

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Jakub Sitnicki]

On Wed, Jul 22, 2020 at 05:05 PM CEST, Willem de Bruijn wrote:
> On Wed, Jul 22, 2020 at 11:02 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>>
>> On Wed, Jul 22, 2020 at 04:42 PM CEST, Kuniyuki Iwashima wrote:
>> > Can I submit a patch to net tree that rewrites udp[46]_lib_lookup2() to
>> > use only 'result' ?
>>
>> Feel free. That should make the conflict resolution even easier later
>> on.
>
> Thanks for the detailed analysis, Jakub.
>
> Would it be easier to fix this wholly in bpf-next, by introducing
> reuseport_result there?

Did you mean replicating the Kuniyuki fix in bpf-next, or just
introducing the intermediate 'reuseport_result' var?

I'm assuming the former, so that the conflict resolving later on will
reduce to selecting everything from bpf-next side.

TBH, I don't what is the preferred way to handle it. Perhaps DaveM or
Alexei/Daniel can say what would make their life easiest?

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Willem de Bruijn]

On Wed, Jul 22, 2020 at 11:02 AM Jakub Sitnicki <jakub@cloudflare.com> wrote:
>
> On Wed, Jul 22, 2020 at 04:42 PM CEST, Kuniyuki Iwashima wrote:
> > Can I submit a patch to net tree that rewrites udp[46]_lib_lookup2() to
> > use only 'result' ?
>
> Feel free. That should make the conflict resolution even easier later
> on.

Thanks for the detailed analysis, Jakub.

Would it be easier to fix this wholly in bpf-next, by introducing
reuseport_result there?

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Jakub Sitnicki]

On Wed, Jul 22, 2020 at 04:42 PM CEST, Kuniyuki Iwashima wrote:
> Can I submit a patch to net tree that rewrites udp[46]_lib_lookup2() to
> use only 'result' ?

Feel free. That should make the conflict resolution even easier later
on.

Thanks,
-jkbs

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Kuniyuki Iwashima]

From:   Jakub Sitnicki <jakub@cloudflare.com>
Date:   Wed, 22 Jul 2020 14:17:05 +0200
> On Wed, Jul 22, 2020 at 05:21 AM CEST, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the bpf-next tree got conflicts in:
> >
> >   net/ipv4/udp.c
> >   net/ipv6/udp.c
> >
> > between commit:
> >
> >   efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.")
> >
> > from the net tree and commits:
> >
> >   7629c73a1466 ("udp: Extract helper for selecting socket from reuseport group")
> >   2a08748cd384 ("udp6: Extract helper for selecting socket from reuseport group")
> >
> > from the bpf-next tree.
> >
> > I fixed it up (I wasn't sure how to proceed, so I used the latter
> > version) 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.
> 
> This one is a bit tricky.
> 
> Looking at how code in udp[46]_lib_lookup2 evolved, first:
> 
>   acdcecc61285 ("udp: correct reuseport selection with connected sockets")
> 
> 1) exluded connected UDP sockets from reuseport group during lookup, and
> 2) limited fast reuseport return to groups with no connected sockets,
> 
> The second change had an uninteded side-effect of discarding reuseport
> socket selection when reuseport group contained connected sockets.
> 
> Then, recent
> 
>   efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.")
> 
> rectified it by recording reuseport socket selection as lookup result
> candidate, in case fast reuseport return did not happen because
> reuseport group had connected sockets.
> 
> I belive that changes in commit efc6b6f6c311 can be rewritten as below
> to the same effect, by realizing that we are always setting the 'result'
> if 'score > badness'. Either to what reuseport_select_sock() returned or
> to 'sk' that scored higher than current 'badness' threshold.

Good point!
It looks good to me.


> ---8<---
> static struct sock *udp4_lib_lookup2(struct net *net,
> 				     __be32 saddr, __be16 sport,
> 				     __be32 daddr, unsigned int hnum,
> 				     int dif, int sdif,
> 				     struct udp_hslot *hslot2,
> 				     struct sk_buff *skb)
> {
> 	struct sock *sk, *result;
> 	int score, badness;
> 	u32 hash = 0;
> 
> 	result = NULL;
> 	badness = 0;
> 	udp_portaddr_for_each_entry_rcu(sk, &hslot2->head) {
> 		score = compute_score(sk, net, saddr, sport,
> 				      daddr, hnum, dif, sdif);
> 		if (score > badness) {
> 			result = NULL;
> 			if (sk->sk_reuseport &&
> 			    sk->sk_state != TCP_ESTABLISHED) {
> 				hash = udp_ehashfn(net, daddr, hnum,
> 						   saddr, sport);
> 				result = reuseport_select_sock(sk, hash, skb,
> 							       sizeof(struct udphdr));
> 				if (result && !reuseport_has_conns(sk, false))
> 					return result;
> 			}
> 			if (!result)
> 				result = sk;
> 			badness = score;
> 		}
> 	}
> 	return result;
> }
> ---8<---
> 
> From there, it is now easier to resolve the conflict with
> 
>   7629c73a1466 ("udp: Extract helper for selecting socket from reuseport group")
>   2a08748cd384 ("udp6: Extract helper for selecting socket from reuseport group")
> 
> which extract the 'if (sk->sk_reuseport && sk->sk_state !=
> TCP_ESTABLISHED)' block into a helper called lookup_reuseport().
> 
> To merge the two, we need to pull the reuseport_has_conns() check up
> from lookup_reuseport() and back into udp[46]_lib_lookup2(), because now
> we want to record reuseport socket selection even if reuseport group has
> connections.
> 
> The only other call site of lookup_reuseport() is in
> udp[46]_lookup_run_bpf(). We don't want to discard the reuseport
> selected socket if group has connections there either, so no changes are
> needed. And, now that I think about it, the current behavior in
> udp[46]_lookup_run_bpf() is not right.
> 
> The end result for udp4 will look like:
> 
> ---8<---
> static inline struct sock *lookup_reuseport(struct net *net, struct sock *sk,
> 					    struct sk_buff *skb,
> 					    __be32 saddr, __be16 sport,
> 					    __be32 daddr, unsigned short hnum)
> {
> 	struct sock *reuse_sk = NULL;
> 	u32 hash;
> 
> 	if (sk->sk_reuseport && sk->sk_state != TCP_ESTABLISHED) {
> 		hash = udp_ehashfn(net, daddr, hnum, saddr, sport);
> 		reuse_sk = reuseport_select_sock(sk, hash, skb,
> 						 sizeof(struct udphdr));
> 	}
> 	return reuse_sk;
> }
> 
> /* called with rcu_read_lock() */
> static struct sock *udp4_lib_lookup2(struct net *net,
> 				     __be32 saddr, __be16 sport,
> 				     __be32 daddr, unsigned int hnum,
> 				     int dif, int sdif,
> 				     struct udp_hslot *hslot2,
> 				     struct sk_buff *skb)
> {
> 	struct sock *sk, *result;
> 	int score, badness;
> 
> 	result = NULL;
> 	badness = 0;
> 	udp_portaddr_for_each_entry_rcu(sk, &hslot2->head) {
> 		score = compute_score(sk, net, saddr, sport,
> 				      daddr, hnum, dif, sdif);
> 		if (score > badness) {
> 			result = lookup_reuseport(net, sk, skb,
> 						  saddr, sport, daddr, hnum);
> 			if (result && !reuseport_has_conns(sk, false))
> 				return result;
> 			if (!result)
> 				result = sk;
> 			badness = score;
> 		}
> 	}
> 	return result;
> }
> ---8<---
> 
> I will submit a patch that pulls the reuseport_has_conns() check from
> lookup_reuseport() to bpf-next. That should bring the two sides of the
> merge closer. Please let me know if I can help in any other way.
> 
> Also, please take a look at the 3-way diff below from my attempt to
> merge net tree into bpf-next tree taking the described approach.
> 
> Thanks,
> -jkbs

Can I submit a patch to net tree that rewrites udp[46]_lib_lookup2() to
use only 'result' ?

Best Regards,
Kuniyuki

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Jakub Sitnicki]

On Wed, Jul 22, 2020 at 05:21 AM CEST, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the bpf-next tree got conflicts in:
>
>   net/ipv4/udp.c
>   net/ipv6/udp.c
>
> between commit:
>
>   efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.")
>
> from the net tree and commits:
>
>   7629c73a1466 ("udp: Extract helper for selecting socket from reuseport group")
>   2a08748cd384 ("udp6: Extract helper for selecting socket from reuseport group")
>
> from the bpf-next tree.
>
> I fixed it up (I wasn't sure how to proceed, so I used the latter
> version) 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.

This one is a bit tricky.

Looking at how code in udp[46]_lib_lookup2 evolved, first:

  acdcecc61285 ("udp: correct reuseport selection with connected sockets")

1) exluded connected UDP sockets from reuseport group during lookup, and
2) limited fast reuseport return to groups with no connected sockets,

The second change had an uninteded side-effect of discarding reuseport
socket selection when reuseport group contained connected sockets.

Then, recent

  efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.")

rectified it by recording reuseport socket selection as lookup result
candidate, in case fast reuseport return did not happen because
reuseport group had connected sockets.

I belive that changes in commit efc6b6f6c311 can be rewritten as below
to the same effect, by realizing that we are always setting the 'result'
if 'score > badness'. Either to what reuseport_select_sock() returned or
to 'sk' that scored higher than current 'badness' threshold.

---8<---
static struct sock *udp4_lib_lookup2(struct net *net,
				     __be32 saddr, __be16 sport,
				     __be32 daddr, unsigned int hnum,
				     int dif, int sdif,
				     struct udp_hslot *hslot2,
				     struct sk_buff *skb)
{
	struct sock *sk, *result;
	int score, badness;
	u32 hash = 0;

	result = NULL;
	badness = 0;
	udp_portaddr_for_each_entry_rcu(sk, &hslot2->head) {
		score = compute_score(sk, net, saddr, sport,
				      daddr, hnum, dif, sdif);
		if (score > badness) {
			result = NULL;
			if (sk->sk_reuseport &&
			    sk->sk_state != TCP_ESTABLISHED) {
				hash = udp_ehashfn(net, daddr, hnum,
						   saddr, sport);
				result = reuseport_select_sock(sk, hash, skb,
							       sizeof(struct udphdr));
				if (result && !reuseport_has_conns(sk, false))
					return result;
			}
			if (!result)
				result = sk;
			badness = score;
		}
	}
	return result;
}
---8<---

From there, it is now easier to resolve the conflict with

  7629c73a1466 ("udp: Extract helper for selecting socket from reuseport group")
  2a08748cd384 ("udp6: Extract helper for selecting socket from reuseport group")

which extract the 'if (sk->sk_reuseport && sk->sk_state !=
TCP_ESTABLISHED)' block into a helper called lookup_reuseport().

To merge the two, we need to pull the reuseport_has_conns() check up
from lookup_reuseport() and back into udp[46]_lib_lookup2(), because now
we want to record reuseport socket selection even if reuseport group has
connections.

The only other call site of lookup_reuseport() is in
udp[46]_lookup_run_bpf(). We don't want to discard the reuseport
selected socket if group has connections there either, so no changes are
needed. And, now that I think about it, the current behavior in
udp[46]_lookup_run_bpf() is not right.

The end result for udp4 will look like:

---8<---
static inline struct sock *lookup_reuseport(struct net *net, struct sock *sk,
					    struct sk_buff *skb,
					    __be32 saddr, __be16 sport,
					    __be32 daddr, unsigned short hnum)
{
	struct sock *reuse_sk = NULL;
	u32 hash;

	if (sk->sk_reuseport && sk->sk_state != TCP_ESTABLISHED) {
		hash = udp_ehashfn(net, daddr, hnum, saddr, sport);
		reuse_sk = reuseport_select_sock(sk, hash, skb,
						 sizeof(struct udphdr));
	}
	return reuse_sk;
}

/* called with rcu_read_lock() */
static struct sock *udp4_lib_lookup2(struct net *net,
				     __be32 saddr, __be16 sport,
				     __be32 daddr, unsigned int hnum,
				     int dif, int sdif,
				     struct udp_hslot *hslot2,
				     struct sk_buff *skb)
{
	struct sock *sk, *result;
	int score, badness;

	result = NULL;
	badness = 0;
	udp_portaddr_for_each_entry_rcu(sk, &hslot2->head) {
		score = compute_score(sk, net, saddr, sport,
				      daddr, hnum, dif, sdif);
		if (score > badness) {
			result = lookup_reuseport(net, sk, skb,
						  saddr, sport, daddr, hnum);
			if (result && !reuseport_has_conns(sk, false))
				return result;
			if (!result)
				result = sk;
			badness = score;
		}
	}
	return result;
}
---8<---

I will submit a patch that pulls the reuseport_has_conns() check from
lookup_reuseport() to bpf-next. That should bring the two sides of the
merge closer. Please let me know if I can help in any other way.

Also, please take a look at the 3-way diff below from my attempt to
merge net tree into bpf-next tree taking the described approach.

Thanks,
-jkbs

--
diff --cc net/ipv4/udp.c
index b738c63d7a77,4077d589b72e..f5297ea376de
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@@ -408,25 -408,6 +408,22 @@@ static u32 udp_ehashfn(const struct ne
  			      udp_ehash_secret + net_hash_mix(net));
  }

 +static inline struct sock *lookup_reuseport(struct net *net, struct sock *sk,
 +					    struct sk_buff *skb,
 +					    __be32 saddr, __be16 sport,
 +					    __be32 daddr, unsigned short hnum)
 +{
 +	struct sock *reuse_sk = NULL;
 +	u32 hash;
 +
 +	if (sk->sk_reuseport && sk->sk_state != TCP_ESTABLISHED) {
 +		hash = udp_ehashfn(net, daddr, hnum, saddr, sport);
 +		reuse_sk = reuseport_select_sock(sk, hash, skb,
 +						 sizeof(struct udphdr));
- 		/* Fall back to scoring if group has connections */
- 		if (reuseport_has_conns(sk, false))
- 			return NULL;
 +	}
 +	return reuse_sk;
 +}
 +
  /* called with rcu_read_lock() */
  static struct sock *udp4_lib_lookup2(struct net *net,
  				     __be32 saddr, __be16 sport,
@@@ -444,13 -426,20 +441,13 @@@
  		score = compute_score(sk, net, saddr, sport,
  				      daddr, hnum, dif, sdif);
  		if (score > badness) {
 -			reuseport_result = NULL;
 -
 -			if (sk->sk_reuseport &&
 -			    sk->sk_state != TCP_ESTABLISHED) {
 -				hash = udp_ehashfn(net, daddr, hnum,
 -						   saddr, sport);
 -				reuseport_result = reuseport_select_sock(sk, hash, skb,
 -									 sizeof(struct udphdr));
 -				if (reuseport_result && !reuseport_has_conns(sk, false))
 -					return reuseport_result;
 -			}
 -
 -			result = reuseport_result ? : sk;
 +			result = lookup_reuseport(net, sk, skb,
 +						  saddr, sport, daddr, hnum);
- 			if (result)
++			if (result && !reuseport_has_conns(sk, false))
 +				return result;
-
++			if (!result)
++				result = sk;
  			badness = score;
- 			result = sk;
  		}
  	}
  	return result;
diff --cc net/ipv6/udp.c
index ff8be202726a,a8d74f44056a..ca50fcdf0776
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@@ -141,27 -141,6 +141,24 @@@ static int compute_score(struct sock *s
  	return score;
  }

 +static inline struct sock *lookup_reuseport(struct net *net, struct sock *sk,
 +					    struct sk_buff *skb,
 +					    const struct in6_addr *saddr,
 +					    __be16 sport,
 +					    const struct in6_addr *daddr,
 +					    unsigned int hnum)
 +{
 +	struct sock *reuse_sk = NULL;
 +	u32 hash;
 +
 +	if (sk->sk_reuseport && sk->sk_state != TCP_ESTABLISHED) {
 +		hash = udp6_ehashfn(net, daddr, hnum, saddr, sport);
 +		reuse_sk = reuseport_select_sock(sk, hash, skb,
 +						 sizeof(struct udphdr));
- 		/* Fall back to scoring if group has connections */
- 		if (reuseport_has_conns(sk, false))
- 			return NULL;
 +	}
 +	return reuse_sk;
 +}
 +
  /* called with rcu_read_lock() */
  static struct sock *udp6_lib_lookup2(struct net *net,
  		const struct in6_addr *saddr, __be16 sport,
@@@ -178,12 -158,20 +175,12 @@@
  		score = compute_score(sk, net, saddr, sport,
  				      daddr, hnum, dif, sdif);
  		if (score > badness) {
 -			reuseport_result = NULL;
 -
 -			if (sk->sk_reuseport &&
 -			    sk->sk_state != TCP_ESTABLISHED) {
 -				hash = udp6_ehashfn(net, daddr, hnum,
 -						    saddr, sport);
 -
 -				reuseport_result = reuseport_select_sock(sk, hash, skb,
 -									 sizeof(struct udphdr));
 -				if (reuseport_result && !reuseport_has_conns(sk, false))
 -					return reuseport_result;
 -			}
 -
 -			result = reuseport_result ? : sk;
 +			result = lookup_reuseport(net, sk, skb,
 +						  saddr, sport, daddr, hnum);
- 			if (result)
++			if (result && !reuseport_has_conns(sk, false))
 +				return result;
-
- 			result = sk;
++			if (!result)
++				result = sk;
  			badness = score;
  		}
  	}

linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 889 bytes --]

Hi all,

Today's linux-next merge of the bpf-next tree got conflicts in:

  net/ipv4/udp.c
  net/ipv6/udp.c

between commit:

  efc6b6f6c311 ("udp: Improve load balancing for SO_REUSEPORT.")

from the net tree and commits:

  7629c73a1466 ("udp: Extract helper for selecting socket from reuseport group")
  2a08748cd384 ("udp6: Extract helper for selecting socket from reuseport group")

from the bpf-next tree.

I fixed it up (I wasn't sure how to proceed, so I used the latter
version) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 775 bytes --]

Hi all,

Today's linux-next merge of the bpf-next tree got a conflict in:

  arch/riscv/net/bpf_jit_comp.c

between commit:

  96bc4432f5ad ("bpf, riscv: Limit to 33 tail calls")

from the net tree and commit:

  29d92edd9ee8 ("riscv, bpf: Add support for far branching when emitting tail call")

from the bpf-next tree.

I fixed it up (I just used the bpf-next tree version) 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.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Luca Boccassi]

On Wed, 2019-03-27 at 18:53 -0700, Alexei Starovoitov wrote:
> On Wed, Mar 27, 2019 at 8:15 AM Alexei Starovoitov
> <
> alexei.starovoitov@gmail.com
> > wrote:
> > then get propagated into net-next and then bpf-next will get them
> > as well.
> 
> Now it's done.
> Luca,
> could you please rebase on bpf-next and resubmit your patch?

Just sent v8:

https://patchwork.ozlabs.org/patch/1068045/

Thanks for the heads-up!

-- 
Kind regards,
Luca Boccassi

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Alexei Starovoitov]

On Wed, Mar 27, 2019 at 8:15 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> then get propagated into net-next and then bpf-next will get them as well.

Now it's done.
Luca,
could you please rebase on bpf-next and resubmit your patch?

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Alexei Starovoitov]

On Wed, Mar 27, 2019 at 09:26:02AM +0000, Luca Boccassi wrote:
> On Tue, 2019-03-26 at 18:56 -0700, Alexei Starovoitov wrote:
> > On Wed, Mar 27, 2019 at 09:14:37AM +1100, Stephen Rothwell wrote:
> > > Hi all,
> > > 
> > > Today's linux-next merge of the bpf-next tree got a conflict in:
> > > 
> > >   tools/lib/bpf/Makefile
> > > 
> > > between commit:
> > > 
> > >   1d382264d911 ("bpf, libbpf: fix version info and add it to shared
> > > object")
> > > 
> > > from the net tree and commit:
> > > 
> > >   60e4786e229d ("tools/bpf: generate pkg-config file for libbpf")
> > > 
> > > from the bpf-next tree.
> > > 
> > > I fixed it up (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.
> > 
> > argh. that's a heavy conflict.
> > Since that patch was at the top of the bpf-next I removed it for now
> > and will re-apply when bpf-next gets merged cleanly into net-next and
> > we bring back net changes into bpf-next. Sorry Luca.
> 
> No worries - for the next time, should I have based the patch on net-
> next rather than bpf-next?

new bpf related features -> bpf-next tree
bpf bugfixes -> bpf tree

Linus hasn't pulled Dave's PR yet: https://patchwork.ozlabs.org/patch/1066321/
We need these fixes to land his tree first,
then get propagated into net-next and then bpf-next will get them as well.
Sorry for this unfortunate delay.
This lib/bpf/Makefile conflict is not the only one we're waiting for.
There are verifier and other libbpf fixes in there.

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Luca Boccassi]

On Tue, 2019-03-26 at 18:56 -0700, Alexei Starovoitov wrote:
> On Wed, Mar 27, 2019 at 09:14:37AM +1100, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Today's linux-next merge of the bpf-next tree got a conflict in:
> > 
> >   tools/lib/bpf/Makefile
> > 
> > between commit:
> > 
> >   1d382264d911 ("bpf, libbpf: fix version info and add it to shared
> > object")
> > 
> > from the net tree and commit:
> > 
> >   60e4786e229d ("tools/bpf: generate pkg-config file for libbpf")
> > 
> > from the bpf-next tree.
> > 
> > I fixed it up (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.
> 
> argh. that's a heavy conflict.
> Since that patch was at the top of the bpf-next I removed it for now
> and will re-apply when bpf-next gets merged cleanly into net-next and
> we bring back net changes into bpf-next. Sorry Luca.

No worries - for the next time, should I have based the patch on net-
next rather than bpf-next?

-- 
Kind regards,
Luca Boccassi

Re: linux-next: manual merge of the bpf-next tree with the net tree

[Alexei Starovoitov]

On Wed, Mar 27, 2019 at 09:14:37AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   tools/lib/bpf/Makefile
> 
> between commit:
> 
>   1d382264d911 ("bpf, libbpf: fix version info and add it to shared object")
> 
> from the net tree and commit:
> 
>   60e4786e229d ("tools/bpf: generate pkg-config file for libbpf")
> 
> from the bpf-next tree.
> 
> I fixed it up (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.

argh. that's a heavy conflict.
Since that patch was at the top of the bpf-next I removed it for now
and will re-apply when bpf-next gets merged cleanly into net-next and
we bring back net changes into bpf-next. Sorry Luca.

linux-next: manual merge of the bpf-next tree with the net tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2561 bytes --]

Hi all,

Today's linux-next merge of the bpf-next tree got a conflict in:

  tools/lib/bpf/Makefile

between commit:

  1d382264d911 ("bpf, libbpf: fix version info and add it to shared object")

from the net tree and commit:

  60e4786e229d ("tools/bpf: generate pkg-config file for libbpf")

from the bpf-next tree.

I fixed it up (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.

-- 
Cheers,
Stephen Rothwell

diff --cc tools/lib/bpf/Makefile
index 5bf8e52c41fc,96e9571b0a2e..000000000000
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@@ -79,6 -79,9 +79,8 @@@ export prefix libdir src ob
  libdir_SQ = $(subst ','\'',$(libdir))
  libdir_relative_SQ = $(subst ','\'',$(libdir_relative))
  
 -LIB_FILE = libbpf.a libbpf.so
+ PC_FILE = libbpf.pc
+ 
  VERSION		= $(BPF_VERSION)
  PATCHLEVEL	= $(BPF_PATCHLEVEL)
  EXTRAVERSION	= $(BPF_EXTRAVERSION)
@@@ -129,18 -129,17 +131,19 @@@ all
  export srctree OUTPUT CC LD CFLAGS V
  include $(srctree)/tools/build/Makefile.include
  
 -BPF_IN    := $(OUTPUT)libbpf-in.o
 -LIB_FILE := $(addprefix $(OUTPUT),$(LIB_FILE))
 -PC_FILE := $(addprefix $(OUTPUT),$(PC_FILE))
 -VERSION_SCRIPT := libbpf.map
 +BPF_IN		:= $(OUTPUT)libbpf-in.o
 +VERSION_SCRIPT	:= libbpf.map
 +
 +LIB_TARGET	:= $(addprefix $(OUTPUT),$(LIB_TARGET))
 +LIB_FILE	:= $(addprefix $(OUTPUT),$(LIB_FILE))
++PC_FILE		:= $(addprefix $(OUTPUT),$(PC_FILE))
  
  GLOBAL_SYM_COUNT = $(shell readelf -s --wide $(BPF_IN) | \
  			   awk '/GLOBAL/ && /DEFAULT/ && !/UND/ {s++} END{print s}')
  VERSIONED_SYM_COUNT = $(shell readelf -s --wide $(OUTPUT)libbpf.so | \
  			      grep -Eo '[^ ]+@LIBBPF_' | cut -d@ -f1 | sort -u | wc -l)
  
- CMD_TARGETS = $(LIB_TARGET)
 -CMD_TARGETS = $(LIB_FILE) $(PC_FILE)
++CMD_TARGETS = $(LIB_TARGET) $(PC_FILE)
  
  CXX_TEST_TARGET = $(OUTPUT)test_libbpf
  
@@@ -233,7 -232,7 +247,7 @@@ config-clean
  
  clean:
  	$(call QUIET_CLEAN, libbpf) $(RM) $(TARGETS) $(CXX_TEST_TARGET) \
- 		*.o *~ *.a *.so *.so.$(VERSION) .*.d .*.cmd LIBBPF-CFLAGS
 -		*.o *~ *.a *.so .*.d .*.cmd *.pc LIBBPF-CFLAGS
++		*.o *~ *.a *.so *.so.$(VERSION) .*.d .*.cmd *.pc LIBBPF-CFLAGS
  	$(call QUIET_CLEAN, core-gen) $(RM) $(OUTPUT)FEATURE-DUMP.libbpf
  
  

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]