* linux-next: manual merge of the bpf-next tree with the net tree
@ 2019-03-26 22:14 Stephen Rothwell
2019-03-27 1:56 ` Alexei Starovoitov
0 siblings, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2019-03-26 22:14 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Luca Boccassi
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2019-03-26 22:14 linux-next: manual merge of the bpf-next tree with the net tree Stephen Rothwell
@ 2019-03-27 1:56 ` Alexei Starovoitov
2019-03-27 9:26 ` Luca Boccassi
0 siblings, 1 reply; 26+ messages in thread
From: Alexei Starovoitov @ 2019-03-27 1:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller,
Linux Next Mailing List, Linux Kernel Mailing List,
Luca Boccassi
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2019-03-27 1:56 ` Alexei Starovoitov
@ 2019-03-27 9:26 ` Luca Boccassi
2019-03-27 15:15 ` Alexei Starovoitov
0 siblings, 1 reply; 26+ messages in thread
From: Luca Boccassi @ 2019-03-27 9:26 UTC (permalink / raw)
To: Alexei Starovoitov, Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller,
Linux Next Mailing List, Linux Kernel Mailing List
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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2019-03-27 9:26 ` Luca Boccassi
@ 2019-03-27 15:15 ` Alexei Starovoitov
2019-03-28 1:53 ` Alexei Starovoitov
0 siblings, 1 reply; 26+ messages in thread
From: Alexei Starovoitov @ 2019-03-27 15:15 UTC (permalink / raw)
To: Luca Boccassi
Cc: Stephen Rothwell, Daniel Borkmann, Alexei Starovoitov,
Networking, David Miller, Linux Next Mailing List,
Linux Kernel Mailing List
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net tree
@ 2019-10-13 23:32 Stephen Rothwell
2019-10-15 23:30 ` Stephen Rothwell
0 siblings, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2019-10-13 23:32 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Ivan Khoronzhuk, Yonghong Song
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2019-10-13 23:32 Stephen Rothwell
@ 2019-10-15 23:30 ` Stephen Rothwell
0 siblings, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2019-10-15 23:30 UTC (permalink / raw)
To: David Miller
Cc: Daniel Borkmann, Alexei Starovoitov, Networking,
Linux Next Mailing List, Linux Kernel Mailing List,
Ivan Khoronzhuk, Yonghong Song
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net tree
@ 2019-12-19 23:23 Stephen Rothwell
0 siblings, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2019-12-19 23:23 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Paul Chaignon, Björn Töpel
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* linux-next: manual merge of the bpf-next tree with the net tree
@ 2020-07-22 3:21 Stephen Rothwell
2020-07-22 12:17 ` Jakub Sitnicki
2020-07-23 2:11 ` Stephen Rothwell
0 siblings, 2 replies; 26+ messages in thread
From: Stephen Rothwell @ 2020-07-22 3:21 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Kuniyuki Iwashima, Jakub Sitnicki
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2020-07-22 3:21 Stephen Rothwell
@ 2020-07-22 12:17 ` Jakub Sitnicki
2020-07-22 14:42 ` Kuniyuki Iwashima
2020-07-23 2:11 ` Stephen Rothwell
1 sibling, 1 reply; 26+ messages in thread
From: Jakub Sitnicki @ 2020-07-22 12:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller,
Linux Next Mailing List, Linux Kernel Mailing List,
Kuniyuki Iwashima, kernel-team, Willem de Bruijn
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;
}
}
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2020-07-22 12:17 ` Jakub Sitnicki
@ 2020-07-22 14:42 ` Kuniyuki Iwashima
2020-07-22 15:02 ` Jakub Sitnicki
0 siblings, 1 reply; 26+ messages in thread
From: Kuniyuki Iwashima @ 2020-07-22 14:42 UTC (permalink / raw)
To: jakub
Cc: ast, daniel, davem, kernel-team, kuniyu, linux-kernel,
linux-next, netdev, sfr, willemb
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
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2020-07-22 14:42 ` Kuniyuki Iwashima
@ 2020-07-22 15:02 ` Jakub Sitnicki
2020-07-22 15:05 ` Willem de Bruijn
0 siblings, 1 reply; 26+ messages in thread
From: Jakub Sitnicki @ 2020-07-22 15:02 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: ast, daniel, davem, kernel-team, linux-kernel, linux-next,
netdev, sfr, willemb
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net tree
2020-07-22 15:02 ` Jakub Sitnicki
@ 2020-07-22 15:05 ` Willem de Bruijn
2020-07-22 15:25 ` Jakub Sitnicki
0 siblings, 1 reply; 26+ messages in thread
From: Willem de Bruijn @ 2020-07-22 15:05 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: Kuniyuki Iwashima, Alexei Starovoitov, Daniel Borkmann,
David Miller, kernel-team, linux-kernel, Linux-Next Mailing List,
Network Development, Stephen Rothwell
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?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net tree
2020-07-22 15:05 ` Willem de Bruijn
@ 2020-07-22 15:25 ` Jakub Sitnicki
2020-07-22 15:49 ` Willem de Bruijn
0 siblings, 1 reply; 26+ messages in thread
From: Jakub Sitnicki @ 2020-07-22 15:25 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Kuniyuki Iwashima, Alexei Starovoitov, Daniel Borkmann,
David Miller, kernel-team, linux-kernel, Linux-Next Mailing List,
Network Development, Stephen Rothwell
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?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net tree
2020-07-22 15:25 ` Jakub Sitnicki
@ 2020-07-22 15:49 ` Willem de Bruijn
2020-07-22 17:14 ` Alexei Starovoitov
0 siblings, 1 reply; 26+ messages in thread
From: Willem de Bruijn @ 2020-07-22 15:49 UTC (permalink / raw)
To: Jakub Sitnicki
Cc: Willem de Bruijn, Kuniyuki Iwashima, Alexei Starovoitov,
Daniel Borkmann, David Miller, kernel-team, linux-kernel,
Linux-Next Mailing List, Network Development, Stephen Rothwell
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.
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2020-07-22 15:49 ` Willem de Bruijn
@ 2020-07-22 17:14 ` Alexei Starovoitov
0 siblings, 0 replies; 26+ messages in thread
From: Alexei Starovoitov @ 2020-07-22 17:14 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Jakub Sitnicki, Kuniyuki Iwashima, Alexei Starovoitov,
Daniel Borkmann, David Miller, kernel-team, linux-kernel,
Linux-Next Mailing List, Network Development, Stephen Rothwell
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: linux-next: manual merge of the bpf-next tree with the net tree
2020-07-22 3:21 Stephen Rothwell
2020-07-22 12:17 ` Jakub Sitnicki
@ 2020-07-23 2:11 ` Stephen Rothwell
1 sibling, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2020-07-23 2:11 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Kuniyuki Iwashima, Jakub Sitnicki
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net tree
@ 2022-08-25 1:00 Stephen Rothwell
0 siblings, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2022-08-25 1:00 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, bpf,
Networking, David S. Miller
Cc: Kuniyuki Iwashima, Linux Kernel Mailing List,
Linux Next Mailing List, Martin KaFai Lau
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* linux-next: manual merge of the bpf-next tree with the net tree
@ 2022-09-01 1:11 Stephen Rothwell
0 siblings, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2022-09-01 1:11 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, David Miller
Cc: bpf, Networking, Daniel Müller, Hou Tao,
Linux Kernel Mailing List, Linux Next Mailing List,
Martin KaFai Lau
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* linux-next: manual merge of the bpf-next tree with the net tree
@ 2022-11-15 23:10 Stephen Rothwell
0 siblings, 0 replies; 26+ messages in thread
From: Stephen Rothwell @ 2022-11-15 23:10 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko, David Miller
Cc: bpf, Networking, Kumar Kartikeya Dwivedi,
Linux Kernel Mailing List, Linux Next Mailing List, Xu Kuohai
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* linux-next: manual merge of the bpf-next tree with the net tree
@ 2024-03-28 1:55 Stephen Rothwell
2024-03-28 1:57 ` Alexei Starovoitov
0 siblings, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2024-03-28 1:55 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
David Miller, Jakub Kicinski, Paolo Abeni
Cc: bpf, Networking, Haiyue Wang, Linux Kernel Mailing List,
Linux Next Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2024-03-28 1:55 Stephen Rothwell
@ 2024-03-28 1:57 ` Alexei Starovoitov
0 siblings, 0 replies; 26+ messages in thread
From: Alexei Starovoitov @ 2024-03-28 1:57 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
David Miller, Jakub Kicinski, Paolo Abeni, bpf, Networking,
Haiyue Wang, Linux Kernel Mailing List, Linux Next Mailing List
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* linux-next: manual merge of the bpf-next tree with the net tree
@ 2024-04-29 1:49 Stephen Rothwell
2024-04-29 18:56 ` Jakub Kicinski
0 siblings, 1 reply; 26+ messages in thread
From: Stephen Rothwell @ 2024-04-29 1:49 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
David Miller, Jakub Kicinski, Paolo Abeni
Cc: bpf, Networking, Linux Kernel Mailing List,
Linux Next Mailing List, Martin KaFai Lau, Puranjay Mohan,
Puranjay Mohan
[-- Attachment #1: Type: text/plain, Size: 2121 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got conflicts in:
include/linux/filter.h
kernel/bpf/core.c
between commit:
66e13b615a0c ("bpf: verifier: prevent userspace memory access")
from the net tree and commit:
d503a04f8bc0 ("bpf: Add support for certain atomics in bpf_arena to x86 JIT")
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 include/linux/filter.h
index 42dbceb04ca6,7a27f19bf44d..000000000000
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@@ -975,7 -1000,7 +1000,8 @@@ bool bpf_jit_supports_far_kfunc_call(vo
bool bpf_jit_supports_exceptions(void);
bool bpf_jit_supports_ptr_xchg(void);
bool bpf_jit_supports_arena(void);
+u64 bpf_arch_uaddress_limit(void);
+ bool bpf_jit_supports_insn(struct bpf_insn *insn, bool in_arena);
void arch_bpf_stack_walk(bool (*consume_fn)(void *cookie, u64 ip, u64 sp, u64 bp), void *cookie);
bool bpf_helper_changes_pkt_data(void *func);
diff --cc kernel/bpf/core.c
index a04695ca82b9,95c7fd093e55..000000000000
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@@ -2958,15 -2965,11 +2965,20 @@@ bool __weak bpf_jit_supports_arena(void
return false;
}
+u64 __weak bpf_arch_uaddress_limit(void)
+{
+#if defined(CONFIG_64BIT) && defined(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE)
+ return TASK_SIZE;
+#else
+ return 0;
+#endif
+}
+
+ bool __weak bpf_jit_supports_insn(struct bpf_insn *insn, bool in_arena)
+ {
+ return false;
+ }
+
/* Return TRUE if the JIT backend satisfies the following two conditions:
* 1) JIT backend supports atomic_xchg() on pointer-sized words.
* 2) Under the specific arch, the implementation of xchg() is the same
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2024-04-29 1:49 Stephen Rothwell
@ 2024-04-29 18:56 ` Jakub Kicinski
2024-04-29 21:17 ` Daniel Borkmann
0 siblings, 1 reply; 26+ messages in thread
From: Jakub Kicinski @ 2024-04-29 18:56 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Daniel Borkmann, Alexei Starovoitov, Andrii Nakryiko,
David Miller, Paolo Abeni, bpf, Networking,
Linux Kernel Mailing List, Linux Next Mailing List,
Martin KaFai Lau, Puranjay Mohan, Puranjay Mohan
On Mon, 29 Apr 2024 11:49:39 +1000 Stephen Rothwell wrote:
> +u64 __weak bpf_arch_uaddress_limit(void)
> +{
> +#if defined(CONFIG_64BIT) && defined(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE)
> + return TASK_SIZE;
> +#else
> + return 0;
> +#endif
> +}
> +
> + bool __weak bpf_jit_supports_insn(struct bpf_insn *insn, bool in_arena)
> + {
> + return false;
> + }
Thanks! FTR I plan to used the inverse order, if that matters..
^ permalink raw reply [flat|nested] 26+ messages in thread* Re: linux-next: manual merge of the bpf-next tree with the net tree
2024-04-29 18:56 ` Jakub Kicinski
@ 2024-04-29 21:17 ` Daniel Borkmann
0 siblings, 0 replies; 26+ messages in thread
From: Daniel Borkmann @ 2024-04-29 21:17 UTC (permalink / raw)
To: Jakub Kicinski, Stephen Rothwell
Cc: Alexei Starovoitov, Andrii Nakryiko, David Miller, Paolo Abeni,
bpf, Networking, Linux Kernel Mailing List,
Linux Next Mailing List, Martin KaFai Lau, Puranjay Mohan,
Puranjay Mohan
On 4/29/24 8:56 PM, Jakub Kicinski wrote:
> On Mon, 29 Apr 2024 11:49:39 +1000 Stephen Rothwell wrote:
>> +u64 __weak bpf_arch_uaddress_limit(void)
>> +{
>> +#if defined(CONFIG_64BIT) && defined(CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE)
>> + return TASK_SIZE;
>> +#else
>> + return 0;
>> +#endif
>> +}
>> +
>> + bool __weak bpf_jit_supports_insn(struct bpf_insn *insn, bool in_arena)
>> + {
>> + return false;
>> + }
>
> Thanks! FTR I plan to used the inverse order, if that matters..
Yeap, that looks cleaner, same for the signature in the header given the others
prefixed with bpf_jit_supports_*.
Thanks,
Daniel
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2024-04-29 21:18 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-03-26 22:14 linux-next: manual merge of the bpf-next tree with the net tree Stephen Rothwell
2019-03-27 1:56 ` Alexei Starovoitov
2019-03-27 9:26 ` Luca Boccassi
2019-03-27 15:15 ` Alexei Starovoitov
2019-03-28 1:53 ` Alexei Starovoitov
2019-03-28 11:37 ` Luca Boccassi
2019-10-13 23:32 Stephen Rothwell
2019-10-15 23:30 ` Stephen Rothwell
2019-12-19 23:23 Stephen Rothwell
2020-07-22 3:21 Stephen Rothwell
2020-07-22 12:17 ` Jakub Sitnicki
2020-07-22 14:42 ` Kuniyuki Iwashima
2020-07-22 15:02 ` Jakub Sitnicki
2020-07-22 15:05 ` Willem de Bruijn
2020-07-22 15:25 ` Jakub Sitnicki
2020-07-22 15:49 ` Willem de Bruijn
2020-07-22 17:14 ` Alexei Starovoitov
2020-07-23 2:11 ` Stephen Rothwell
2022-08-25 1:00 Stephen Rothwell
2022-09-01 1:11 Stephen Rothwell
2022-11-15 23:10 Stephen Rothwell
2024-03-28 1:55 Stephen Rothwell
2024-03-28 1:57 ` Alexei Starovoitov
2024-04-29 1:49 Stephen Rothwell
2024-04-29 18:56 ` Jakub Kicinski
2024-04-29 21:17 ` Daniel Borkmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).