* Re: KASAN: use-after-free Read in remove_wait_queue (2)
From: Guillaume Nault @ 2018-05-23 13:26 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-ppp, Paul Mackerras, netdev, linux-kernel, syzkaller-bugs,
syzbot, viro
In-Reply-To: <20180523032958.GE658@sol.localdomain>
On Tue, May 22, 2018 at 08:29:58PM -0700, Eric Biggers wrote:
> On Fri, May 18, 2018 at 06:02:23PM +0200, Guillaume Nault wrote:
> > On Sun, May 13, 2018 at 11:11:55PM -0700, Eric Biggers wrote:
> > > [+ppp list and maintainer]
> > >
> > > This is a bug in ppp_generic.c; it still happens on Linus' tree and it's easily
> > > reproducible, see program below. The bug is that the PPPIOCDETACH ioctl doesn't
> > > consider that the file can still be attached to epoll instances even when
> > > ->f_count == 1.
> >
> > Right. What would it take to remove the file for the epoll instances?
> > Sorry for the naive question, but I'm not familiar with VFS and didn't
> > find a helper function we could call.
> >
>
> There is eventpoll_release_file(), but it's not exported to modules. It might
> work to call it, but it seems like a hack.
>
> > > Also, the reproducer doesn't test this but I think ppp_poll(),
> > > ppp_read(), and ppp_write() can all race with PPPIOCDETACH, causing
> > > use-after-frees as well.
> >
> > I also believe so. ppp_release() resets ->private_data, and even though
> > functions like ppp_read() test ->private_data before executing, there's
> > no synchronisation mechanism to ensure that the update is visible
> > before the unit or channel is destroyed. Is that the kind of race you
> > had in mind?
>
> Yes, though after looking into it more I *think* these additional races aren't
> actually possible, due to the 'f_count < 2' check. These races could only
> happen with a shared fd table, but in that case fdget() would increment f_count
> for the duration of each operation, resulting in 'f_count >= 2' if both ioctl()
> and something else is running on the same file concurrently.
>
> Note that this also means PPPIOCDETACH doesn't work at all if called from a
> multithreaded application...
>
> >
> > > Any chance that PPPIOCDETACH can simply be removed,
> > > given that it's apparently been "deprecated" for 16 years?
> > > Does anyone use it?
> >
> > The only users I'm aware of are pppd versions older than ppp-2.4.2
> > (released in November 2003). But even at that time, there were issues
> > with PPPIOCDETACH as pppd didn't seem to react properly when this call
> > failed. An Internet search on the "PPPIOCDETACH file->f_count=" kernel
> > log string, or on the "Couldn't release PPP unit: Invalid argument"
> > error message of pppd, returns several related bug reports.
> >
> > Originally, PPPIOCDETACH never failed, but testing ->f_count was
> > later introduced to fix crashes when the file descriptor had been
> > duplicated. It seems that this was motivated by polling issues too.
> >
> > Long story short, it looks like PPPIOCDETACH never has worked well
> > and we have at least two more bugs to fix. Given how it has proven
> > fragile, I wouldn't be surprised if there were even more lurking
> > around. I'd say that it's probably safer to drop it than to add more
> > workarounds and playing wack-a-mole with those bugs.
>
> IMO, if we can get away with removing it without any users noticing, that would
> be much better than trying to fix it with a VFS-level hack, and probably missing
> some cases. I'll send a patch to get things started...
>
Yes, I fully agree. That looks much safer, and given the track record
of this ioctl I very much doubt anyone would depend on it.
^ permalink raw reply
* Re: [PATCH 1/1] selftests/bpf: Makefile fix "missing" headers on build with -idirafter
From: Daniel Borkmann @ 2018-05-23 12:44 UTC (permalink / raw)
To: Sirio Balmelli; +Cc: netdev
In-Reply-To: <20180521070001.tzyzdb3o2ma3hwdv@vm4>
On 05/21/2018 09:00 AM, Sirio Balmelli wrote:
> Selftests fail to build on several distros/architectures because of
> missing headers files.
>
> On a Ubuntu/x86_64 some missing headers are:
> asm/byteorder.h, asm/socket.h, asm/sockios.h
>
> On a Debian/arm32 build already fails at sys/cdefs.h
>
> In both cases, these already exist in /usr/include/<arch-specific-dir>,
> but Clang does not include these when using '-target bpf' flag,
> since it is no longer compiling against the host architecture.
>
> The solution is to:
>
> - run Clang without '-target bpf' and extract the include chain for the
> current system
>
> - add these to the bpf build with '-idirafter'
>
> The choice of -idirafter is to catch this error without injecting
> unexpected include behavior: if an arch-specific tree is built
> for bpf in the future, this will be correctly found by Clang.
>
> Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Ok, I've tried this on arm64:
# clang -v -E - </dev/null 2>&1 | sed -n '/<...> search starts here:/,/End of search list./{ s| \(/.*\)|-idirafter \1|p }'
-idirafter /usr/local/include
-idirafter /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include
-idirafter /usr/include/aarch64-linux-gnu
-idirafter /usr/include
# clang -target bpf -v -E - </dev/null 2>&1 | sed -n '/<...> search starts here:/,/End of search list./{ s| \(/.*\)|-idirafter \1|p }'
-idirafter /usr/local/include
-idirafter /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include
-idirafter /usr/include
# clang -target aarch64 -v -E - </dev/null 2>&1 | sed -n '/<...> search starts here:/,/End of search list./{ s| \(/.*\)|-idirafter \1|p }'
-idirafter /usr/local/include
-idirafter /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include
-idirafter /usr/include
# clang -target aarch64-unknown-linux-gnu -v -E - </dev/null 2>&1 | sed -n '/<...> search starts here:/,/End of search list./{ s| \(/.*\)|-idirafter \1|p }'
-idirafter /usr/local/include
-idirafter /usr/lib/llvm-3.8/bin/../lib/clang/3.8.0/include
-idirafter /usr/include/aarch64-linux-gnu
-idirafter /usr/include
# llc --version
LLVM (http://llvm.org/):
LLVM version 3.8.0
Optimized build.
Built Jul 9 2016 (11:22:59).
Default target: aarch64-unknown-linux-gnu
Host CPU: (unknown)
[...]
So the default target adds additionally /usr/include/aarch64-linux-gnu which is
what you're after. Seems okay if it does the trick. Worst case we can always
revert and find a different solution. I've applied it to bpf-next instead of
bpf in order to give this some time for test exposure, thanks Sirio!
^ permalink raw reply
* Re: Expected result when racing listen(2) on two sockets bound to the same address
From: Kirill Tkhai @ 2018-05-23 12:44 UTC (permalink / raw)
To: Alexander Kurtz, linux-kernel, netdev
In-Reply-To: <a3ecf04de4fded7c71284a9695b7146d284d1f22.camel@kurtz.be>
Hi,
On 23.05.2018 14:15, Alexander Kurtz wrote:
> [Please keep me CC'ed; I'm not subscribed to the list]
>
> Hi!
>
> The program shown below (also available at [0]) does the following:
>
> * Create two sockets
> * Enable SO_REUSEADDR on both
> * Bind both sockets to [::1]:12345
> * Spawn two threads which both call listen(2) on one socket each
> * Check that at least one thread succeeded
>
> Unfortunately, when running this program on Linux 4.16, it is sometimes
> possible that neither thread succeeds in calling listen(2):
>
> $ uname -a
> Linux shepard 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux
> $ time make
> cc -Wall -Wextra -pedantic -Werror -O3 listenrace.c -lpthread -o listenrace
> for i in `seq 10000`; do ./listenrace; done
> listenrace: listenrace.c:58: main: Assertion `result1 == 0 || result2 == 0' failed.
> Aborted
> listenrace: listenrace.c:58: main: Assertion `result1 == 0 || result2 == 0' failed.
> Aborted
> listenrace: listenrace.c:58: main: Assertion `result1 == 0 || result2 == 0' failed.
> Aborted
>
> real 0m8.201s
> user 0m6.801s
> sys 0m2.141s
> $
>
> As can be seen, on 3 runs (out of 10000) calling listen(2) failed in
> *both* threads. Is this to be expected (i.e. "don't do this then") or
> could this be some race condition in the Linux kernel?
At the first sight, it is in kernel and is expected:
inet_csk_listen_start()
{
/* There is race window here: we announce ourselves listening,
* but this transition is still not validated by get_port().
* It is OK, because this socket enters to hash table only
* after validation is complete.
*/
inet_sk_state_store(sk, TCP_LISTEN);
if (!sk->sk_prot->get_port(sk, inet->inet_num)) {
}
CC netdev.
Kirill
^ permalink raw reply
* Re: [PATCH v4 0/3] IR decoding using BPF
From: Daniel Borkmann @ 2018-05-23 12:21 UTC (permalink / raw)
To: Sean Young, linux-media, linux-kernel, Alexei Starovoitov,
Mauro Carvalho Chehab, netdev, Matthias Reichl, Devin Heitmueller,
Y Song, Quentin Monnet
In-Reply-To: <cover.1526651592.git.sean@mess.org>
On 05/18/2018 04:07 PM, Sean Young wrote:
> The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most
> widely used IR protocols, but there are many protocols which are not
> supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes,
> many of which are not supported by rc-core. There is a "long tail" of
> unsupported IR protocols, for which lircd is need to decode the IR .
>
> IR encoding is done in such a way that some simple circuit can decode it;
> therefore, bpf is ideal.
>
> In order to support all these protocols, here we have bpf based IR decoding.
> The idea is that user-space can define a decoder in bpf, attach it to
> the rc device through the lirc chardev.
>
> Separate work is underway to extend ir-keytable to have an extensive library
> of bpf-based decoders, and a much expanded library of rc keymaps.
>
> Another future application would be to compile IRP[3] to a IR BPF program, and
> so support virtually every remote without having to write a decoder for each.
> It might also be possible to support non-button devices such as analog
> directional pads or air conditioning remote controls and decode the target
> temperature in bpf, and pass that to an input device.
Mauro, are you fine with this series going via bpf-next? How ugly would this
get with regards to merge conflicts wrt drivers/media/rc/?
Thanks,
Daniel
> Thanks,
>
> Sean Young
>
> [1] http://www.hifi-remote.com/wiki/index.php?title=DecodeIR
> [2] https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/
> [3] http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation
>
> Changes since v3:
> - Implemented review comments from Quentin Monnet and Y Song (thanks!)
> - More helpful and better formatted bpf helper documentation
> - Changed back to bpf_prog_array rather than open-coded implementation
> - scancodes can be 64 bit
> - bpf gets passed values in microseconds, not nanoseconds.
> microseconds is more than than enough (IR receivers support carriers upto
> 70kHz, at which point a single period is already 14 microseconds). Also,
> this makes it much more consistent with lirc mode2.
> - Since it looks much more like lirc mode2, rename the program type to
> BPF_PROG_TYPE_LIRC_MODE2.
> - Rebased on bpf-next
>
> Changes since v2:
> - Fixed locking issues
> - Improved self-test to cover more cases
> - Rebased on bpf-next again
>
> Changes since v1:
> - Code review comments from Y Song <ys114321@gmail.com> and
> Randy Dunlap <rdunlap@infradead.org>
> - Re-wrote sample bpf to be selftest
> - Renamed RAWIR_DECODER -> RAWIR_EVENT (Kconfig, context, bpf prog type)
> - Rebase on bpf-next
> - Introduced bpf_rawir_event context structure with simpler access checking
>
> Sean Young (3):
> bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not
> found
> media: rc: introduce BPF_PROG_LIRC_MODE2
> bpf: add selftest for lirc_mode2 type program
>
> drivers/media/rc/Kconfig | 13 +
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/bpf-lirc.c | 308 ++++++++++++++++++
> drivers/media/rc/lirc_dev.c | 30 ++
> drivers/media/rc/rc-core-priv.h | 22 ++
> drivers/media/rc/rc-ir-raw.c | 12 +-
> include/linux/bpf_rcdev.h | 30 ++
> include/linux/bpf_types.h | 3 +
> include/uapi/linux/bpf.h | 53 ++-
> kernel/bpf/core.c | 11 +-
> kernel/bpf/syscall.c | 7 +
> kernel/trace/bpf_trace.c | 2 +
> tools/bpf/bpftool/prog.c | 1 +
> tools/include/uapi/linux/bpf.h | 53 ++-
> tools/include/uapi/linux/lirc.h | 217 ++++++++++++
> tools/lib/bpf/libbpf.c | 1 +
> tools/testing/selftests/bpf/Makefile | 8 +-
> tools/testing/selftests/bpf/bpf_helpers.h | 6 +
> .../testing/selftests/bpf/test_lirc_mode2.sh | 28 ++
> .../selftests/bpf/test_lirc_mode2_kern.c | 23 ++
> .../selftests/bpf/test_lirc_mode2_user.c | 154 +++++++++
> 21 files changed, 974 insertions(+), 9 deletions(-)
> create mode 100644 drivers/media/rc/bpf-lirc.c
> create mode 100644 include/linux/bpf_rcdev.h
> create mode 100644 tools/include/uapi/linux/lirc.h
> create mode 100755 tools/testing/selftests/bpf/test_lirc_mode2.sh
> create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_kern.c
> create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_user.c
>
^ permalink raw reply
* [PATCH bpf-next v2 3/3] bpf: add ability to configure BPF JIT kallsyms export at the boot time
From: Eugene Syromiatnikov @ 2018-05-23 12:18 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, linux-doc, Kees Cook, Kai-Heng Feng,
Daniel Borkmann, Alexei Starovoitov, Jonathan Corbet, Jiri Olsa,
Jesper Dangaard Brouer
This patch introduces two configuration options,
BPF_JIT_KALLSYMS_BOOTPARAM and BPF_JIT_KALLSYMS_BOOTPARAM_VALUE, that
allow configuring the initial value of net.core.bpf_jit_kallsyms sysctl
knob. This enables export of addresses of JIT'ed BPF programs that
created during the early boot.
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
Documentation/admin-guide/kernel-parameters.txt | 10 +++++++++
init/Kconfig | 30 +++++++++++++++++++++++++
kernel/bpf/core.c | 14 ++++++++++++
3 files changed, 54 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 5adc6d0..10e7502 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -452,6 +452,16 @@
2 - JIT hardening is enabled for all users.
Default value is set via kernel config option.
+ bpf_jit_kallsyms=
+ Format: { "0" | "1" }
+ Sets initial value of net.core.bpf_jit_kallsyms
+ sysctl knob.
+ 0 - Addresses of JIT'ed BPF programs are not exported
+ to kallsyms.
+ 1 - Export of addresses of JIT'ed BPF programs is
+ enabled for privileged users.
+ Default value is set via kernel config option.
+
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
diff --git a/init/Kconfig b/init/Kconfig
index b661497..b5405ca 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1464,6 +1464,36 @@ config BPF_JIT_HARDEN_BOOTPARAM_VALUE
If you are unsure how to answer this question, answer 0.
+config BPF_JIT_KALLSYMS_BOOTPARAM
+ bool "BPF JIT kallsyms export boot parameter"
+ default n
+ help
+ This option adds a kernel parameter 'bpf_jit_kallsyms' that allows
+ configuring default state of the net.core.bpf_jit_kallsyms sysctl
+ knob. If this option is selected, the default value of the
+ net.core.bpf_jit_kallsyms sysctl knob can be set on the kernel command
+ line. The purpose of this option is to allow enabling BPF JIT
+ kallsyms export for the BPF programs created during the early boot,
+ so they can be traced later.
+
+ If you are unsure how to answer this question, answer N.
+
+config BPF_JIT_KALLSYMS_BOOTPARAM_VALUE
+ int "BPF JIT kallsyms export boot parameter default value"
+ depends on BPF_JIT_HARDEN_BOOTPARAM
+ range 0 1
+ default 0
+ help
+ This option sets the default value for the kernel parameter
+ 'bpf_jit_kallsyms' that configures default value of the
+ net.core.bpf_jit_kallsyms sysctl knob at boot. If this option is set
+ to 0 (zero), the net.core.bpf_jit_kallsyms will default to 0, which
+ will lead to disabling of exporting of addresses of JIT'ed BPF
+ programs. If this option is set to 1 (one), addresses of privileged
+ BPF programs are exported to kallsyms.
+
+ If you are unsure how to answer this question, answer 0.
+
config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 9edb7a8..003d708 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -321,7 +321,21 @@ __setup("bpf_jit_harden=", bpf_jit_harden_setup);
int bpf_jit_harden __read_mostly;
#endif /* CONFIG_BPF_JIT_HARDEN_BOOTPARAM */
+#ifdef CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM
+int bpf_jit_kallsyms __read_mostly = CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM_VALUE;
+
+static int __init bpf_jit_kallsyms_setup(char *str)
+{
+ unsigned long enabled;
+
+ if (!kstrtoul(str, 0, &enabled))
+ bpf_jit_kallsyms = !!enabled;
+ return 1;
+}
+__setup("bpf_jit_kallsyms=", bpf_jit_kallsyms_setup);
+#else /* !CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM */
int bpf_jit_kallsyms __read_mostly;
+#endif /* CONFIG_BPF_JIT_KALLSYMS_BOOTPARAM */
static __always_inline void
bpf_get_prog_addr_region(const struct bpf_prog *prog,
--
2.1.4
^ permalink raw reply related
* [PATCH bpf-next v2 2/3] bpf: add ability to configure BPF JIT hardening via boot-time parameter
From: Eugene Syromiatnikov @ 2018-05-23 12:18 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, linux-doc, Kees Cook, Kai-Heng Feng,
Daniel Borkmann, Alexei Starovoitov, Jonathan Corbet, Jiri Olsa,
Jesper Dangaard Brouer
This patch introduces two configuration options,
BPF_JIT_HARDEN_BOOTPARAM and BPF_JIT_HARDEN_BOOTPARAM_VALUE, that allow
configuring the initial value of net.core.bpf_jit_harden sysctl knob,
which is useful for enforcing JIT hardening during the early boot.
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
Documentation/admin-guide/kernel-parameters.txt | 10 +++++++++
init/Kconfig | 29 +++++++++++++++++++++++++
kernel/bpf/core.c | 17 +++++++++++++++
3 files changed, 56 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index aa8e831..5adc6d0 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -442,6 +442,16 @@
bert_disable [ACPI]
Disable BERT OS support on buggy BIOSes.
+ bpf_jit_harden=
+ Format: { "0" | "1" | "2" }
+ Sets initial value of net.core.bpf_jit_harden
+ sysctl knob.
+ 0 - JIT hardening is disabled.
+ 1 - JIT hardening is enabled for unprivileged users
+ only.
+ 2 - JIT hardening is enabled for all users.
+ Default value is set via kernel config option.
+
bttv.card= [HW,V4L] bttv (bt848 + bt878 based grabber cards)
bttv.radio= Most important insmod options are available as
kernel args too.
diff --git a/init/Kconfig b/init/Kconfig
index 1403a3e..b661497 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1435,6 +1435,35 @@ config UNPRIVILEGED_BPF_BOOTPARAM_VALUE
If you are unsure how to answer this question, answer 0.
+config BPF_JIT_HARDEN_BOOTPARAM
+ bool "BPF JIT harden boot parameter"
+ default n
+ help
+ This option adds a kernel parameter 'bpf_jit_harden' that allows
+ configuring default state of the net.core.bpf_jit_harden sysctl knob.
+ If this option is selected, the default value of the
+ net.core.bpf_jit_harden sysctl knob can be set on the kernel command
+ line. The purpose of this option is to allow enabling BPF JIT
+ hardening for the BPF programs created during the early boot.
+
+ If you are unsure how to answer this question, answer N.
+
+config BPF_JIT_HARDEN_BOOTPARAM_VALUE
+ int "BPF JIT harden boot parameter default value"
+ depends on BPF_JIT_HARDEN_BOOTPARAM
+ range 0 2
+ default 0
+ help
+ This option sets the default value for the kernel parameter
+ 'bpf_jit_enabled' that configures default value of the
+ net.core.bpf_jit_harden sysctl knob at boot. If this option is set to
+ 0 (zero), the net.core.bpf_jit_harden will default to 0, which will
+ lead to no hardening at bootup. If this option is set to 1 (one),
+ hardening will be applied only to unprivileged users only. If this
+ option is set to 2 (two), JIT hardening will be enabled for all users.
+
+ If you are unsure how to answer this question, answer 0.
+
config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
index 2194c6a..9edb7a8 100644
--- a/kernel/bpf/core.c
+++ b/kernel/bpf/core.c
@@ -32,6 +32,7 @@
#include <linux/kallsyms.h>
#include <linux/rcupdate.h>
#include <linux/perf_event.h>
+#include <linux/init.h>
#include <asm/unaligned.h>
@@ -303,7 +304,23 @@ struct bpf_prog *bpf_patch_insn_single(struct bpf_prog *prog, u32 off,
#ifdef CONFIG_BPF_JIT
/* All BPF JIT sysctl knobs here. */
int bpf_jit_enable __read_mostly = IS_BUILTIN(CONFIG_BPF_JIT_ALWAYS_ON);
+
+#ifdef CONFIG_BPF_JIT_HARDEN_BOOTPARAM
+int bpf_jit_harden __read_mostly = CONFIG_BPF_JIT_HARDEN_BOOTPARAM_VALUE;
+
+static int __init bpf_jit_harden_setup(char *str)
+{
+ unsigned long value;
+
+ if (!kstrtoul(str, 0, &value))
+ bpf_jit_harden = min(value, 2UL);
+ return 1;
+}
+__setup("bpf_jit_harden=", bpf_jit_harden_setup);
+#else /* !CONFIG_BPF_JIT_HARDEN_BOOTPARAM */
int bpf_jit_harden __read_mostly;
+#endif /* CONFIG_BPF_JIT_HARDEN_BOOTPARAM */
+
int bpf_jit_kallsyms __read_mostly;
static __always_inline void
--
2.1.4
^ permalink raw reply related
* [PATCH bpf-next v2 1/3] bpf: add ability to configure unprivileged BPF via boot-time parameter
From: Eugene Syromiatnikov @ 2018-05-23 12:18 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, linux-doc, Kees Cook, Kai-Heng Feng,
Daniel Borkmann, Alexei Starovoitov, Jonathan Corbet, Jiri Olsa,
Jesper Dangaard Brouer
This patch introduces two configuration options,
UNPRIVILEGED_BPF_BOOTPARAM and UNPRIVILEGED_BPF_BOOTPARAM_VALUE, that
allow configuring the initial value of kernel.unprivileged_bpf_disabled
sysctl knob, which is useful for the cases when disabling unprivileged
bpf() access during the early boot is desirable.
Signed-off-by: Eugene Syromiatnikov <esyr@redhat.com>
---
Documentation/admin-guide/kernel-parameters.txt | 8 +++++++
init/Kconfig | 31 +++++++++++++++++++++++++
kernel/bpf/syscall.c | 16 +++++++++++++
3 files changed, 55 insertions(+)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 11fc28e..aa8e831 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4355,6 +4355,14 @@
unknown_nmi_panic
[X86] Cause panic on unknown NMI.
+ unprivileged_bpf_disabled=
+ Format: { "0" | "1" }
+ Sets initial value of kernel.unprivileged_bpf_disabled
+ sysctl knob.
+ 0 - unprivileged bpf() syscall access enabled.
+ 1 - unprivileged bpf() syscall access disabled.
+ Default value is set via kernel config option.
+
usbcore.authorized_default=
[USB] Default USB device authorization:
(default -1 = authorized except for wireless USB,
diff --git a/init/Kconfig b/init/Kconfig
index 480a4f2..1403a3e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1404,6 +1404,37 @@ config BPF_JIT_ALWAYS_ON
Enables BPF JIT and removes BPF interpreter to avoid
speculative execution of BPF instructions by the interpreter
+config UNPRIVILEGED_BPF_BOOTPARAM
+ bool "Unprivileged bpf() boot parameter"
+ depends on BPF_SYSCALL
+ default n
+ help
+ This option adds a kernel parameter 'unprivileged_bpf_disabled'
+ that allows configuring default state of the
+ kernel.unprivileged_bpf_disabled sysctl knob.
+ If this option is selected, unprivileged access to the bpf() syscall
+ can be disabled with unprivileged_bpf_disabled=1 on the kernel command
+ line. The purpose of this option is to allow disabling unprivileged
+ bpf() syscall access during the early boot.
+
+ If you are unsure how to answer this question, answer N.
+
+config UNPRIVILEGED_BPF_BOOTPARAM_VALUE
+ int "Unprivileged bpf() boot parameter default value"
+ depends on UNPRIVILEGED_BPF_BOOTPARAM
+ range 0 1
+ default 0
+ help
+ This option sets the default value for the kernel parameter
+ 'unprivileged_bpf_disabled', which allows disabling unprivileged bpf()
+ syscall access at boot. If this option is set to 0 (zero), the
+ unprivileged bpf() boot kernel parameter will default to 0, allowing
+ unprivileged bpf() syscall access at bootup. If this option is
+ set to 1 (one), the unprivileged bpf() kernel parameter will default
+ to 1, disabling unprivileged bpf() syscall access at bootup.
+
+ If you are unsure how to answer this question, answer 0.
+
config USERFAULTFD
bool "Enable userfaultfd() system call"
select ANON_INODES
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index bfcde94..fdc5fd9 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -29,6 +29,7 @@
#include <linux/ctype.h>
#include <linux/btf.h>
#include <linux/nospec.h>
+#include <linux/init.h>
#define IS_FD_ARRAY(map) ((map)->map_type == BPF_MAP_TYPE_PROG_ARRAY || \
(map)->map_type == BPF_MAP_TYPE_PERF_EVENT_ARRAY || \
@@ -45,7 +46,22 @@ static DEFINE_SPINLOCK(prog_idr_lock);
static DEFINE_IDR(map_idr);
static DEFINE_SPINLOCK(map_idr_lock);
+#ifdef CONFIG_UNPRIVILEGED_BPF_BOOTPARAM
+int sysctl_unprivileged_bpf_disabled __read_mostly =
+ CONFIG_UNPRIVILEGED_BPF_BOOTPARAM_VALUE;
+
+static int __init unprivileged_bpf_setup(char *str)
+{
+ unsigned long disabled;
+
+ if (!kstrtoul(str, 0, &disabled))
+ sysctl_unprivileged_bpf_disabled = !!disabled;
+ return 1;
+}
+__setup("unprivileged_bpf_disabled=", unprivileged_bpf_setup);
+#else /* !CONFIG_UNPRIVILEGED_BPF_BOOTPARAM */
int sysctl_unprivileged_bpf_disabled __read_mostly;
+#endif /* CONFIG_UNPRIVILEGED_BPF_BOOTPARAM */
static const struct bpf_map_ops * const bpf_map_types[] = {
#define BPF_PROG_TYPE(_id, _ops)
--
2.1.4
^ permalink raw reply related
* [PATCH bpf-next v2 0/3] bpf: add boot parameters for sysctl knobs
From: Eugene Syromiatnikov @ 2018-05-23 12:18 UTC (permalink / raw)
To: netdev
Cc: linux-kernel, linux-doc, Kees Cook, Kai-Heng Feng,
Daniel Borkmann, Alexei Starovoitov, Jonathan Corbet, Jiri Olsa,
Jesper Dangaard Brouer
Some BPF sysctl knobs affect the loading of BPF programs, and during
system boot/init stages these sysctls are not yet configured.
A concrete example is systemd, that has implemented loading of BPF
programs.
Thus, to allow controlling these setting at early boot, this patch set
adds the ability to change the default setting of these sysctl knobs
as well as option to override them via a boot-time kernel parameter
(in order to avoid rebuilding kernel each time a need of changing these
defaults arises).
The sysctl knobs in question are kernel.unprivileged_bpf_disable,
net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.
Eugene Syromiatnikov (3):
bpf: add ability to configure unprivileged BPF via boot-time parameter
bpf: add ability to configure BPF JIT hardening via boot-time
parameter
bpf: add ability to configure BPF JIT kallsyms export at the boot time
Documentation/admin-guide/kernel-parameters.txt | 28 ++++++++
init/Kconfig | 90 +++++++++++++++++++++++++
kernel/bpf/core.c | 31 +++++++++
kernel/bpf/syscall.c | 16 +++++
4 files changed, 165 insertions(+)
--
2.1.4
^ permalink raw reply
* pull-request: mac80211-next 2018-05-23
From: Johannes Berg @ 2018-05-23 12:14 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here's a new version of the pull request for net-next, now
with the stack size fixes included, which were the reason I
withdrew my earlier one. Other things are also included all
over the map.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit 1fe8c06c4a0d3b589f076cd00c25082840f10423:
Merge branch 'qed-firmware-TLV' (2018-05-22 23:29:55 -0400)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2018-05-23
for you to fetch changes up to bad2929733635f80f99930b252757c70372356fe:
nl80211: Reject disconnect commands except from conn_owner (2018-05-23 11:56:26 +0200)
----------------------------------------------------------------
For this round, we have various things all over the place, notably
* a fix for a race in aggregation, which I want to let
bake for a bit longer before sending to stable
* some new statistics (ACK RSSI, TXQ)
* TXQ configuration
* preparations for HE, particularly radiotap
* replace confusing "country IE" by "country element" since it's
not referring to Ireland
Note that I merged net-next to get a fix from mac80211 that got
there via net, to apply one patch that would otherwise conflict.
----------------------------------------------------------------
Alexander Wetzel (1):
mac80211: fix TX aggregation stop race
Amar Singhal (1):
cfg80211: Call reg_notifier for self managed hints conditionally
Andrew Zaborowski (1):
nl80211: Reject disconnect commands except from conn_owner
Arend Van Spriel (2):
cfg80211: use separate struct for FILS parameters
nl80211: add FILS related parameters to ROAM event
Arend van Spriel (1):
cfg80211: dynamically allocate per-tid stats for station info
Balaji Pothunoori (2):
cfg80211: average ack rssi support for data frames
mac80211: average ack rssi support for data frames
Bjoern Johansson (1):
mac80211_hwsim: indicate support for powersave.
Colin Ian King (2):
mac80211: ethtool: avoid 32 bit multiplication overflow
cfg80211: fix spelling mistake: "uknown" -> "unknown"
Denis Kenzior (2):
nl80211: Fix compilation
nl80211: Optimize cfg80211_bss_expire invocations
Gregory Greenman (1):
mac80211: add api to set CSA counter in mac80211
Haim Dreyfuss (1):
nl80211: Add wmm rule attribute to NL80211_CMD_GET_WIPHY dump command
Ilan Peer (1):
mac80211: Support adding duration for prepare_tx() callback
Johannes Berg (9):
mac80211: rename rtap_vendor_space to rtap_space
mac80211: clean up rate info bandwidth setting
mac80211: ethtool: memset the whole sinfo struct to 0
mac80211: remove pointless flags=0 assignment
cfg80211/mac80211: revert to stack allocation for sinfo
mac80211: allocate and fill tidstats only when needed
cfg80211: release station info tidstats where needed
cfg80211: add missing kernel-doc
Merge remote-tracking branch 'net-next/master' into mac80211-next
João Paulo Rechi Vita (2):
rfkill: Rename rfkill_any_led_trigger* functions
rfkill: Create rfkill-none LED trigger
Toke Høiland-Jørgensen (3):
regulatory: Rename confusing 'country IE' in log output
cfg80211: Expose TXQ stats and parameters to userspace
mac80211: Support the new cfg80211 TXQ stats API
Vidyullatha Kanchanapally (1):
nl80211: Update ERP info using NL80211_CMD_UPDATE_CONNECT_PARAMS
drivers/net/wireless/ath/ath9k/main.c | 3 +-
drivers/net/wireless/intel/iwlwifi/mvm/mac80211.c | 6 +-
drivers/net/wireless/mac80211_hwsim.c | 1 +
include/net/cfg80211.h | 131 ++++++++--
include/net/mac80211.h | 18 +-
include/uapi/linux/nl80211.h | 99 ++++++-
net/mac80211/cfg.c | 103 +++++++-
net/mac80211/driver-ops.h | 8 +-
net/mac80211/ethtool.c | 13 +-
net/mac80211/ht.c | 44 ++--
net/mac80211/ieee80211_i.h | 3 +
net/mac80211/main.c | 3 +
net/mac80211/mlme.c | 17 +-
net/mac80211/rx.c | 40 ++-
net/mac80211/sta_info.c | 38 ++-
net/mac80211/sta_info.h | 5 +-
net/mac80211/status.c | 2 +
net/mac80211/trace.h | 25 +-
net/mac80211/tx.c | 45 ++++
net/mac80211/util.c | 6 +-
net/rfkill/core.c | 66 +++--
net/wireless/core.c | 4 +
net/wireless/nl80211.c | 304 ++++++++++++++++++++--
net/wireless/rdev-ops.h | 12 +
net/wireless/reg.c | 39 ++-
net/wireless/sme.c | 88 +++++--
net/wireless/trace.h | 14 +
net/wireless/util.c | 11 +
28 files changed, 968 insertions(+), 180 deletions(-)
^ permalink raw reply
* [PATCH net-next] ixgbe: introduce a helper to simplify code
From: YueHaibing @ 2018-05-23 12:08 UTC (permalink / raw)
To: davem, jeffrey.t.kirsher; +Cc: netdev, intel-wired-lan, YueHaibing
ixgbe_dbg_reg_ops_read and ixgbe_dbg_netdev_ops_read copy-pasting
the same code except for ixgbe_dbg_netdev_ops_buf/ixgbe_dbg_reg_ops_buf,
so introduce a helper ixgbe_dbg_common_ops_read to remove redundant code.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c | 57 +++++++++---------------
1 file changed, 21 insertions(+), 36 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
index 55fe811..50dfb02 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_debugfs.c
@@ -10,15 +10,9 @@ static struct dentry *ixgbe_dbg_root;
static char ixgbe_dbg_reg_ops_buf[256] = "";
-/**
- * ixgbe_dbg_reg_ops_read - read for reg_ops datum
- * @filp: the opened file
- * @buffer: where to write the data for the user to read
- * @count: the size of the user's buffer
- * @ppos: file position offset
- **/
-static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char __user *buffer,
- size_t count, loff_t *ppos)
+static ssize_t ixgbe_dbg_common_ops_read(struct file *filp, char __user *buffer,
+ size_t count, loff_t *ppos,
+ char *dbg_buf)
{
struct ixgbe_adapter *adapter = filp->private_data;
char *buf;
@@ -29,8 +23,7 @@ static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char __user *buffer,
return 0;
buf = kasprintf(GFP_KERNEL, "%s: %s\n",
- adapter->netdev->name,
- ixgbe_dbg_reg_ops_buf);
+ adapter->netdev->name, dbg_buf);
if (!buf)
return -ENOMEM;
@@ -46,6 +39,20 @@ static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char __user *buffer,
}
/**
+ * ixgbe_dbg_reg_ops_read - read for reg_ops datum
+ * @filp: the opened file
+ * @buffer: where to write the data for the user to read
+ * @count: the size of the user's buffer
+ * @ppos: file position offset
+ **/
+static ssize_t ixgbe_dbg_reg_ops_read(struct file *filp, char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+ return ixgbe_dbg_common_ops_read(filp, buffer, count, ppos,
+ ixgbe_dbg_reg_ops_buf);
+}
+
+/**
* ixgbe_dbg_reg_ops_write - write into reg_ops datum
* @filp: the opened file
* @buffer: where to find the user's data
@@ -121,33 +128,11 @@ static char ixgbe_dbg_netdev_ops_buf[256] = "";
* @count: the size of the user's buffer
* @ppos: file position offset
**/
-static ssize_t ixgbe_dbg_netdev_ops_read(struct file *filp,
- char __user *buffer,
+static ssize_t ixgbe_dbg_netdev_ops_read(struct file *filp, char __user *buffer,
size_t count, loff_t *ppos)
{
- struct ixgbe_adapter *adapter = filp->private_data;
- char *buf;
- int len;
-
- /* don't allow partial reads */
- if (*ppos != 0)
- return 0;
-
- buf = kasprintf(GFP_KERNEL, "%s: %s\n",
- adapter->netdev->name,
- ixgbe_dbg_netdev_ops_buf);
- if (!buf)
- return -ENOMEM;
-
- if (count < strlen(buf)) {
- kfree(buf);
- return -ENOSPC;
- }
-
- len = simple_read_from_buffer(buffer, count, ppos, buf, strlen(buf));
-
- kfree(buf);
- return len;
+ return ixgbe_dbg_common_ops_read(filp, buffer, count, ppos,
+ ixgbe_dbg_netdev_ops_buf);
}
/**
--
2.7.0
^ permalink raw reply related
* Re: [PATCH 0/3] bpf: add boot parameters for sysctl knobs
From: Jesper Dangaard Brouer @ 2018-05-23 12:00 UTC (permalink / raw)
To: Eugene Syromiatnikov
Cc: Alexei Starovoitov, netdev, linux-doc, Kees Cook, Kai-Heng Feng,
Daniel Borkmann, Alexei Starovoitov, Jonathan Corbet, Jiri Olsa,
brouer
In-Reply-To: <20180523113542.GD3888@asgard.redhat.com>
On Wed, 23 May 2018 13:35:47 +0200
Eugene Syromiatnikov <esyr@redhat.com> wrote:
> On Mon, May 21, 2018 at 11:58:13AM -0700, Alexei Starovoitov wrote:
> > On Mon, May 21, 2018 at 02:29:30PM +0200, Eugene Syromiatnikov wrote:
> > > Hello.
> > >
> > > This patch set adds ability to set default values for
> > > kernel.unprivileged_bpf_disable, net.core.bpf_jit_harden,
> > > net.core.bpf_jit_kallsyms sysctl knobs as well as option to override
> > > them via a boot-time kernel parameter.
> >
> > Commits log not only should explain 'what' is being done by the patch,
> > but 'why' as well.
>
> Some BPF sysctl knobs affect the loading of BPF programs, and during
> system boot/init stages these sysctls are not yet configured. A
> concrete example is systemd, that has implemented loading of BPF
> programs.
>
> Thus, to allow controlling these setting at early boot, this patch set
> adds the ability to change the default setting of these sysctl knobs
> as well as option to override them via a boot-time kernel parameter
> (in order to avoid rebuilding kernel each time a need of changing these
> defaults arises).
>
> The sysctl knobs in question are kernel.unprivileged_bpf_disable,
> net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.
Hi Eugene,
You have to resend the entire patchset with this explanation in the
cover-letter. Your old patchset have been dropped from patchwork[1]
due to being marked with "Changes Requested".
Please remember to give it a "V2" tag and also specify which git tree
you are targeting[2], like [PATCH bpf-next V2].
[1] http://patchwork.ozlabs.org/project/netdev/list/?series=45617&state=%2a
[2] https://github.com/netoptimizer/linux/blob/bpf_doc10/Documentation/bpf/bpf_devel_QA.rst#q-how-do-i-indicate-which-tree-bpf-vs-bpf-next-my-patch-should-be-applied-to
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* RE: [PATCH v2] packet: track ring entry use using a shadow ring to prevent RX ring overrun
From: Jon Rosen (jrosen) @ 2018-05-23 11:54 UTC (permalink / raw)
To: Willem de Bruijn
Cc: David S. Miller, Willem de Bruijn, Eric Dumazet, Kees Cook,
David Windsor, Rosen, Rami, Reshetova, Elena, Mike Maloney,
Benjamin Poirier, Thomas Gleixner, Greg Kroah-Hartman,
open list:NETWORKING [GENERAL], open list
In-Reply-To: <CAF=yD-KvTyTibhqpKP79Obfk8KRVDLMyb6THNwNgrJzs47bAtQ@mail.gmail.com>
> > For the ring, there is no requirement to allocate exactly the amount
> > specified by the user request. Safer than relying on shared memory
> > and simpler than the extra allocation in this patch would be to allocate
> > extra shadow memory at the end of the ring (and not mmap that).
> >
> > That still leaves an extra cold cacheline vs using tp_padding.
>
> Given my lack of experience and knowledge in writing kernel code
> it was easier for me to allocate the shadow ring as a separate
> structure. Of course it's not about me and my skills so if it's
> more appropriate to allocate at the tail of the existing ring
> then certainly I can look at doing that.
The memory for the ring is not one contiguous block, it's an array of
blocks of pages (or 'order' sized blocks of pages). I don't think
increasing the size of each of the blocks to provided storage would be
such a good idea as it will risk spilling over into the next order and
wasting lots of memory. I suspect it's also more complex than a single
shadow ring to do both the allocation and the access.
It could be tacked onto the end of the pg_vec[] used to store the
pointers to the blocks. The challenge with that is that a pg_vec[] is
created for each of RX and TX rings so either it would have to
allocate unnecessary storage for TX or the caller will have to say if
extra space should be allocated or not. E.g.:
static struct pgv *alloc_pg_vec(struct tpacket_req *req, int order, int scratch, void **scratch_p)
I'm not sure avoiding the extra allocation and moving it to the
pg_vec[] for the RX ring is going to get the simplification you were
hoping for. Is there another way of storing the shadow ring which
I should consider?
^ permalink raw reply
* Re: [PATCH 0/3] bpf: add boot parameters for sysctl knobs
From: Eugene Syromiatnikov @ 2018-05-23 11:35 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev, linux-kernel, linux-doc, Kees Cook, Kai-Heng Feng,
Daniel Borkmann, Alexei Starovoitov, Jonathan Corbet, Jiri Olsa,
Jesper Dangaard Brouer
In-Reply-To: <20180521185811.2r6372timh5rfs5n@ast-mbp.dhcp.thefacebook.com>
On Mon, May 21, 2018 at 11:58:13AM -0700, Alexei Starovoitov wrote:
> On Mon, May 21, 2018 at 02:29:30PM +0200, Eugene Syromiatnikov wrote:
> > Hello.
> >
> > This patch set adds ability to set default values for
> > kernel.unprivileged_bpf_disable, net.core.bpf_jit_harden,
> > net.core.bpf_jit_kallsyms sysctl knobs as well as option to override
> > them via a boot-time kernel parameter.
>
> Commits log not only should explain 'what' is being done by the patch,
> but 'why' as well.
Some BPF sysctl knobs affect the loading of BPF programs, and during
system boot/init stages these sysctls are not yet configured. A
concrete example is systemd, that has implemented loading of BPF
programs.
Thus, to allow controlling these setting at early boot, this patch set
adds the ability to change the default setting of these sysctl knobs
as well as option to override them via a boot-time kernel parameter
(in order to avoid rebuilding kernel each time a need of changing these
defaults arises).
The sysctl knobs in question are kernel.unprivileged_bpf_disable,
net.core.bpf_jit_harden, and net.core.bpf_jit_kallsyms.
^ permalink raw reply
* Re: [PATCH v2 1/1] drivers core: multi-threading device shutdown
From: Pavel Tatashin @ 2018-05-23 11:31 UTC (permalink / raw)
To: pavel
Cc: Steven Sistare, Daniel Jordan, LKML, jeffrey.t.kirsher,
intel-wired-lan, netdev, gregkh, Alexander Duyck, tobin
In-Reply-To: <20180523104029.GC15312@amd>
Hi Pavel,
Thank you for looking at this patch. BTW, the version 5 is out. The latest
thread is anchered here:
http://lkml.kernel.org/r/20180516024004.28977-1-pasha.tatashin@oracle.com
> ixgbe is network card, right? So ... it does not have any persistent
> state and no moving parts, and there's no reason we could not "just
> power it down"?
True to what you said, but the same path is used for both regular reboot,
and kexec reboot. In the later case we want to make sure that devices are
quieced and do not send any interrupts, do not do any DMA activity, and
basically in the same state as when system was first cold booted, so the
driver initializing functions can pick and bring the devices up. My
understanding is that because we do not want to diverge the regular reboot
and kexec reboot, we do it for both cases.
^ permalink raw reply
* Re: [bpf-next V4 PATCH 1/8] bpf: devmap introduce dev_map_enqueue
From: Jesper Dangaard Brouer @ 2018-05-23 11:12 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, Daniel Borkmann, Alexei Starovoitov, Christoph Hellwig,
BjörnTöpel, Magnus Karlsson, makita.toshiaki, brouer
In-Reply-To: <1cb01875-6044-540a-e1f8-0cafd9587ee8@iogearbox.net>
On Wed, 23 May 2018 11:34:22 +0200 Daniel Borkmann <daniel@iogearbox.net> wrote:
> > +int dev_map_enqueue(struct bpf_dtab_netdev *dst, struct xdp_buff *xdp)
> > +{
> > + struct net_device *dev = dst->dev;
> > + struct xdp_frame *xdpf;
> > + int err;
> > +
> > + if (!dev->netdev_ops->ndo_xdp_xmit)
> > + return -EOPNOTSUPP;
> > +
> > + xdpf = convert_to_xdp_frame(xdp);
> > + if (unlikely(!xdpf))
> > + return -EOVERFLOW;
> > +
> > + /* TODO: implement a bulking/enqueue step later */
> > + err = dev->netdev_ops->ndo_xdp_xmit(dev, xdpf);
> > + if (err)
> > + return err;
> > +
> > + return 0;
>
> The 'err' is just unnecessary, lets just do:
>
> return dev->netdev_ops->ndo_xdp_xmit(dev, xdpf);
>
> Later after the other patches this becomes:
>
> return bq_enqueue(dst, xdpf, dev_rx);
I agree, I'll fix this up in V5.
After this patchset gets applied, there are also other opportunities to
do similar micro-optimizations. I have a branch (on top of this
patchset) which does such micro-optimizations (including this) plus
I've looked at the resulting asm-code layout. But my benchmarks only
show a 2 nanosec improvement for all these micro-optimizations (where
the focus is to reduce the asm-code I-cache size of xdp_do_redirect).
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* RE: [PATCH v2] packet: track ring entry use using a shadow ring to prevent RX ring overrun
From: Jon Rosen (jrosen) @ 2018-05-23 11:08 UTC (permalink / raw)
To: Willem de Bruijn
Cc: David S. Miller, Willem de Bruijn, Eric Dumazet, Kees Cook,
David Windsor, Rosen, Rami, Reshetova, Elena, Mike Maloney,
Benjamin Poirier, Thomas Gleixner, Greg Kroah-Hartman,
open list:NETWORKING [GENERAL], open list
In-Reply-To: <CAF=yD-KHFwhVt4xzED7FPLd_xej9nLmoZOgZG0PmsVgbrnN0Ng@mail.gmail.com>
> >>> I think the bigger issues as you've pointed out are the cost of
> >>> the additional spin lock and should the additional state be
> >>> stored in-band (fewer cache lines) or out-of band (less risk of
> >>> breaking due to unpredictable application behavior).
> >>
> >> We don't need the spinlock if clearing the shadow byte after
> >> setting the status to user.
> >>
> >> Worst case, user will set it back to kernel while the shadow
> >> byte is not cleared yet and the next producer will drop a packet.
> >> But next producers will make progress, so there is no deadlock
> >> or corruption.
> >
> > I thought so too for a while but after spending more time than I
> > care to admit I relized the following sequence was occuring:
> >
> > Core A Core B
> > ------ ------
> > - Enter spin_lock
> > - Get tp_status of head (X)
> > tp_status == 0
> > - Check inuse
> > inuse == 0
> > - Allocate entry X
> > advance head (X+1)
> > set inuse=1
> > - Exit spin_lock
> >
> > <very long delay>
> >
> > <allocate N-1 entries
> > where N = size of ring>
> >
> > - Enter spin_lock
> > - get tp_status of head (X+N)
> > tp_status == 0 (but slot
> > in use for X on core A)
> >
> > - write tp_status of <--- trouble!
> > X = TP_STATUS_USER <--- trouble!
> > - write inuse=0 <--- trouble!
> >
> > - Check inuse
> > inuse == 0
> > - Allocate entry X+N
> > advance head (X+N+1)
> > set inuse=1
> > - Exit spin_lock
> >
> >
> > At this point Core A just passed slot X to userspace with a
> > packet and Core B has just been assigned slot X+N (same slot as
> > X) for it's new packet. Both cores A and B end up filling in that
> > slot. Tracking ths donw was one of the reasons it took me a
> > while to produce these updated diffs.
>
> Is this not just an ordering issue? Since inuse is set after tp_status,
> it has to be tested first (and barriers are needed to avoid reordering).
I changed the code as you suggest to do the inuse check first and
removed the extra added spin_lock/unlock and it seems to be working.
I was able to run through the night without an issue (normally I would
hit the ring corruption in 1 to 2 hours).
Thanks for pointing that out, I should have caught that myself. Next
I'll look at your suggestion for where to put the shadow ring.
^ permalink raw reply
* Re: [v8, bpf-next, 4/9] net/wireless/iwlwifi: fix iwlwifi_dev_ucode_error tracepoint
From: Johannes Berg @ 2018-05-23 11:03 UTC (permalink / raw)
To: Alexei Starovoitov, davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: daniel-FeC+5ew28dpmcu3hnIyYJQ,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
peterz-wEGCiKHe2LqWVfeAwA7xHQ, rostedt-nx8X9YLhiw1AfugRpC6u6w,
mathieu.desnoyers-vg+e7yoeK/dWk0Htik3J/w,
netdev-u79uwXL29TY76Z2rM5mHXA, kernel-team-b10kYP2dOMg,
linux-api-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20180328190540.370956-5-ast-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
On Wed, 2018-03-28 at 12:05 -0700, Alexei Starovoitov wrote:
> fix iwlwifi_dev_ucode_error tracepoint to pass pointer to a table
> instead of all 17 arguments by value.
> dvm/main.c and mvm/utils.c have 'struct iwl_error_event_table'
> defined with very similar yet subtly different fields and offsets.
> tracepoint is still common and using definition of 'struct iwl_error_event_table'
> from dvm/commands.h while copying fields.
> Long term this tracepoint probably should be split into two.
It would've been nice to CC the wireless list for wireless related
patches ...
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-devtrace.c
> @@ -30,6 +30,7 @@
> #ifndef __CHECKER__
> #include "iwl-trans.h"
>
> +#include "dvm/commands.h"
In particular, this breaks the whole driver abstraction.
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/utils.c
> @@ -549,12 +549,7 @@ static void iwl_mvm_dump_lmac_error_log(struct iwl_mvm *mvm, u32 base)
>
> IWL_ERR(mvm, "Loaded firmware version: %s\n", mvm->fw->fw_version);
>
> - trace_iwlwifi_dev_ucode_error(trans->dev, table.error_id, table.tsf_low,
> - table.data1, table.data2, table.data3,
> - table.blink2, table.ilink1,
> - table.ilink2, table.bcon_time, table.gp1,
> - table.gp2, table.fw_rev_type, table.major,
> - table.minor, table.hw_ver, table.brd_ver);
> + trace_iwlwifi_dev_ucode_error(trans->dev, &table, table.hw_ver, table.brd_ver);
This is also utterly wrong because mvm has - for better or worse - a
different type "struct iwl_error_event_table" in this file ...
This really should never have gotten into the tree.
johannes
^ permalink raw reply
* [PATCH] netfilter: nft_numgen: fix ptr_ret.cocci warnings
From: kbuild test robot @ 2018-05-23 10:58 UTC (permalink / raw)
To: Laura Garcia Liebana
Cc: kbuild-all, Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
netfilter-devel, coreteam, netdev, linux-kernel
In-Reply-To: <201805231855.2507c2Vh%fengguang.wu@intel.com>
From: kbuild test robot <fengguang.wu@intel.com>
net/netfilter/nft_numgen.c:117:1-3: WARNING: PTR_ERR_OR_ZERO can be used
Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
Generated by: scripts/coccinelle/api/ptr_ret.cocci
Fixes: d734a2888922 ("netfilter: nft_numgen: add map lookups for numgen statements")
CC: Laura Garcia Liebana <nevola@gmail.com>
Signed-off-by: kbuild test robot <fengguang.wu@intel.com>
---
nft_numgen.c | 5 +----
1 file changed, 1 insertion(+), 4 deletions(-)
--- a/net/netfilter/nft_numgen.c
+++ b/net/netfilter/nft_numgen.c
@@ -114,10 +114,7 @@ static int nft_ng_inc_map_init(const str
tb[NFTA_NG_SET_NAME],
tb[NFTA_NG_SET_ID], genmask);
- if (IS_ERR(priv->map))
- return PTR_ERR(priv->map);
-
- return 0;
+ return PTR_ERR_OR_ZERO(priv->map);
}
static int nft_ng_dump(struct sk_buff *skb, enum nft_registers dreg,
^ permalink raw reply
* Re: [bpf-next V4 PATCH 2/8] bpf: devmap prepare xdp frames for bulking
From: Daniel Borkmann @ 2018-05-23 10:45 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: netdev, Daniel Borkmann, Alexei Starovoitov, Christoph Hellwig,
BjörnTöpel, Magnus Karlsson, makita.toshiaki
In-Reply-To: <20180523122917.05f45694@redhat.com>
On 05/23/2018 12:29 PM, Jesper Dangaard Brouer wrote:
> On Wed, 23 May 2018 11:54:38 +0200
> Daniel Borkmann <daniel@iogearbox.net> wrote:
>
>> Please fix this bug up and send a fresh series, so we can fix this
>> right away without needing a follow-up in bpf-next.
>
> Okay. So I assume this means you reverted/didn't push this patchset in
> bpf-next tree... so I have time to respin the series, and I will send a V5.
Yeah, I tossed it from there, so we have a chance to fix it up in the series
itself, which will then later on land in a clean state in net-next eventually.
So please resend the series in a v5. Thanks Jesper!
^ permalink raw reply
* Re: [PATCH 1/1] tools/lib/libbpf.c: fix string format to allow build on arm32
From: Daniel Borkmann @ 2018-05-23 10:41 UTC (permalink / raw)
To: Sirio Balmelli; +Cc: netdev, kafai
In-Reply-To: <20180521065940.srb4rqwaohkn43i6@vm4>
[ +Martin ]
On 05/21/2018 08:59 AM, Sirio Balmelli wrote:
> On arm32, 'cd tools/testing/selftests/bpf && make' fails with:
>
> libbpf.c:80:10: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘int64_t {aka long long int}’ [-Werror=format=]
> (func)("libbpf: " fmt, ##__VA_ARGS__); \
> ^
> libbpf.c:83:30: note: in expansion of macro ‘__pr’
> #define pr_warning(fmt, ...) __pr(__pr_warning, fmt, ##__VA_ARGS__)
> ^~~~
> libbpf.c:1072:3: note: in expansion of macro ‘pr_warning’
> pr_warning("map:%s value_type:%s has BTF type_size:%ld != value_size:%u\n",
>
> To fix, include 'inttypes.h' and change format directive to 'PRIi64'.
>
> Signed-off-by: Sirio Balmelli <sirio@b-ad.ch>
Thanks for the fix! One minor comment below.
> ---
> tools/lib/bpf/libbpf.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> index 3dbe217bf23e..e2cc8f10c188 100644
> --- a/tools/lib/bpf/libbpf.c
> +++ b/tools/lib/bpf/libbpf.c
> @@ -48,6 +48,8 @@
> #include "bpf.h"
> #include "btf.h"
>
> +#include <inttypes.h> /* PRIi64 */
> +
> #ifndef EM_BPF
> #define EM_BPF 247
> #endif
> @@ -1042,7 +1044,7 @@ static int bpf_map_find_btf_info(struct bpf_map *map, const struct btf *btf)
> }
>
> if (def->key_size != key_size) {
> - pr_warning("map:%s key_type:%s has BTF type_size:%ld != key_size:%u\n",
> + pr_warning("map:%s key_type:%s has BTF type_size:%"PRIi64" != key_size:%u\n",
> map->name, name, key_size, def->key_size);
> return -EINVAL;
> }
> @@ -1069,7 +1071,7 @@ static int bpf_map_find_btf_info(struct bpf_map *map, const struct btf *btf)
> }
>
> if (def->value_size != value_size) {
> - pr_warning("map:%s value_type:%s has BTF type_size:%ld != value_size:%u\n",
> + pr_warning("map:%s value_type:%s has BTF type_size:%"PRIi64" != value_size:%u\n",
> map->name, name, value_size, def->value_size);
I don't think we need the PRIi64 in here. Could you just change it to 'type_size:%u'
and then cast the 'key_size' resp. 'value_size' to unsigned int? We know at this
point that the type size value is positive anyway, so we only want to show the size
mismatch so simple cast should suffice. Thanks!
> return -EINVAL;
> }
>
^ permalink raw reply
* Re: [PATCH v2 1/1] drivers core: multi-threading device shutdown
From: Pavel Machek @ 2018-05-23 10:40 UTC (permalink / raw)
To: Pavel Tatashin
Cc: steven.sistare, daniel.m.jordan, linux-kernel, jeffrey.t.kirsher,
intel-wired-lan, netdev, gregkh, alexander.duyck, tobin
In-Reply-To: <20180505154040.28614-2-pasha.tatashin@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1260 bytes --]
Hi!
> When system is rebooted, halted or kexeced device_shutdown() is
> called.
>
> This function shuts down every single device by calling either:
>
> dev->bus->shutdown(dev)
> dev->driver->shutdown(dev)
...
> Finally, with ixgbe_shutdown() it takes 0.37 for each device, but that time
> is spread all over the place, with bigger offenders:
>
> ixgbe_shutdown
> __ixgbe_shutdown
> ixgbe_close_suspend
> ixgbe_down
> ixgbe_init_hw_generic
> ixgbe_reset_hw_X540
> msleep(100); 0.104483472
> ixgbe_get_san_mac_addr_generic 0.048414851
> ixgbe_get_wwn_prefix_generic 0.048409893
> ixgbe_start_hw_X540
> ixgbe_start_hw_generic
> ixgbe_clear_hw_cntrs_generic 0.048581502
> ixgbe_setup_fc_generic 0.024225800
ixgbe is network card, right? So ... it does not have any persistent
state and no moving parts, and there's no reason we could not "just
power it down"?
> /*
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [bpf-next V4 PATCH 2/8] bpf: devmap prepare xdp frames for bulking
From: Jesper Dangaard Brouer @ 2018-05-23 10:38 UTC (permalink / raw)
To: Daniel Borkmann
Cc: netdev, Daniel Borkmann, Alexei Starovoitov, Christoph Hellwig,
BjörnTöpel, Magnus Karlsson, makita.toshiaki, brouer
In-Reply-To: <1db29c53-1568-a3b5-f2d3-1c830aefe33b@iogearbox.net>
On Wed, 23 May 2018 11:54:38 +0200
Daniel Borkmann <daniel@iogearbox.net> wrote:
> > + for (i = 0; i < bq->count; i++) {
> > + struct xdp_frame *xdpf = bq->q[i];
> > + int err;
> > +
> > + err = dev->netdev_ops->ndo_xdp_xmit(dev, xdpf);
> > + if (err) {
> > + drops++;
> > + xdp_return_frame(xdpf);
> > + }
> > + processed++;
>
> This sort of thing makes it really hard to review. 'processed' and
> 'drops' are not read anywhere in this function. So I need to go and
> check all the other patches whether there's further logic involved here
> or not. I had to review your series after applying all patches in a
> local branch, please never do this. Add the logic in a patch where it's
> self-contained and obvious to review.
Sorry, 'processed' and 'drops' were used by the tracepoint that Alexei
asked me to split into another (next patch). And I can see that I have
renamed 'processed' to 'sent' in the next tracepoint patch, which makes
reviewing even harder sorry. Those lines should have been moved to the
tracepoint patch. My mistake when splitting up the patches.
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH bpf-next v3 10/10] tools: bpftool: add delimiters to multi-function JITed dumps
From: Sandipan Das @ 2018-05-23 10:37 UTC (permalink / raw)
To: Daniel Borkmann, Jakub Kicinski
Cc: ast, netdev, linuxppc-dev, mpe, naveen.n.rao, Quentin Monnet
In-Reply-To: <2dabfa7f-15b8-236c-7724-33bc3da7e549@iogearbox.net>
On 05/23/2018 02:38 PM, Daniel Borkmann wrote:
> On 05/22/2018 09:55 PM, Jakub Kicinski wrote:
>> On Tue, 22 May 2018 22:46:13 +0530, Sandipan Das wrote:
>>> + if (info.nr_jited_func_lens && info.jited_func_lens) {
>>> + struct kernel_sym *sym = NULL;
>>> + unsigned char *img = buf;
>>> + __u64 *ksyms = NULL;
>>> + __u32 *lens;
>>> + __u32 i;
>>> +
>>> + if (info.nr_jited_ksyms) {
>>> + kernel_syms_load(&dd);
>>> + ksyms = (__u64 *) info.jited_ksyms;
>>> + }
>>> +
>>> + lens = (__u32 *) info.jited_func_lens;
>>> + for (i = 0; i < info.nr_jited_func_lens; i++) {
>>> + if (ksyms) {
>>> + sym = kernel_syms_search(&dd, ksyms[i]);
>>> + if (sym)
>>> + printf("%s:\n", sym->name);
>>> + else
>>> + printf("%016llx:\n", ksyms[i]);
>>> + }
>>> +
>>> + disasm_print_insn(img, lens[i], opcodes, name);
>>> + img += lens[i];
>>> + printf("\n");
>>> + }
>>> + } else {
>>
>> The output doesn't seem to be JSON-compatible :( We try to make sure
>> all bpftool command can produce valid JSON when run with -j (or -p)
>> switch.
>>
>> Would it be possible to make each function a separate JSON object with
>> "name" and "insn" array? Would that work?
>
> Sandipan, could you take a look at this? Given there's json output today we
> should definitely try not to break it; presumably this would be one final
> respin of your series with this fixed.
>
>
Sure. With a few changes, I am able get JSON output like the following:
# echo 0 > /proc/sys/net/core/bpf_jit_kallsyms
# bpftool prog -p dump jited id 1
[{
"name": "0xd00000000aa80000",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
"operands": ["r0"
]
},{
"pc": "0xc",
"operation": "std",
"operands": ["r0","16","(","r1",")"
]
},{
"pc": "0x10",
"operation": "stdu",
"operands": ["r1","-112","(","r1",")"
]
},{
...
}
]
},{
"name": "0xd00000000aae0000",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
"operands": ["r0"
]
},{
...
}
]
}
]
# echo 1 > /proc/sys/net/core/bpf_jit_kallsyms
# bpftool prog -p dump jited id 1
[{
"name": "bpf_prog_b811aab41a39ad3d_foo",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
"operands": ["r0"
]
},{
"pc": "0xc",
"operation": "std",
"operands": ["r0","16","(","r1",")"
]
},{
"pc": "0x10",
"operation": "stdu",
"operands": ["r1","-112","(","r1",")"
]
},{
...
}
]
},{
"name": "bpf_prog_196af774a3477707_F",
"insns": [{
"pc": "0x0",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x4",
"operation": "nop",
"operands": [null
]
},{
"pc": "0x8",
"operation": "mflr",
"operands": ["r0"
]
},{
...
}
]
}
]
If this is okay, I can send out the next revision with these changes.
Other than that, for powerpc64, there is a problem with the way the
binutils disassembler code (in "opcodes/ppc-dis.c") passes arguments
to the callback fprintf_json().
In fprintf_json(), we always expect the va_list elements to resolve
to strings (char *). But for powerpc64, the register or immediate
operands are always passed as integers. So, when the code attempts
to resolve these operands using va_arg(ap, char *), bpftool crashes.
For now, I am using a workaround based on vsnprintf() but this does
not get the semantics correct for memory operands. You can probably
see that for the store instructions in the JSON dump above this.
Daniel,
Would it be okay if I send out a fix for this in a different series?
- Sandipan
^ permalink raw reply
* [PATCH] atmel: Add missing call to pci_disable_device()
From: YueHaibing @ 2018-05-23 10:34 UTC (permalink / raw)
To: simon-xn1N/tgparsycpQjotevgVpr/1R2p/CL,
kvalo-sgV2jX0FEOL9JmXXK+q4OQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, YueHaibing
add pci_disable_device in error handling while init_atmel_card failed.
Signed-off-by: YueHaibing <yuehaibing-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
---
drivers/net/wireless/atmel/atmel_pci.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/atmel/atmel_pci.c b/drivers/net/wireless/atmel/atmel_pci.c
index bcf1f27..30df58a 100644
--- a/drivers/net/wireless/atmel/atmel_pci.c
+++ b/drivers/net/wireless/atmel/atmel_pci.c
@@ -61,8 +61,10 @@ static int atmel_pci_probe(struct pci_dev *pdev,
dev = init_atmel_card(pdev->irq, pdev->resource[1].start,
ATMEL_FW_TYPE_506,
&pdev->dev, NULL, NULL);
- if (!dev)
+ if (!dev) {
+ pci_disable_device(pdev);
return -ENODEV;
+ }
pci_set_drvdata(pdev, dev);
return 0;
--
2.7.0
^ permalink raw reply related
* Re: [PATCH bpf-next v2 0/7] BTF uapi cleanup
From: Daniel Borkmann @ 2018-05-23 10:29 UTC (permalink / raw)
To: Martin KaFai Lau, netdev; +Cc: Alexei Starovoitov, Yonghong Song, kernel-team
In-Reply-To: <20180522215723.784040-1-kafai@fb.com>
On 05/22/2018 11:57 PM, Martin KaFai Lau wrote:
> This patch set makes some changes to cleanup the unused
> bits in BTF uapi. It also makes the btf_header extensible.
>
> Please see individual patches for details.
>
> v2:
> - Remove NR_SECS from patch 2
> - Remove "unsigned" check on array->index_type from patch 3
> - Remove BTF_INT_VARARGS and further limit BTF_INT_ENCODING
> from 8 bits to 4 bits in patch 4
> - Adjustments in test_btf.c to reflect changes in v2
>
> Martin KaFai Lau (7):
> bpf: Expose check_uarg_tail_zero()
> bpf: btf: Change how section is supported in btf_header
> bpf: btf: Check array->index_type
> bpf: btf: Remove unused bits from uapi/linux/btf.h
> bpf: btf: Rename btf_key_id and btf_value_id in bpf_map_info
> bpf: btf: Sync bpf.h and btf.h to tools
> bpf: btf: Add tests for the btf uapi changes
>
> include/linux/bpf.h | 6 +-
> include/uapi/linux/bpf.h | 8 +-
> include/uapi/linux/btf.h | 37 +--
> kernel/bpf/arraymap.c | 2 +-
> kernel/bpf/btf.c | 335 +++++++++++++++------
> kernel/bpf/syscall.c | 32 +-
> tools/include/uapi/linux/bpf.h | 8 +-
> tools/include/uapi/linux/btf.h | 37 +--
> tools/lib/bpf/bpf.c | 4 +-
> tools/lib/bpf/bpf.h | 4 +-
> tools/lib/bpf/btf.c | 5 +-
> tools/lib/bpf/libbpf.c | 34 +--
> tools/lib/bpf/libbpf.h | 4 +-
> tools/testing/selftests/bpf/test_btf.c | 521 +++++++++++++++++++++++++++------
> 14 files changed, 753 insertions(+), 284 deletions(-)
>
Applied to bpf-next, thanks Martin!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox