[also Cc: bpf maintainers and get_maintainer output]
On Thu, May 23, 2024 at 07:52:22PM +0300, Marcel wrote:
> This seems that it was a long standing problem with the Linux kernel in
> general. bpf_probe_read should have worked for both kernel and user pointers
> but it fails with access error
On Tue, 5 Jan 2021, Cong Wang wrote:
> On Mon, Jan 4, 2021 at 7:29 AM Alan Maguire wrote:
> >
> > BPF Type Format (BTF) provides a description of kernel data structures
> > and of the types kernel functions utilize as arguments and return values.
> >
> > A helper was recently added -
On Mon, Jan 4, 2021 at 7:29 AM Alan Maguire wrote:
>
> BPF Type Format (BTF) provides a description of kernel data structures
> and of the types kernel functions utilize as arguments and return values.
>
> A helper was recently added - bpf_snprintf_btf() - that uses that
> description to create a
break;
> +
> + buf_offset = >buf[trace->buf_len];
> + if (buf_offset > >buf[MAX_TRACE_BUF]) {
> + currdata->err_type_id = currtrace->type_id;
> + currdata->err = -ENOSPC;
> +
BPF Type Format (BTF) provides a description of kernel data structures
and of the types kernel functions utilize as arguments and return values.
A helper was recently added - bpf_snprintf_btf() - that uses that
description to create a string representation of the data provided,
using the BTF id
>
>>> Type verification and size resolution is only doing an added resolution of
>>> new
>>> split BTF types and relies on already cached size and type resolution
>>> results
>>> in the base BTF.
>>>
>>> Signed-off-by: Andrii Nakry
nd relies on already cached size and type resolution
> > results
> > in the base BTF.
> >
> > Signed-off-by: Andrii Nakryiko
> > ---
> > kernel/bpf/btf.c | 171 +++++++++--
> > 1 file changed, 119 insertions(+), 52 deletions(-)
&
logic is kept without changes.
>
> Type verification and size resolution is only doing an added resolution of new
> split BTF types and relies on already cached size and type resolution results
> in the base BTF.
>
> Signed-off-by: Andrii Nakryiko
> ---
> kernel/bpf/btf.c | 1
split BTF types and relies on already cached size and type resolution results
in the base BTF.
Signed-off-by: Andrii Nakryiko
---
kernel/bpf/btf.c | 171 +--
1 file changed, 119 insertions(+), 52 deletions(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf
split BTF types and relies on already cached size and type resolution results
in the base BTF.
Signed-off-by: Andrii Nakryiko
---
kernel/bpf/btf.c | 171 +--
1 file changed, 119 insertions(+), 52 deletions(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf
On Fri, Nov 6, 2020 at 5:28 PM Song Liu wrote:
>
>
>
> > On Nov 6, 2020, at 3:02 PM, Andrii Nakryiko wrote:
> >
> > Adjust in-kernel BTF implementation to support a split BTF mode of
> > operation.
> > Changes are mostly mirroring libbpf split BTF changes, with the exception of
> > start_id
> On Nov 6, 2020, at 3:02 PM, Andrii Nakryiko wrote:
>
> Adjust in-kernel BTF implementation to support a split BTF mode of operation.
> Changes are mostly mirroring libbpf split BTF changes, with the exception of
> start_id being 0 for in-kernel implementation due to simpler read-only mode.
split BTF types and relies on already cached size and type resolution results
in the base BTF.
Signed-off-by: Andrii Nakryiko
---
kernel/bpf/btf.c | 182 +--
1 file changed, 130 insertions(+), 52 deletions(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf
split BTF types and relies on already cached size and type resolution results
in the base BTF.
Signed-off-by: Andrii Nakryiko
---
kernel/bpf/btf.c | 182 +--
1 file changed, 130 insertions(+), 52 deletions(-)
diff --git a/kernel/bpf/btf.c b/kernel/bpf
Resolve issues in bpf selftests introduced with BTF-based kernel data
display selftests; these are
- a warning introduced in snprintf_btf.c; and
- compilation failures with old kernels vmlinux.h
Alan Maguire (2):
selftests/bpf: fix unused-result warning in snprintf_btf.c
selftests/bpf:
From: dihu
[ Upstream commit 487082fb7bd2a32b66927d2b22e3a81b072b44f0 ]
When user application calls read() with MSG_PEEK flag to read data
of bpf sockmap socket, kernel panic happens at
__tcp_bpf_recvmsg+0x12c/0x350. sk_msg is not removed from ingress_msg
queue after read out under MSG_PEEK
From: dihu
[ Upstream commit 487082fb7bd2a32b66927d2b22e3a81b072b44f0 ]
When user application calls read() with MSG_PEEK flag to read data
of bpf sockmap socket, kernel panic happens at
__tcp_bpf_recvmsg+0x12c/0x350. sk_msg is not removed from ingress_msg
queue after read out under MSG_PEEK
From: dihu
[ Upstream commit 487082fb7bd2a32b66927d2b22e3a81b072b44f0 ]
When user application calls read() with MSG_PEEK flag to read data
of bpf sockmap socket, kernel panic happens at
__tcp_bpf_recvmsg+0x12c/0x350. sk_msg is not removed from ingress_msg
queue after read out under MSG_PEEK
From: dihu
[ Upstream commit 487082fb7bd2a32b66927d2b22e3a81b072b44f0 ]
When user application calls read() with MSG_PEEK flag to read data
of bpf sockmap socket, kernel panic happens at
__tcp_bpf_recvmsg+0x12c/0x350. sk_msg is not removed from ingress_msg
queue after read out under MSG_PEEK
On Fri, May 29, 2020 at 11:05 AM CEST, dihu wrote:
> On 2020/5/27 5:10, John Fastabend wrote:
>> dihu wrote:
>>> From 865a45747de6b68fd02a0ff128a69a5c8feb73c3 Mon Sep 17 00:00:00 2001
>>> From: dihu
>>> Date: Mon, 25 May 2020 17:23:16 +0800
>>> S
On 2020/5/27 5:10, John Fastabend wrote:
dihu wrote:
From 865a45747de6b68fd02a0ff128a69a5c8feb73c3 Mon Sep 17 00:00:00 2001
From: dihu
Date: Mon, 25 May 2020 17:23:16 +0800
Subject: [PATCH] bpf/sockmap: fix kernel panic at __tcp_bpf_recvmsg
When user application calls read() with MSG_PEEK
dihu wrote:
> From 865a45747de6b68fd02a0ff128a69a5c8feb73c3 Mon Sep 17 00:00:00 2001
> From: dihu
> Date: Mon, 25 May 2020 17:23:16 +0800
> Subject: [PATCH] bpf/sockmap: fix kernel panic at __tcp_bpf_recvmsg
>
> When user application calls read() with MSG_PEEK flag to read dat
On Mon, Sep 18, 2000 at 10:55:20PM -0700, Philippe Troin <[EMAIL PROTECTED]> wrote:
> Ideally, libpcap should be extended to support the LPFisms. A LSF
Indeed, and I sent a patch to do so about 4 weeks after LSF was in the
kernel, but nothing happened so far. ("Hey, the -s option suddenly works
On Mon, Sep 18, 2000 at 10:55:20PM -0700, Philippe Troin [EMAIL PROTECTED] wrote:
Ideally, libpcap should be extended to support the LPFisms. A LSF
Indeed, and I sent a patch to do so about 4 weeks after LSF was in the
kernel, but nothing happened so far. ("Hey, the -s option suddenly works ;")
kjh63 <[EMAIL PROTECTED]> writes:
> > How Linux Kernel and BPF relate to each other:
> >
> > a) linux has BPF (I don't think so).
It has LSF, the Linux Socket Filter.
> > b) Linux has own equivalent of BPF (part of NAT?)
Yes, the LSF.
> > c) linux does not
> How Linux Kernel and BPF relate to each other:
>
> a) linux has BPF (I don't think so).
> b) Linux has own equivalent of BPF (part of NAT?)
> c) linux does not have anything like BPF
> d) something else (if so, then what?)
a) The Documentation/networking/filters.txt may say s
kjh63 [EMAIL PROTECTED] writes:
How Linux Kernel and BPF relate to each other:
a) linux has BPF (I don't think so).
It has LSF, the Linux Socket Filter.
b) Linux has own equivalent of BPF (part of NAT?)
Yes, the LSF.
c) linux does not have anything like BPF
BPF opcodes works
27 matches
Mail list logo
