On 4/27/24 8:18 AM, Florian Lehner wrote:
Add new field "cpu_entry" to bpf_perf_event_data which could be read by
bpf programs attached to perf events. The value contains the CPU value
recorded by specifying sample_type with PERF_SAMPLE_CPU when calling
perf_event_open().
You can use
On 4/27/24 9:34 AM, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:443574b03387 riscv, bpf: Fix kfunc parameters incompatibil..
git tree: bpf
console output: https://syzkaller.appspot.com/x/log.txt?x=11ca8fe718
kernel config:
On 12/20/23 1:19 AM, Hou Tao wrote:
Hi,
On 12/14/2023 11:40 AM, xingwei lee wrote:
Hello I found a bug in net/bpf in the lastest upstream linux and
comfired in the lastest net tree and lastest net bpf titled BUG:
unable to handle kernel paging request in bpf_probe_read_compat_str
If you fix
On 11/21/23 7:50 PM, Edward Adam Davis wrote:
Confirm that skb->len is not 0 to ensure that skb length is valid.
Fixes: 114039b34201 ("bpf: Move skb->len == 0 checks into __bpf_redirect")
Reported-by: syzbot+e2c932aec5c8a6e1d...@syzkaller.appspotmail.com
Signed-off-by: Edward Adam Davis
Signed-off-by: Samuel Mendoza-Jonas
Reviewed-by: Frank van der Linden
Reviewed-by: Ethan Chen
Just to be clear, the patch is for 4.14 stable branch.
Acked-by: Yonghong Song
M although I see some tools Makefile directly added
".DELETE_ON_ERROR:" in their Makefile.
Acked-by: Yonghong Song
On 4/9/21 2:20 PM, Sergei Trofimovich wrote:
On Tue, 23 Feb 2021 18:53:21 +
Sergei Trofimovich wrote:
The crash seems to be related to sock_filter-v test from strace:
https://github.com/strace/strace/blob/master/tests/seccomp-filter-v.c
Here is an OOps:
[ 818.089904] BUG: Bad
On 4/1/21 3:05 PM, Yonghong Song wrote:
On 4/1/21 4:29 AM, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit: 36e79851 libbpf: Preserve empty DATASEC BTFs during
static..
git tree: bpf-next
console output:
https://syzkaller.appspot.com/x/log.txt?x
On 4/1/21 4:29 AM, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit:36e79851 libbpf: Preserve empty DATASEC BTFs during static..
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=1569bb06d0
kernel config:
On 3/19/21 12:21 AM, Daniel Borkmann wrote:
On 3/19/21 3:11 AM, Piotr Krysiuk wrote:
Hi Daniel,
On Fri, Mar 19, 2021 at 12:16 AM Stephen Rothwell
wrote:
diff --cc kernel/bpf/verifier.c
index 44e4ec1640f1,f9096b049cd6..
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
On 3/18/21 8:45 PM, Jisheng Zhang wrote:
Hi,
When trying the latest 5.12-rc3 with both LTO_CLANG_THIN and DEBUG_INFO_BTF
enabled, I met lots of warnings such as:
...
tag__recode_dwarf_type: couldn't find 0x4a7ade5 type for 0x4ab9f88
(subroutine_type)!
ftype__recode_dwarf_types: couldn't
On 3/15/21 6:29 AM, Pedro Tammela wrote:
This seems to be a reminiscent from the hashmap tests.
Signed-off-by: Pedro Tammela
Acked-by: Yonghong Song
On 3/10/21 3:48 AM, Florent Revest wrote:
On Wed, Mar 10, 2021 at 6:16 AM Yonghong Song wrote:
On 3/9/21 7:43 PM, Yonghong Song wrote:
On 3/9/21 5:54 PM, Florent Revest wrote:
I noticed that initializing an array of pointers using this syntax:
__u64 array[] = { (__u64), (__u64) };
(which
On 3/9/21 7:43 PM, Yonghong Song wrote:
On 3/9/21 5:54 PM, Florent Revest wrote:
I noticed that initializing an array of pointers using this syntax:
__u64 array[] = { (__u64), (__u64) };
(which is a fairly common operation with macros such as BPF_SEQ_PRINTF)
always results in array[0
On 3/9/21 5:54 PM, Florent Revest wrote:
I noticed that initializing an array of pointers using this syntax:
__u64 array[] = { (__u64), (__u64) };
(which is a fairly common operation with macros such as BPF_SEQ_PRINTF)
always results in array[0] and array[1] being NULL.
Interestingly, if the
On 3/2/21 11:52 PM, Jiapeng Chong wrote:
Fix the following coccicheck warnings:
./tools/testing/selftests/bpf/test_sockmap.c:735:35-37: WARNING !A || A
&& B is equivalent to !A || B.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
Acked-by: Yonghong Song
On 3/2/21 11:20 PM, Jiapeng Chong wrote:
Fix the following coccicheck warnings:
./tools/bpf/bpf_dbg.c:1201:55-57: WARNING !A || A && B is equivalent to
!A || B.
Reported-by: Abaci Robot
Signed-off-by: Jiapeng Chong
Acked-by: Yonghong Song
On 2/23/21 2:28 PM, Song Liu wrote:
To access per-task data, BPF programs usually creates a hash table with
pid as the key. This is not ideal because:
1. The user need to estimate the proper size of the hash table, which may
be inaccurate;
2. Big hash tables are slow;
3. To clean
On 2/8/21 11:35 PM, Dmitry Vyukov wrote:
On Sun, Feb 7, 2021 at 1:20 PM syzbot
wrote:
Hello,
syzbot found the following issue on:
HEAD commit:73d62e81 kmsan: random: prevent boot-time reports in _mix_..
git tree: https://github.com/google/kmsan.git master
console output:
On 2/6/21 11:44 AM, Sedat Dilek wrote:
On Sat, Feb 6, 2021 at 8:33 PM Yonghong Song wrote:
On 2/6/21 11:28 AM, Sedat Dilek wrote:
On Sat, Feb 6, 2021 at 8:22 PM Sedat Dilek wrote:
On Sat, Feb 6, 2021 at 8:17 PM Yonghong Song wrote:
On 2/6/21 10:10 AM, Sedat Dilek wrote:
On Sat
On 2/6/21 11:28 AM, Sedat Dilek wrote:
On Sat, Feb 6, 2021 at 8:22 PM Sedat Dilek wrote:
On Sat, Feb 6, 2021 at 8:17 PM Yonghong Song wrote:
On 2/6/21 10:10 AM, Sedat Dilek wrote:
On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song wrote:
On 2/6/21 8:24 AM, Mark Wieelard wrote:
Hi
On 2/6/21 10:10 AM, Sedat Dilek wrote:
On Sat, Feb 6, 2021 at 6:53 PM Yonghong Song wrote:
On 2/6/21 8:24 AM, Mark Wieelard wrote:
Hi,
On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote:
With the above vmlinux, the issue appears to be handling
DW_ATE_signed_1
On 2/6/21 8:24 AM, Mark Wieelard wrote:
Hi,
On Sat, Feb 06, 2021 at 12:26:44AM -0800, Yonghong Song wrote:
With the above vmlinux, the issue appears to be handling
DW_ATE_signed_1, DW_ATE_unsigned_{1,24,40}.
The following patch should fix the issue:
That doesn't really make sense to me
Song wrote:
On 2/5/21 12:31 PM, Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
On 2/5/21 11:06 AM, Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 7:53
On 2/5/21 12:31 PM, Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 9:03 PM Yonghong Song wrote:
On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
On 2/5/21 11:06 AM, Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 7:53 PM Sedat
On 2/5/21 11:24 AM, Arnaldo Carvalho de Melo wrote:
Em Fri, Feb 05, 2021 at 11:10:08AM -0800, Yonghong Song escreveu:
On 2/5/21 11:06 AM, Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek wrote:
Grepping through linux.git/tools I guess some BTF tools/libs need to
know what
On 2/5/21 11:15 AM, Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 8:10 PM Yonghong Song wrote:
On 2/5/21 11:06 AM, Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 6:48 PM Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 4:28 PM Arnaldo Carvalho de
On 2/5/21 11:06 AM, Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 7:53 PM Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 6:48 PM Sedat Dilek wrote:
On Fri, Feb 5, 2021 at 4:28 PM Arnaldo Carvalho de Melo
wrote:
Em Fri, Feb 05, 2021 at 04:23:59PM +0100, Sedat Dilek escreveu:
On Fri, Feb 5,
assembly.
Suggested-by: John Fastabend
Signed-off-by: Brendan Jackman
Ack with a nit below.
Acked-by: Yonghong Song
---
Difference from v2->v3 [1]:
* Fixed missing ENABLE_ATOMICS_TESTS check.
Difference from v1->v2:
* Reworked commit message to clarify this only affects
On 1/26/21 12:52 PM, Jiri Olsa wrote:
On Thu, Jan 14, 2021 at 07:47:20PM -0800, Alexei Starovoitov wrote:
On Thu, Jan 14, 2021 at 3:44 PM Yonghong Song wrote:
On 1/14/21 2:02 PM, Jiri Olsa wrote:
On Thu, Jan 14, 2021 at 01:05:33PM -0800, Yonghong Song wrote:
On 1/14/21 12:01 PM
ep] Error 1
make[2]: *** [Makefile:156: all] Error 2
With #ifndef __SANE_USERSPACE_TYPES__ in tools/include/linux/types.h,
the above error has gone and this ifndef change does not hurt other
compilations.
Signed-off-by: Tiezhu Yang
Acked-by: Yonghong Song
On 1/22/21 7:34 AM, Florent Revest wrote:
On Wed, Jan 20, 2021 at 8:06 PM Florent Revest wrote:
On Wed, Jan 20, 2021 at 8:04 PM Alexei Starovoitov
wrote:
On Wed, Jan 20, 2021 at 9:08 AM KP Singh wrote:
On Tue, Jan 19, 2021 at 5:00 PM Florent Revest wrote:
This builds up on the
this issue to:
commit 8b401f9ed2441ad9e219953927a842d24ed051fc
Author: Yonghong Song
Date: Thu May 23 21:47:45 2019 +
bpf: implement bpf_send_signal() helper
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=123408e750
start commit: 7d68e382 bpf: Permit size-0 datasec
git
-project/llvm/build/install is
not used, BUILD_SHARED_LIBS=OFF is the default option [2], so also change
Documentation/bpf/bpf_devel_QA.rst together.
[1] https://clang.llvm.org/get_started.html
[2] https://www.llvm.org/docs/CMake.html
Signed-off-by: Tiezhu Yang
Acked-by: Yonghong Song
Reviewed
and it is proved to be feasible, so we should
update README.rst to reflect the reality. At the same time, update the
related comment in Makefile.
[1]
https://clang.llvm.org/get_started.html
Signed-off-by: Tiezhu Yang
Acked-by: Yonghong Song
---
v2: Update the commit message suggested
On 1/19/21 4:22 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
Acked-by: Yonghong Song
] https://clang.llvm.org/get_started.html
Signed-off-by: Tiezhu Yang
Ack with minor nits in the above. Also, this is a documentation update.
I think it is okay to target the patch to bpf-next instead of bpf.
Acked-by: Yonghong Song
On 1/17/21 7:22 PM, Tiezhu Yang wrote:
On 01/14/2021 01:12 AM, Yonghong Song wrote:
On 1/13/21 2:57 AM, Tiezhu Yang wrote:
MIPS needs __SANE_USERSPACE_TYPES__ before to select
'int-ll64.h' in arch/mips/include/uapi/asm/types.h and avoid compile
warnings when printing __u64 with %llu
On 1/18/21 12:53 AM, Tiezhu Yang wrote:
In the current samples/bpf/README.rst, the url of llvm and clang git
may be out of date, they are unable to access:
$ git clone http://llvm.org/git/llvm.git
Cloning into 'llvm'...
fatal: unable to access 'http://llvm.org/git/llvm.git/ ': Maximum (20)
On 1/18/21 4:18 AM, Qais Yousef wrote:
On 01/16/21 18:11, Yonghong Song wrote:
On 1/16/21 10:21 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod
/#m07264fc18fdc43af02fc1320968afefcc73d96f4
Signed-off-by: Brendan Jackman
Thanks for better description!
Acked-by: Yonghong Song
On 1/16/21 10:21 AM, Qais Yousef wrote:
Reuse module_attach infrastructure to add a new bare tracepoint to check
we can attach to it as a raw tracepoint.
Signed-off-by: Qais Yousef
---
.../bpf/bpf_testmod/bpf_testmod-events.h | 6 +
.../selftests/bpf/bpf_testmod/bpf_testmod.c
about any ABI.
Update Documentation/bpf/bpf_design_QA.rst to document this contract.
Signed-off-by: Qais Yousef
Acked-by: Yonghong Song
On 1/15/21 5:12 PM, Song Liu wrote:
On Jan 15, 2021, at 4:55 PM, Yonghong Song wrote:
On 1/15/21 3:34 PM, Song Liu wrote:
On Jan 12, 2021, at 8:53 AM, KP Singh wrote:
On Tue, Jan 12, 2021 at 5:32 PM Yonghong Song wrote:
On 1/11/21 3:45 PM, Song Liu wrote:
On Jan 11, 2021
On 1/15/21 3:34 PM, Song Liu wrote:
On Jan 12, 2021, at 8:53 AM, KP Singh wrote:
On Tue, Jan 12, 2021 at 5:32 PM Yonghong Song wrote:
On 1/11/21 3:45 PM, Song Liu wrote:
On Jan 11, 2021, at 1:58 PM, Martin Lau wrote:
On Mon, Jan 11, 2021 at 10:35:43PM +0100, KP Singh wrote
On 1/15/21 3:34 PM, Nick Desaulniers wrote:
On Fri, Jan 15, 2021 at 3:24 PM Yonghong Song wrote:
On 1/15/21 1:53 PM, Sedat Dilek wrote:
En plus, I encountered breakage with GCC v10.2.1 and LLVM=1 and
CONFIG_DEBUG_INFO_DWARF4.
So might be good to add a "depends on !DEBUG_INF
On 1/15/21 1:53 PM, Sedat Dilek wrote:
On Fri, Jan 15, 2021 at 10:06 PM Nick Desaulniers
wrote:
DWARF v5 is the latest standard of the DWARF debug info format.
DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).
Link:
On 1/14/21 2:02 PM, Jiri Olsa wrote:
On Thu, Jan 14, 2021 at 01:05:33PM -0800, Yonghong Song wrote:
On 1/14/21 12:01 PM, Jiri Olsa wrote:
On Thu, Jan 14, 2021 at 10:56:33AM -0800, Yonghong Song wrote:
On 1/14/21 5:40 AM, Jiri Olsa wrote:
It's possible to have other build id types
On 1/14/21 12:01 PM, Jiri Olsa wrote:
On Thu, Jan 14, 2021 at 10:56:33AM -0800, Yonghong Song wrote:
On 1/14/21 5:40 AM, Jiri Olsa wrote:
It's possible to have other build id types (other than default SHA1).
Currently there's also ld support for MD5 build id.
Currently, bpf build_id
On 1/14/21 5:40 AM, Jiri Olsa wrote:
It's possible to have other build id types (other than default SHA1).
Currently there's also ld support for MD5 build id.
Currently, bpf build_id based stackmap does not returns the size of
the build_id. Did you see an issue here? I guess user space can
On 1/13/21 2:36 PM, Ian Rogers wrote:
No additional warnings are generated by enabling this, but having it
enabled will help avoid regressions.
Signed-off-by: Ian Rogers
Acked-by: Yonghong Song
On 1/13/21 2:36 PM, Ian Rogers wrote:
Add inline to __always_inline making it match the linux/compiler.h.
Adding this avoids an unused function warning on bpf_tail_call_static
when compining with -Wall.
Signed-off-by: Ian Rogers
Acked-by: Yonghong Song
On 1/13/21 2:57 AM, Tiezhu Yang wrote:
There exists many build errors and warnings when make M=samples/bpf,
both fixes in this patch related to mips, please do mention in the
commit message that this is
mips related. x86 (and arm64 I assume) compiles just fine.
this patch series fix
On 1/13/21 2:57 AM, Tiezhu Yang wrote:
When make M=samples/bpf on the Loongson 3A3000 platform which
belongs to MIPS arch, there exists many similar build errors
about 'asm/rwonce.h' file not found, so include it only under
CONFIG_ARM64 and CONFIG_ALPHA due to it exists only in arm64
and
On 1/13/21 2:57 AM, Tiezhu Yang wrote:
MIPS needs __SANE_USERSPACE_TYPES__ before to select
'int-ll64.h' in arch/mips/include/uapi/asm/types.h and avoid compile
warnings when printing __u64 with %llu, %llx or %lld.
could you mention which command produces the following warning?
On 1/13/21 2:16 AM, Qais Yousef wrote:
On 01/12/21 12:19, Yonghong Song wrote:
I applied the patch to my local bpf-next repo, and got the following
compilation error:
[...]
I dumped preprecessor result but after macro expansion, the code
becomes really complex and I have not figured out
area pointed by it.
The patch was partially contributed by CyberArk Software, Inc.
Signed-off-by: Gilad Reti
I didn't verify result_unpriv = ACCEPT part. I think it is correct
by checking code.
Acked-by: Yonghong Song
On 1/11/21 10:20 AM, Qais Yousef wrote:
Some subsystems only have bare tracepoints (a tracepoint with no
associated trace event) to avoid the problem of trace events being an
ABI that can't be changed.
From bpf presepective, bare tracepoints are what it calls
RAW_TRACEPOINT().
Since bpf
On 1/12/21 7:43 AM, Daniel Borkmann wrote:
On 1/12/21 4:35 PM, Gilad Reti wrote:
On Tue, Jan 12, 2021 at 4:56 PM KP Singh wrote:
On Tue, Jan 12, 2021 at 10:16 AM Gilad Reti
wrote:
Add test to check that the verifier is able to recognize spilling of
PTR_TO_MEM registers.
It would be
On 1/12/21 4:39 AM, Brendan Jackman wrote:
The error message here is misleading, the argument will be rejected
unless it is a known constant.
Signed-off-by: Brendan Jackman
Okay, this is for bpf_ringbuf_reserve() helper where the size must be a
constant.
Acked-by: Yonghong Song
could also refer to
the length of the input.
Signed-off-by: Brendan Jackman
Acked-by: Yonghong Song
On 1/11/21 3:45 PM, Song Liu wrote:
On Jan 11, 2021, at 1:58 PM, Martin Lau wrote:
On Mon, Jan 11, 2021 at 10:35:43PM +0100, KP Singh wrote:
On Mon, Jan 11, 2021 at 7:57 PM Martin KaFai Lau wrote:
On Fri, Jan 08, 2021 at 03:19:47PM -0800, Song Liu wrote:
[ ... ]
diff --git
On 1/11/21 11:14 PM, Andrii Nakryiko wrote:
On Mon, Jan 11, 2021 at 7:24 PM Yonghong Song wrote:
On 1/11/21 2:54 PM, Song Liu wrote:
On Jan 11, 2021, at 9:49 AM, Yonghong Song wrote:
On 1/8/21 3:19 PM, Song Liu wrote:
Replace hashtab with task local storage in runqslower
On 1/11/21 2:54 PM, Song Liu wrote:
On Jan 11, 2021, at 9:49 AM, Yonghong Song wrote:
On 1/8/21 3:19 PM, Song Liu wrote:
Replace hashtab with task local storage in runqslower. This improves the
performance of these BPF programs. The following table summarizes average
runtime
On 1/8/21 3:19 PM, Song Liu wrote:
Replace hashtab with task local storage in runqslower. This improves the
performance of these BPF programs. The following table summarizes average
runtime of these programs, in nanoseconds:
task-local hash-prealloc
On 1/8/21 3:19 PM, Song Liu wrote:
Update the Makefile to prefer using ../../../vmlinux, which has latest
definitions for vmlinux.h
Signed-off-by: Song Liu
---
tools/bpf/runqslower/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On 1/8/21 3:19 PM, Song Liu wrote:
Task local storage is enabled for tracing programs. Add a test for it
without CONFIG_BPF_LSM.
Signed-off-by: Song Liu
---
.../bpf/prog_tests/test_task_local_storage.c | 34 +
.../selftests/bpf/progs/task_local_storage.c | 37
On 1/8/21 3:19 PM, Song Liu wrote:
To access per-task data, BPF program typically creates a hash table with
pid as the key. This is not ideal because:
1. The use need to estimate requires size of the hash table, with may be
inaccurate;
2. Big hash tables are slow;
3. To clean up
On 1/11/21 2:17 AM, KP Singh wrote:
On Mon, Jan 11, 2021 at 7:27 AM Yonghong Song wrote:
On 1/8/21 3:19 PM, Song Liu wrote:
To access per-task data, BPF program typically creates a hash table with
pid as the key. This is not ideal because:
1. The use need to estimate requires size
On 1/8/21 3:19 PM, Song Liu wrote:
To access per-task data, BPF program typically creates a hash table with
pid as the key. This is not ideal because:
1. The use need to estimate requires size of the hash table, with may be
inaccurate;
2. Big hash tables are slow;
3. To clean up
On 1/7/21 6:08 PM, 彭浩(Richard) wrote:
struct bpf_object *obj is not used in bpf_object__probe_loading, so we
can remove it.
Signed-off-by: Peng Hao
Acked-by: Yonghong Song
the _ExtInt extension enabled in clang, which is under
review.
Link: https://clang.llvm.org/docs/LanguageExtensions.html#extended-integer-types
Link: https://reviews.llvm.org/D93103
Signed-off-by: Sean Young
---
changes since v2:
- added tests as suggested by Yonghong Song
- added kernel pretty-printer
On 12/23/20 11:01 PM, YANG LI wrote:
Assigning local variable txq to the outputting parameter xdp->txq is not
safe, txq will be released after the end of the function call.
Then the result of using xdp is unpredictable.
Fix this error by defining the struct xdp_txq_info in function
On 12/17/20 7:20 PM, Alexei Starovoitov wrote:
On Thu, Dec 17, 2020 at 09:26:09AM -0800, Yonghong Song wrote:
On 12/17/20 7:31 AM, Florent Revest wrote:
On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM
On 12/17/20 7:01 AM, Sean Young wrote:
clang supports arbitrary length ints using the _ExtInt extension. This
can be useful to hold very large values, e.g. 256 bit or 512 bit types.
Larger types (e.g. 1024 bits) are possible but I am unaware of a use
case for these.
This requires the
On 12/17/20 7:31 AM, Florent Revest wrote:
On Mon, Dec 14, 2020 at 7:47 AM Yonghong Song wrote:
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
wrote:
I still think that adopting printk/vsnprintf for this instead of
reinventing the wheel
On 12/16/20 3:51 AM, Brendan Jackman wrote:
On Wed, 16 Dec 2020 at 08:19, Yonghong Song wrote:
On 12/15/20 3:12 AM, Brendan Jackman wrote:
On Tue, Dec 08, 2020 at 10:15:35AM -0800, Yonghong Song wrote:
On 12/8/20 8:59 AM, Brendan Jackman wrote:
On Tue, Dec 08, 2020 at 08:38:04AM
On 12/16/20 3:44 AM, Brendan Jackman wrote:
On Wed, 16 Dec 2020 at 08:08, Yonghong Song wrote:
On 12/15/20 4:18 AM, Brendan Jackman wrote:
Document new atomic instructions.
Signed-off-by: Brendan Jackman
Ack with minor comments below.
Acked-by: Yonghong Song
---
Documentation
On 12/15/20 3:12 AM, Brendan Jackman wrote:
On Tue, Dec 08, 2020 at 10:15:35AM -0800, Yonghong Song wrote:
On 12/8/20 8:59 AM, Brendan Jackman wrote:
On Tue, Dec 08, 2020 at 08:38:04AM -0800, Yonghong Song wrote:
On 12/8/20 4:41 AM, Brendan Jackman wrote:
On Mon, Dec 07, 2020 at 07:18
On 12/15/20 4:18 AM, Brendan Jackman wrote:
Document new atomic instructions.
Signed-off-by: Brendan Jackman
Ack with minor comments below.
Acked-by: Yonghong Song
---
Documentation/networking/filter.rst | 26 ++
1 file changed, 26 insertions(+)
diff --git
Acked-by: Yonghong Song
). That means return-old-value is easier to JIT, so that's
what we use.
Signed-off-by: Brendan Jackman
Ack with a minor comment below.
Acked-by: Yonghong Song
---
arch/x86/net/bpf_jit_comp.c| 8
include/linux/filter.h | 2 ++
include/uapi/linux/bpf.h | 4
On 12/11/20 6:40 AM, Florent Revest wrote:
On Wed, Dec 2, 2020 at 10:18 PM Alexei Starovoitov
wrote:
I still think that adopting printk/vsnprintf for this instead of
reinventing the wheel
is more flexible and easier to maintain long term.
Almost the same layout can be done with vsnprintf
On 12/8/20 8:59 AM, Brendan Jackman wrote:
On Tue, Dec 08, 2020 at 08:38:04AM -0800, Yonghong Song wrote:
On 12/8/20 4:41 AM, Brendan Jackman wrote:
On Mon, Dec 07, 2020 at 07:18:57PM -0800, Yonghong Song wrote:
On 12/7/20 8:07 AM, Brendan Jackman wrote:
The prog_test that's added
On 12/8/20 4:41 AM, Brendan Jackman wrote:
On Mon, Dec 07, 2020 at 07:18:57PM -0800, Yonghong Song wrote:
On 12/7/20 8:07 AM, Brendan Jackman wrote:
The prog_test that's added depends on Clang/LLVM features added by
Yonghong in commit 286daafd6512 (was https://reviews.llvm.org/D72184
On 12/7/20 8:07 AM, Brendan Jackman wrote:
Document new atomic instructions.
Signed-off-by: Brendan Jackman
Ack with minor comments below.
Acked-by: Yonghong Song
---
Documentation/networking/filter.rst | 26 ++
1 file changed, 26 insertions(+)
diff --git
. A variable called skip_tests is
defined in the BPF object's data section, which tells the userspace
object whether to skip the atomics test.
Signed-off-by: Brendan Jackman
Ack with minor comments below.
Acked-by: Yonghong Song
---
tools/testing/selftests/bpf/Makefile | 10
On 12/7/20 8:07 AM, Brendan Jackman wrote:
This adds instructions for
atomic[64]_[fetch_]and
atomic[64]_[fetch_]or
atomic[64]_[fetch_]xor
All these operations are isomorphic enough to implement with the same
verifier, interpreter, and x86 JIT code, hence being a single commit.
The main
On 12/7/20 8:07 AM, Brendan Jackman wrote:
This adds two atomic opcodes, both of which include the BPF_FETCH
flag. XCHG without the BPF_FETCH flag would naturally encode
atomic_set. This is not supported because it would be of limited
value to userspace (it doesn't imply any barriers).
On 12/7/20 8:07 AM, Brendan Jackman wrote:
The BPF_FETCH field can be set in bpf_insn.imm, for BPF_ATOMIC
instructions, in order to have the previous value of the
atomically-modified memory location loaded into the src register
after an atomic op is carried out.
Suggested-by: Yonghong Song
On 12/7/20 8:07 AM, Brendan Jackman wrote:
I can't find a reason why this code is in resolve_pseudo_ldimm64;
since I'll be modifying it in a subsequent commit, tidy it up.
Signed-off-by: Brendan Jackman
Acked-by: Yonghong Song
-next tree is fine
since this is not a correctness issue.
Acked-by: Yonghong Song
On 12/7/20 3:28 AM, Brendan Jackman wrote:
On Fri, Dec 04, 2020 at 07:21:22AM -0800, Yonghong Song wrote:
On 12/4/20 1:36 AM, Brendan Jackman wrote:
On Thu, Dec 03, 2020 at 10:42:19PM -0800, Yonghong Song wrote:
On 12/3/20 8:02 AM, Brendan Jackman wrote:
This adds instructions
On 12/5/20 4:43 PM, Alan Maguire wrote:
On Sat, 5 Dec 2020, Yonghong Song wrote:
__builtin_btf_type_id() is really only supported in llvm12
and 64bit return value support is pushed to llvm12 trunk
a while back. The builtin is introduced in llvm11 but has a
corner bug, so llvm12
On 12/5/20 12:35 PM, Yonghong Song wrote:
On 12/4/20 10:48 AM, Alan Maguire wrote:
This series aims to add support to bpf_snprintf_btf() and
bpf_seq_printf_btf() allowing them to store string representations
of module-specific types, as well as the kernel-specific ones
they currently
On 12/4/20 10:48 AM, Alan Maguire wrote:
This series aims to add support to bpf_snprintf_btf() and
bpf_seq_printf_btf() allowing them to store string representations
of module-specific types, as well as the kernel-specific ones
they currently support.
Patch 1 removes the btf_module_mutex, as
On 12/4/20 1:45 AM, Brendan Jackman wrote:
On Thu, Dec 03, 2020 at 11:06:31PM -0800, Yonghong Song wrote:
On 12/3/20 8:02 AM, Brendan Jackman wrote:
[...]
diff --git a/tools/testing/selftests/bpf/prog_tests/atomics_test.c
b/tools/testing/selftests/bpf/prog_tests/atomics_test.c
new file
On 12/4/20 1:36 AM, Brendan Jackman wrote:
On Thu, Dec 03, 2020 at 10:42:19PM -0800, Yonghong Song wrote:
On 12/3/20 8:02 AM, Brendan Jackman wrote:
This adds instructions for
atomic[64]_[fetch_]and
atomic[64]_[fetch_]or
atomic[64]_[fetch_]xor
All these operations are isomorphic enough
On 12/4/20 1:29 AM, Brendan Jackman wrote:
On Thu, Dec 03, 2020 at 10:30:18PM -0800, Yonghong Song wrote:
On 12/3/20 8:02 AM, Brendan Jackman wrote:
Since the atomic operations that are added in subsequent commits are
all isomorphic with BPF_ADD, pull out a macro to avoid the
interpreter
On 12/3/20 8:02 AM, Brendan Jackman wrote:
This relies on the work done by Yonghong Song in
https://reviews.llvm.org/D72184
Note the use of a define called ENABLE_ATOMICS_TESTS: this is used
to:
- Avoid breaking the build for people on old versions of Clang
- Avoid needing separate
1 - 100 of 378 matches
Mail list logo
