* [PATCH AUTOSEL 6.0 20/73] bpf: make sure skb->len != 0 when redirecting to a tunneling device
[not found] <20221218160741.927862-1-sashal@kernel.org>
@ 2022-12-18 16:06 ` Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 46/73] ppp: associate skb with a device at tx Sasha Levin
` (4 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2022-12-18 16:06 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stanislav Fomichev, Eric Dumazet, syzbot+f635e86ec3fa0a37e019,
Martin KaFai Lau, Alexei Starovoitov, Sasha Levin, martin.lau,
daniel, andrii, davem, kuba, pabeni, bpf, netdev
From: Stanislav Fomichev <sdf@google.com>
[ Upstream commit 07ec7b502800ba9f7b8b15cb01dd6556bb41aaca ]
syzkaller managed to trigger another case where skb->len == 0
when we enter __dev_queue_xmit:
WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 skb_assert_len include/linux/skbuff.h:2576 [inline]
WARNING: CPU: 0 PID: 2470 at include/linux/skbuff.h:2576 __dev_queue_xmit+0x2069/0x35e0 net/core/dev.c:4295
Call Trace:
dev_queue_xmit+0x17/0x20 net/core/dev.c:4406
__bpf_tx_skb net/core/filter.c:2115 [inline]
__bpf_redirect_no_mac net/core/filter.c:2140 [inline]
__bpf_redirect+0x5fb/0xda0 net/core/filter.c:2163
____bpf_clone_redirect net/core/filter.c:2447 [inline]
bpf_clone_redirect+0x247/0x390 net/core/filter.c:2419
bpf_prog_48159a89cb4a9a16+0x59/0x5e
bpf_dispatcher_nop_func include/linux/bpf.h:897 [inline]
__bpf_prog_run include/linux/filter.h:596 [inline]
bpf_prog_run include/linux/filter.h:603 [inline]
bpf_test_run+0x46c/0x890 net/bpf/test_run.c:402
bpf_prog_test_run_skb+0xbdc/0x14c0 net/bpf/test_run.c:1170
bpf_prog_test_run+0x345/0x3c0 kernel/bpf/syscall.c:3648
__sys_bpf+0x43a/0x6c0 kernel/bpf/syscall.c:5005
__do_sys_bpf kernel/bpf/syscall.c:5091 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5089 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5089
do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48
entry_SYSCALL_64_after_hwframe+0x61/0xc6
The reproducer doesn't really reproduce outside of syzkaller
environment, so I'm taking a guess here. It looks like we
do generate correct ETH_HLEN-sized packet, but we redirect
the packet to the tunneling device. Before we do so, we
__skb_pull l2 header and arrive again at skb->len == 0.
Doesn't seem like we can do anything better than having
an explicit check after __skb_pull?
Cc: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot+f635e86ec3fa0a37e019@syzkaller.appspotmail.com
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/r/20221027225537.353077-1-sdf@google.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
net/core/filter.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/core/filter.c b/net/core/filter.c
index c191db80ce93..e7c8d76c22db 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -2125,6 +2125,10 @@ static int __bpf_redirect_no_mac(struct sk_buff *skb, struct net_device *dev,
if (mlen) {
__skb_pull(skb, mlen);
+ if (unlikely(!skb->len)) {
+ kfree_skb(skb);
+ return -ERANGE;
+ }
/* At ingress, the mac header has already been pulled once.
* At egress, skb_pospull_rcsum has to be done in case that
--
2.35.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH AUTOSEL 6.0 46/73] ppp: associate skb with a device at tx
[not found] <20221218160741.927862-1-sashal@kernel.org>
2022-12-18 16:06 ` [PATCH AUTOSEL 6.0 20/73] bpf: make sure skb->len != 0 when redirecting to a tunneling device Sasha Levin
@ 2022-12-18 16:07 ` Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 47/73] bpf: Fix a BTF_ID_LIST bug with CONFIG_DEBUG_INFO_BTF not set Sasha Levin
` (3 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2022-12-18 16:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stanislav Fomichev, Paul Mackerras, linux-ppp,
syzbot+41cab52ab62ee99ed24a, David S . Miller, Sasha Levin,
edumazet, kuba, pabeni, netdev, bpf
From: Stanislav Fomichev <sdf@google.com>
[ Upstream commit 9f225444467b98579cf28d94f4ad053460dfdb84 ]
Syzkaller triggered flow dissector warning with the following:
r0 = openat$ppp(0xffffffffffffff9c, &(0x7f0000000000), 0xc0802, 0x0)
ioctl$PPPIOCNEWUNIT(r0, 0xc004743e, &(0x7f00000000c0))
ioctl$PPPIOCSACTIVE(r0, 0x40107446, &(0x7f0000000240)={0x2, &(0x7f0000000180)=[{0x20, 0x0, 0x0, 0xfffff034}, {0x6}]})
pwritev(r0, &(0x7f0000000040)=[{&(0x7f0000000140)='\x00!', 0x2}], 0x1, 0x0, 0x0)
[ 9.485814] WARNING: CPU: 3 PID: 329 at net/core/flow_dissector.c:1016 __skb_flow_dissect+0x1ee0/0x1fa0
[ 9.485929] skb_get_poff+0x53/0xa0
[ 9.485937] bpf_skb_get_pay_offset+0xe/0x20
[ 9.485944] ? ppp_send_frame+0xc2/0x5b0
[ 9.485949] ? _raw_spin_unlock_irqrestore+0x40/0x60
[ 9.485958] ? __ppp_xmit_process+0x7a/0xe0
[ 9.485968] ? ppp_xmit_process+0x5b/0xb0
[ 9.485974] ? ppp_write+0x12a/0x190
[ 9.485981] ? do_iter_write+0x18e/0x2d0
[ 9.485987] ? __import_iovec+0x30/0x130
[ 9.485997] ? do_pwritev+0x1b6/0x240
[ 9.486016] ? trace_hardirqs_on+0x47/0x50
[ 9.486023] ? __x64_sys_pwritev+0x24/0x30
[ 9.486026] ? do_syscall_64+0x3d/0x80
[ 9.486031] ? entry_SYSCALL_64_after_hwframe+0x63/0xcd
Flow dissector tries to find skb net namespace either via device
or via socket. Neigher is set in ppp_send_frame, so let's manually
use ppp->dev.
Cc: Paul Mackerras <paulus@samba.org>
Cc: linux-ppp@vger.kernel.org
Reported-by: syzbot+41cab52ab62ee99ed24a@syzkaller.appspotmail.com
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/net/ppp/ppp_generic.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 9206c660a72e..d4c821c8cf57 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -1743,6 +1743,8 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
int len;
unsigned char *cp;
+ skb->dev = ppp->dev;
+
if (proto < 0x8000) {
#ifdef CONFIG_PPP_FILTER
/* check if we should pass this packet */
--
2.35.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH AUTOSEL 6.0 47/73] bpf: Fix a BTF_ID_LIST bug with CONFIG_DEBUG_INFO_BTF not set
[not found] <20221218160741.927862-1-sashal@kernel.org>
2022-12-18 16:06 ` [PATCH AUTOSEL 6.0 20/73] bpf: make sure skb->len != 0 when redirecting to a tunneling device Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 46/73] ppp: associate skb with a device at tx Sasha Levin
@ 2022-12-18 16:07 ` Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 48/73] bpf: Prevent decl_tag from being referenced in func_proto arg Sasha Levin
` (2 subsequent siblings)
5 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2022-12-18 16:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Yonghong Song, kernel test robot, Dan Carpenter,
Nathan Chancellor, Alexei Starovoitov, Sasha Levin, martin.lau,
daniel, andrii, bpf
From: Yonghong Song <yhs@fb.com>
[ Upstream commit beb3d47d1d3d7185bb401af628ad32ee204a9526 ]
With CONFIG_DEBUG_INFO_BTF not set, we hit the following compilation error,
/.../kernel/bpf/verifier.c:8196:23: error: array index 6 is past the end of the array
(that has type 'u32[5]' (aka 'unsigned int[5]')) [-Werror,-Warray-bounds]
if (meta->func_id == special_kfunc_list[KF_bpf_cast_to_kern_ctx])
^ ~~~~~~~~~~~~~~~~~~~~~~~
/.../kernel/bpf/verifier.c:8174:1: note: array 'special_kfunc_list' declared here
BTF_ID_LIST(special_kfunc_list)
^
/.../include/linux/btf_ids.h:207:27: note: expanded from macro 'BTF_ID_LIST'
#define BTF_ID_LIST(name) static u32 __maybe_unused name[5];
^
/.../kernel/bpf/verifier.c:8443:19: error: array index 5 is past the end of the array
(that has type 'u32[5]' (aka 'unsigned int[5]')) [-Werror,-Warray-bounds]
btf_id == special_kfunc_list[KF_bpf_list_pop_back];
^ ~~~~~~~~~~~~~~~~~~~~
/.../kernel/bpf/verifier.c:8174:1: note: array 'special_kfunc_list' declared here
BTF_ID_LIST(special_kfunc_list)
^
/.../include/linux/btf_ids.h:207:27: note: expanded from macro 'BTF_ID_LIST'
#define BTF_ID_LIST(name) static u32 __maybe_unused name[5];
...
Fix the problem by increase the size of BTF_ID_LIST to 16 to avoid compilation error
and also prevent potentially unintended issue due to out-of-bound access.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <error27@gmail.com>
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/r/20221123155759.2669749-1-yhs@fb.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
include/linux/btf_ids.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/btf_ids.h b/include/linux/btf_ids.h
index 2aea877d644f..2b9872008428 100644
--- a/include/linux/btf_ids.h
+++ b/include/linux/btf_ids.h
@@ -204,7 +204,7 @@ extern struct btf_id_set8 name;
#else
-#define BTF_ID_LIST(name) static u32 __maybe_unused name[5];
+#define BTF_ID_LIST(name) static u32 __maybe_unused name[16];
#define BTF_ID(prefix, name)
#define BTF_ID_FLAGS(prefix, name, ...)
#define BTF_ID_UNUSED
--
2.35.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH AUTOSEL 6.0 48/73] bpf: Prevent decl_tag from being referenced in func_proto arg
[not found] <20221218160741.927862-1-sashal@kernel.org>
` (2 preceding siblings ...)
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 47/73] bpf: Fix a BTF_ID_LIST bug with CONFIG_DEBUG_INFO_BTF not set Sasha Levin
@ 2022-12-18 16:07 ` Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 58/73] libbpf: Avoid enum forward-declarations in public API in C++ mode Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 63/73] selftests/bpf: Fix conflicts with built-in functions in bpf_iter_ksym Sasha Levin
5 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2022-12-18 16:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Stanislav Fomichev, syzbot+8dd0551dda6020944c5d, Daniel Borkmann,
Yonghong Song, Sasha Levin, martin.lau, ast, andrii, bpf
From: Stanislav Fomichev <sdf@google.com>
[ Upstream commit f17472d4599697d701aa239b4c475a506bccfd19 ]
Syzkaller managed to hit another decl_tag issue:
btf_func_proto_check kernel/bpf/btf.c:4506 [inline]
btf_check_all_types kernel/bpf/btf.c:4734 [inline]
btf_parse_type_sec+0x1175/0x1980 kernel/bpf/btf.c:4763
btf_parse kernel/bpf/btf.c:5042 [inline]
btf_new_fd+0x65a/0xb00 kernel/bpf/btf.c:6709
bpf_btf_load+0x6f/0x90 kernel/bpf/syscall.c:4342
__sys_bpf+0x50a/0x6c0 kernel/bpf/syscall.c:5034
__do_sys_bpf kernel/bpf/syscall.c:5093 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5091 [inline]
__x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5091
do_syscall_64+0x54/0x70 arch/x86/entry/common.c:48
This seems similar to commit ea68376c8bed ("bpf: prevent decl_tag from being
referenced in func_proto") but for the argument.
Reported-by: syzbot+8dd0551dda6020944c5d@syzkaller.appspotmail.com
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20221123035422.872531-2-sdf@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
kernel/bpf/btf.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
index 0d23d4bcd81c..44e93c3abebd 100644
--- a/kernel/bpf/btf.c
+++ b/kernel/bpf/btf.c
@@ -4481,6 +4481,11 @@ static int btf_func_proto_check(struct btf_verifier_env *env,
break;
}
+ if (btf_type_is_resolve_source_only(arg_type)) {
+ btf_verifier_log_type(env, t, "Invalid arg#%u", i + 1);
+ return -EINVAL;
+ }
+
if (args[i].name_off &&
(!btf_name_offset_valid(btf, args[i].name_off) ||
!btf_name_valid_identifier(btf, args[i].name_off))) {
--
2.35.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH AUTOSEL 6.0 58/73] libbpf: Avoid enum forward-declarations in public API in C++ mode
[not found] <20221218160741.927862-1-sashal@kernel.org>
` (3 preceding siblings ...)
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 48/73] bpf: Prevent decl_tag from being referenced in func_proto arg Sasha Levin
@ 2022-12-18 16:07 ` Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 63/73] selftests/bpf: Fix conflicts with built-in functions in bpf_iter_ksym Sasha Levin
5 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2022-12-18 16:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: Andrii Nakryiko, Daniel Borkmann, Sasha Levin, ast, bpf
From: Andrii Nakryiko <andrii@kernel.org>
[ Upstream commit b42693415b86f608049cf1b4870adc1dc65e58b0 ]
C++ enum forward declarations are fundamentally not compatible with pure
C enum definitions, and so libbpf's use of `enum bpf_stats_type;`
forward declaration in libbpf/bpf.h public API header is causing C++
compilation issues.
More details can be found in [0], but it comes down to C++ supporting
enum forward declaration only with explicitly specified backing type:
enum bpf_stats_type: int;
In C (and I believe it's a GCC extension also), such forward declaration
is simply:
enum bpf_stats_type;
Further, in Linux UAPI this enum is defined in pure C way:
enum bpf_stats_type { BPF_STATS_RUN_TIME = 0; }
And even though in both cases backing type is int, which can be
confirmed by looking at DWARF information, for C++ compiler actual enum
definition and forward declaration are incompatible.
To eliminate this problem, for C++ mode define input argument as int,
which makes enum unnecessary in libbpf public header. This solves the
issue and as demonstrated by next patch doesn't cause any unwanted
compiler warnings, at least with default warnings setting.
[0] https://stackoverflow.com/questions/42766839/c11-enum-forward-causes-underlying-type-mismatch
[1] Closes: https://github.com/libbpf/libbpf/issues/249
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20221130200013.2997831-1-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/lib/bpf/bpf.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 9c50beabdd14..fddc05c667b5 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -393,8 +393,15 @@ LIBBPF_API int bpf_task_fd_query(int pid, int fd, __u32 flags, char *buf,
__u32 *buf_len, __u32 *prog_id, __u32 *fd_type,
__u64 *probe_offset, __u64 *probe_addr);
+#ifdef __cplusplus
+/* forward-declaring enums in C++ isn't compatible with pure C enums, so
+ * instead define bpf_enable_stats() as accepting int as an input
+ */
+LIBBPF_API int bpf_enable_stats(int type);
+#else
enum bpf_stats_type; /* defined in up-to-date linux/bpf.h */
LIBBPF_API int bpf_enable_stats(enum bpf_stats_type type);
+#endif
struct bpf_prog_bind_opts {
size_t sz; /* size of this struct for forward/backward compatibility */
--
2.35.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* [PATCH AUTOSEL 6.0 63/73] selftests/bpf: Fix conflicts with built-in functions in bpf_iter_ksym
[not found] <20221218160741.927862-1-sashal@kernel.org>
` (4 preceding siblings ...)
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 58/73] libbpf: Avoid enum forward-declarations in public API in C++ mode Sasha Levin
@ 2022-12-18 16:07 ` Sasha Levin
5 siblings, 0 replies; 6+ messages in thread
From: Sasha Levin @ 2022-12-18 16:07 UTC (permalink / raw)
To: linux-kernel, stable
Cc: James Hilliard, Andrii Nakryiko, Alexei Starovoitov, Sasha Levin,
daniel, shuah, yhs, alan.maguire, bpf, linux-kselftest
From: James Hilliard <james.hilliard1@gmail.com>
[ Upstream commit ab0350c743d5c93fd88742f02b3dff12168ab435 ]
Both tolower and toupper are built in c functions, we should not
redefine them as this can result in a build error.
Fixes the following errors:
progs/bpf_iter_ksym.c:10:20: error: conflicting types for built-in function 'tolower'; expected 'int(int)' [-Werror=builtin-declaration-mismatch]
10 | static inline char tolower(char c)
| ^~~~~~~
progs/bpf_iter_ksym.c:5:1: note: 'tolower' is declared in header '<ctype.h>'
4 | #include <bpf/bpf_helpers.h>
+++ |+#include <ctype.h>
5 |
progs/bpf_iter_ksym.c:17:20: error: conflicting types for built-in function 'toupper'; expected 'int(int)' [-Werror=builtin-declaration-mismatch]
17 | static inline char toupper(char c)
| ^~~~~~~
progs/bpf_iter_ksym.c:17:20: note: 'toupper' is declared in header '<ctype.h>'
See background on this sort of issue:
https://stackoverflow.com/a/20582607
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12213
(C99, 7.1.3p1) "All identifiers with external linkage in any of the
following subclauses (including the future library directions) are
always reserved for use as identifiers with external linkage."
This is documented behavior in GCC:
https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-std-2
Signed-off-by: James Hilliard <james.hilliard1@gmail.com>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20221203010847.2191265-1-james.hilliard1@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
tools/testing/selftests/bpf/progs/bpf_iter_ksym.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/bpf_iter_ksym.c b/tools/testing/selftests/bpf/progs/bpf_iter_ksym.c
index 285c008cbf9c..9ba14c37bbcc 100644
--- a/tools/testing/selftests/bpf/progs/bpf_iter_ksym.c
+++ b/tools/testing/selftests/bpf/progs/bpf_iter_ksym.c
@@ -7,14 +7,14 @@ char _license[] SEC("license") = "GPL";
unsigned long last_sym_value = 0;
-static inline char tolower(char c)
+static inline char to_lower(char c)
{
if (c >= 'A' && c <= 'Z')
c += ('a' - 'A');
return c;
}
-static inline char toupper(char c)
+static inline char to_upper(char c)
{
if (c >= 'a' && c <= 'z')
c -= ('a' - 'A');
@@ -54,7 +54,7 @@ int dump_ksym(struct bpf_iter__ksym *ctx)
type = iter->type;
if (iter->module_name[0]) {
- type = iter->exported ? toupper(type) : tolower(type);
+ type = iter->exported ? to_upper(type) : to_lower(type);
BPF_SEQ_PRINTF(seq, "0x%llx %c %s [ %s ] ",
value, type, iter->name, iter->module_name);
} else {
--
2.35.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-12-18 16:34 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20221218160741.927862-1-sashal@kernel.org>
2022-12-18 16:06 ` [PATCH AUTOSEL 6.0 20/73] bpf: make sure skb->len != 0 when redirecting to a tunneling device Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 46/73] ppp: associate skb with a device at tx Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 47/73] bpf: Fix a BTF_ID_LIST bug with CONFIG_DEBUG_INFO_BTF not set Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 48/73] bpf: Prevent decl_tag from being referenced in func_proto arg Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 58/73] libbpf: Avoid enum forward-declarations in public API in C++ mode Sasha Levin
2022-12-18 16:07 ` [PATCH AUTOSEL 6.0 63/73] selftests/bpf: Fix conflicts with built-in functions in bpf_iter_ksym Sasha Levin
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox