[PATCH] perf stat: Added '--polled-interval-print/-P' mode

5729 25 164 351 653 cycles Signed-off-by: Björn Töpel <bjorn.to...@intel.com> --- tools/perf/builtin-stat.c | 69 --- 1 file changed, 60 insertions(+), 9 deletions(-) diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c ind

[PATCH] perf probe: Fix probe definition for inlined functions

From: Björn Töpel <bjorn.to...@intel.com> In commit 613f050d68a8 ("perf probe: Fix to probe on gcc generated functions in modules"), the offset from symbol is, incorrectly, added to the trace point address. This leads to incorrect probe trace points for inlined functions and whe

Re: [PATCH 2/2] [RFC] packet: experimental support for 64-bit timestamps

2017-11-27 21:51 GMT+01:00 Arnd Bergmann : [...] >> There already is an effort to come up with a new AF_PACKET V4 [1]. >> We should make sure that any new interface does not have the >> Y2038/Y2106 issue. But, if a new version is being developed and >> that subsumes all existing use

Re: x86 boot broken on -rc1?

2017-12-02 1:39 GMT+01:00 Jakub Kicinski : > Hi! > > I'm hitting these after DaveM pulled rc1 into net-next on my Xeon > E5-2630 v4 box. It also happens on linux-next. Did anyone else > experience it? (.config attached) > > [5.003771] WARNING: CPU: 14 PID: 1 at

[PATCH bpf-next] xsk: fix 64-bit division

From: Björn Töpel <bjorn.to...@intel.com> i386 builds report: net/xdp/xdp_umem.o: In function `xdp_umem_reg': xdp_umem.c:(.text+0x47e): undefined reference to `__udivdi3' This fix uses div_u64 instead of the GCC built-in. Fixes: c0c77d8fb787 ("xsk: add user memory registrat

[PATCH bpf-next] xsk: fix 64-bit division

From: Björn Töpel i386 builds report: net/xdp/xdp_umem.o: In function `xdp_umem_reg': xdp_umem.c:(.text+0x47e): undefined reference to `__udivdi3' This fix uses div_u64 instead of the GCC built-in. Fixes: c0c77d8fb787 ("xsk: add user memory registration support sockopt")

Re: [PATCH 2/2] [RFC] packet: experimental support for 64-bit timestamps

2017-11-27 21:51 GMT+01:00 Arnd Bergmann : [...] >> There already is an effort to come up with a new AF_PACKET V4 [1]. >> We should make sure that any new interface does not have the >> Y2038/Y2106 issue. But, if a new version is being developed and >> that subsumes all existing use cases, then

Re: x86 boot broken on -rc1?

2017-12-02 1:39 GMT+01:00 Jakub Kicinski : > Hi! > > I'm hitting these after DaveM pulled rc1 into net-next on my Xeon > E5-2630 v4 box. It also happens on linux-next. Did anyone else > experience it? (.config attached) > > [5.003771] WARNING: CPU: 14 PID: 1 at >

Re: general protection fault in xsk_recvmsg

#syz fix: xsk: Validate socket state in xsk_recvmsg, prior touching socket members

Re: [PATCH bpf-next v5 04/11] bpf: Rename BPF_XADD and prepare to encode other atomics in .imm

bpf_jit_comp.c | 16 +-- > arch/mips/net/ebpf_jit.c | 11 +++-- > arch/powerpc/net/bpf_jit_comp64.c | 25 -- > arch/riscv/net/bpf_jit_comp32.c | 20 ++-- > arch/riscv/net/bpf_jit_comp64.c | 16 +-- For RISC-V: Acked-by: Björn Töpel

Re: memory leak in xskq_create

On 2020-12-16 19:11, Peilin Ye wrote: Hi all, On Sun, Dec 13, 2020 at 06:53:10AM -0800, syzbot wrote: BUG: memory leak unreferenced object 0x88810f897940 (size 64): comm "syz-executor991", pid 8502, jiffies 4294942194 (age 14.080s) hex dump (first 32 bytes): 7f 00 00 00 80 00

Re: [PATCH] xsk: add cq event

On 2020-11-16 09:10, Xuan Zhuo wrote: When we write all cq items to tx, we have to wait for a new event based on poll to indicate that it is writable. But the current writability is triggered based on whether tx is full or not, and In fact, when tx is dissatisfied, the user of cq's item may not

Re: [PATCH] xsk: add cq event

On 2020-11-16 17:12, Xuan Zhuo wrote: On Mon, 16 Nov 2020 15:31:20 +0100, =?UTF-8?B?QmrDtnJuIFTDtnBlbA==?= wrote: On 2020-11-16 09:10, Xuan Zhuo wrote: When we write all cq items to tx, we have to wait for a new event based on poll to indicate that it is writable. But the current

Re: linux-next: ERROR: build error for arm64

On 2020-12-06 08:32, Hui Su wrote: hi, all: The error came out like this when i build the linux-next kernel with ARCH=arm64, with the arm64_defconfig: CC drivers/net/ethernet/freescale/dpaa/dpaa_eth.o ../drivers/net/ethernet/freescale/dpaa/dpaa_eth.c: In function ‘dpaa_fq_init’:

Re: [PATCH] dpaa_eth: fix build errorr in dpaa_fq_init

s Anders! Indeed, when bpf-next is pulled into net-next this needs to be applied. Acked-by: Björn Töpel > drivers/net/ethernet/freescale/dpaa/dpaa_eth.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth.c > b/

Re: [PATCH][next] samples/bpf: Fix spelling mistake "recieving" -> "receiving"

On Thu, 3 Dec 2020 at 12:46, Colin King wrote: > > From: Colin Ian King > > There is a spelling mistake in an error message. Fix it. > > Signed-off-by: Colin Ian King Acked-by: Björn Töpel > --- > samples/bpf/xdpsock_user.c | 2 +- > 1 file changed, 1 insertion

Re: general protection fault in xsk_poll

On 2019-08-20 05:31, Hillf Danton wrote: On Mon, 19 Aug 2019 18:18:06 -0700 Hello, syzbot found the following crash on: HEAD commit:da657043 Add linux-next specific files for 20190819 git tree: linux-next console output: https://syzkaller.appspot.com/x/log.txt?x=16af124c60

[PATCH bpf-next] xsk: proper socket state check in xsk_poll

From: Björn Töpel The poll() implementation for AF_XDP sockets did not perform the proper state checks, prior accessing the socket umem. This patch fixes that by performing a xsk_is_bound() check. Suggested-by: Hillf Danton Reported-by: syzbot+c82697e3043781e08...@syzkaller.appspotmail.com

Re: [PATCH bpf-next] xsk: proper socket state check in xsk_poll

On Tue, 20 Aug 2019 at 16:30, Daniel Borkmann wrote: > > On 8/20/19 12:04 PM, Björn Töpel wrote: > > From: Björn Töpel > > > > The poll() implementation for AF_XDP sockets did not perform the > > proper state checks, prior accessing the socket umem. This patc

Re: [PATCH bpf v2] bpf, riscv: clear high 32 bits for ALU32 add/sub/neg/lsh/rsh/arsh

e destination > > register of 32-bit ALU operations. > > > > Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") > > Cc: Xi Wang > > Signed-off-by: Luke Nelson > > Acked-by: Song Liu > Luke, thanks for fixing this! Nice work! Acked-by: Björn T

Re: [PATCH][next] xsk: Fix null check on error return path

es: 921b68692abb ("xsk: Enable sharing of dma mappings") Signed-off-by: Gustavo A. R. Silva Nice catch! Acked-by: Björn Töpel --- net/xdp/xsk_buff_pool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c index 795d7c8

Re: [PATCH] bpf: validate bpf_func when BPF_JIT is enabled

On 2019-09-11 09:42, Yonghong Song wrote: I am not an expert in XDP testing. Toke, Björn, could you give some suggestions what to test for XDP performance here? I ran the "xdp_rxq_info" sample with and without Sami's patch: $ sudo ./xdp_rxq_info --dev enp134s0f0 --action XDP_DROP Before:

[PATCH] Documentation/features: Refresh the arch support status files

I was manually editing the arch-support.txt for eBPF-JIT, when I realized the refresh script [1] has not been run for a while. Let's fix that, so that the entries are more up-to-date. [1] Documentation/features/scripts/features-refresh.sh Signed-off-by: Björn Töpel --- Documentation/features

[PATCH] Documentation/features: Correct RISC-V kprobes support entry

("Documentation/features: Refresh the arch support status files in place") Signed-off-by: Björn Töpel --- Documentation/features/debug/kprobes/arch-support.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentatio

Re: [PATCH] MAINTAINERS: adjust entry in XDP SOCKETS to actual file name

On 2020-05-25 16:15, Lukas Bulwahn wrote: Commit 2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API") added a new header file include/net/xsk_buff_pool.h, but commit 28bee21dc04b ("MAINTAINERS, xsk: Update AF_XDP section after moves/adds") added a file entry referring to

Re: linux-next: manual merge of the net-next tree with the bpf tree

On 2020-05-26 05:12, Stephen Rothwell wrote: I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also

Re: [PATCH bpf v3] xdp: fix hang while unregistering device bound to xdp socket

On Mon, 10 Jun 2019 at 22:49, Jonathan Lemon wrote: > > On 10 Jun 2019, at 9:15, Ilya Maximets wrote: > > > Device that bound to XDP socket will not have zero refcount until the > > userspace application will not close it. This leads to hang inside > > 'netdev_wait_allrefs()' if device

Re: [PATCH bpf-next] MAINTAINERS: add reviewer to maintainers entry

On 2019-06-25 14:00, Daniel Borkmann wrote: Given it's a doc update, I've applied it to bpf, thanks! Perfect, thanks!

Re: [PATCH] xsk: Properly terminate assignment in xskq_produce_flush_desc

functions and poll support") > > Link: https://github.com/ClangBuiltLinux/linux/issues/544 > > Signed-off-by: Nathan Chancellor > > Nice find. > > Acked-by: Jonathan Lemon > Yikes. Yes, nice find, indeed. Acked-by: Björn Töpel The broader question is &q

Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems

On Wed, 26 Jun 2019 at 17:59, Ivan Khoronzhuk wrote: > > Use kmap instead of page_address as it's not always in low memory. > Ah, some 32-bit love. :-) Thanks for working on this! For future patches, please base AF_XDP patches on the bpf/bpf-next tree instead of net/net-next. Acked-

[PATCH 0/2] perf tools: optional compile time test_attr__* depenency for perf-sys.h

This mini series makes it possible to disable the use of test_attr__* for perf-sys.h users outside perf. E.g., samples/bpf/ uses perf-sys.h as a syscall wrapper. Now a user can define HAVE_ATTR_TEST to zero to avoid this, and as a nice side-effect it also fixes the samples/bpf/ build. ;-) Björn

[PATCH 2/2] samples/bpf: fix build by setting HAVE_ATTR_TEST to zero

From: Björn Töpel To remove that test_attr__{enabled/open} are used by perf-sys.h, we set HAVE_ATTR_TEST to zero. Signed-off-by: Björn Töpel --- samples/bpf/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile index 1d9be26b4edd

[PATCH 1/2] perf tools: Make usage of test_attr__* optional for perf-sys.h

From: Björn Töpel For users of perf-sys.h outside perf, e.g. samples/bpf/bpf_load.c, it's convenient not to depend on test_attr__*. After commit 91854f9a077e ("perf tools: Move everything related to sys_perf_event_open() to perf-sys.h"), all users of perf-sys.h will depend on test_att

Re: [PATCH bpf-next 1/3] libbpf: add asm/unistd.h to xsk to get __NR_mmap2

On Wed, 14 Aug 2019 at 13:57, Ivan Khoronzhuk wrote: > > On Wed, Aug 14, 2019 at 12:24:05PM +0300, Ivan Khoronzhuk wrote: > >On Tue, Aug 13, 2019 at 04:38:13PM -0700, Andrii Nakryiko wrote: > > > >Hi, Andrii > > > >>On Tue, Aug 13, 2019 at 3:24 AM Ivan Khoronzhuk > >> wrote: > >>> > >>>That's

Re: [Intel-wired-lan] [PATCH net] ixgbe: fix double clean of tx descriptors with xdp

On Wed, 21 Aug 2019 at 18:22, Ilya Maximets wrote: > > On 21.08.2019 4:17, Alexander Duyck wrote: > > On Tue, Aug 20, 2019 at 8:58 AM Ilya Maximets > > wrote: > >> > >> On 20.08.2019 18:35, Alexander Duyck wrote: [...] > > > > So is it always in the same NAPI context?. I forgot, I was thinking

Re: [Intel-wired-lan] [PATCH net] ixgbe: fix double clean of tx descriptors with xdp

On Wed, 21 Aug 2019 at 18:57, Alexander Duyck wrote: > > On Wed, Aug 21, 2019 at 9:22 AM Ilya Maximets wrote: > > > > On 21.08.2019 4:17, Alexander Duyck wrote: > > > On Tue, Aug 20, 2019 at 8:58 AM Ilya Maximets > > > wrote: > > >> > > >> On 20.08.2019 18:35, Alexander Duyck wrote: > > >>> On

Re: [PATCH net v3] ixgbe: fix double clean of tx descriptors with xdp

On 2019-08-22 19:32, William Tu wrote: On Thu, Aug 22, 2019 at 10:21 AM Alexander Duyck wrote: On Thu, Aug 22, 2019 at 10:12 AM Ilya Maximets wrote: Tx code doesn't clear the descriptors' status after cleaning. So, if the budget is larger than number of used elems in a ring, some

Re: general protection fault in xsk_map_update_elem

=155a0c2960 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=172bf6d960 The bug was bisected to: commit 0402acd683c678874df6bdbc23530ca07ea19353 Author: Björn Töpel Date: Thu Aug 15 09:30:13 2019 + xsk: remove AF_XDP socket from map when the socket is released Bjorn, PTAL

Re: [PATCH bpf-next v1 3/3] bpf, riscv: Use compressed instructions in the rv64 JIT

c.swa4,52(a0) > 54: dd04c.sws1,56(a0) > 56: 03252e23sw s2,60(a0) > 5a: 05352023sw s3,64(a0) > 5e: 4781c.lia5,0 > 60: 7422c.ldsp s0,40(sp) > 62: 7482c.ldsp s1,32(sp) > 64: 696

Re: [PATCH bpf-next v1 0/3] bpf, riscv: Add compressed instructions to rv64 JIT

0) > 52: d958c.swa4,52(a0) > 54: dd04c.sws1,56(a0) > 56: 03252e23sw s2,60(a0) > 5a: 05352023sw s3,64(a0) > 5e: 4781c.lia5,0 > 60: 7422c.ldsp s0,40(sp) > 62: 7482c.ldsp s1,32(sp) >

Re: [Linux-kernel-mentees] [PATCH net v2] xdp: Prevent kernel-infoleak in xsk_getsockopt()

On Tue, 28 Jul 2020 at 07:37, Peilin Ye wrote: > > xsk_getsockopt() is copying uninitialized stack memory to userspace when > `extra_stats` is `false`. Fix it. > > Fixes: 8aa5a33578e9 ("xsk: Add new statistics") > Suggested-by: Dan Carpenter > Signed-off-by: Pe

Re: [RFC PATCH bpf-next 0/3] bpf, riscv: Add compressed instructions to rv64 JIT

On Mon, 13 Jul 2020 at 20:37, Luke Nelson wrote: > > This patch series enables using compressed riscv (RVC) instructions > in the rv64 BPF JIT. > First of all; Really nice work. I like this, and it makes the code easier to read as well (e.g. emit_mv). I'm a bit curious why you only did it for

Re: [RFC PATCH bpf-next 1/3] bpf, riscv: Modify JIT ctx to support compressed instructions

On Mon, 13 Jul 2020 at 20:37, Luke Nelson wrote: > > This patch makes the necessary changes to struct rv_jit_context and to > bpf_int_jit_compile to support compressed riscv (RVC) instructions in > the BPF JIT. > > It changes the JIT image to be u16 instead of u32, since RVC instructions > are 2

Re: [RFC PATCH bpf-next 2/3] bpf, riscv: Add encodings for compressed instructions

On Mon, 13 Jul 2020 at 20:37, Luke Nelson wrote: > > This patch adds functions for encoding and emitting compressed riscv > (RVC) instructions to the BPF JIT. > > Some regular riscv instructions can be compressed into an RVC instruction > if the instruction fields meet some requirements. For

Re: [RFC PATCH bpf-next 3/3] bpf, riscv: Use compressed instructions in the rv64 JIT

c.sws1,56(a0) > 56: 03252e23sw s2,60(a0) > 5a: 05352023sw s3,64(a0) > 5e: 4781c.lia5,0 > 60: 7422c.ldsp s0,40(sp) > 62: 7482c.ldsp s1,32(sp) > 64: 6962 c.ldsp s2,24(sp) > 66: 69c2

[PATCH bpf-next] MAINTAINERS: add reviewer to maintainers entry

From: Björn Töpel Jonathan Lemon has volunteered as an official AF_XDP reviewer. Thank you, Jonathan! Signed-off-by: Björn Töpel --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 0cfe98a6761a..dd875578d53c 100644 --- a/MAINTAINERS +++ b

Re: [RFC PATCH bpf-next] RV32G eBPF JIT

ed > --- /dev/null > +++ b/arch/riscv/net/bpf_jit_comp32.c > @@ -0,0 +1,1460 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* BPF JIT compiler for RV32G > + * > + * Copyright(c) 2019 Luke Nelson > + * This code is based on the code and ideas from > + * Björn Töpel , >

Re: [PATCH net-next] xdp: xdp_umem: fix umem pages mapping for 32bits systems

On Sat, 29 Jun 2019 at 19:53, David Miller wrote: > > From: Björn Töpel > Date: Wed, 26 Jun 2019 22:50:23 +0200 > > > On Wed, 26 Jun 2019 at 17:59, Ivan Khoronzhuk > > wrote: > >> > >> Use kmap instead of page_address as it's not always in low

Re: [PATCH] net: Fix hang while unregistering device bound to xdp socket

On 2019-06-07 08:36, Ilya Maximets wrote: On 06.06.2019 21:03, Jonathan Lemon wrote: On 6 Jun 2019, at 5:40, Ilya Maximets wrote: Device that bound to XDP socket will not have zero refcount until the userspace application will not close it. This leads to hang inside 'netdev_wait_allrefs()'

Re: [PATCH bpf-next] Enable zext optimization for more RV64G ALU ops

t these have been merged to bpf-next, the zext optimization can > be enabled for the fixed operations. > Thanks for the patch, Luke! Acked-by: Björn Töpel > Cc: Song Liu > Cc: Jiong Wang > Cc: Xi Wang > Signed-off-by: Luke Nelson > --- > arch/riscv/net/bpf_jit_comp.c

Re: [PATCH bpf] xdp: fix possible cq entry leak

ation to the point where failure is not > possible. Additionally, 'queue_id' checking moved out from the loop > since there is no point to check it there. > Good catch, Ilya! Thanks for the patch! Acked-by: Björn Töpel > Fixes: 35fcde7f8deb ("xsk: support for Tx") > Sig

Re: [PATCH bpf v3] xdp: fix hang while unregistering device bound to xdp socket

On Tue, 11 Jun 2019 at 10:42, Ilya Maximets wrote: > > On 11.06.2019 11:09, Björn Töpel wrote: > > On Mon, 10 Jun 2019 at 22:49, Jonathan Lemon > > wrote: > >> > >> On 10 Jun 2019, at 9:15, Ilya Maximets wrote: > >> > >>> Device t

Re: [PATCH bpf-next 0/4] RV64 BPF JIT Optimizations

irt machine, using > lib/test_bpf and test_verifier, and formally verified their correctness > using Serval. > Luke and Xi, Thanks a lot for working on this! Very nice series! For the series: Reviewed-by: Björn Töpel Acked-by: Björn Töpel > Luke Nelson (4): > bpf, ri

Re: add an API to check if a streamming mapping needs sync calls

, and there are (obviously) no performance regressions. Would the patches go through the net/bpf trees or somewhere else? For the series: Tested-by: Björn Töpel Acked-by: Björn Töpel Björn Diffstat: Documentation/core-api/dma-api.rst |8 + include/linux/dma-direct.h |1

Re: [PATCH net] xsk: remove cheap_dma optimization

On 2020-06-29 15:52, Daniel Borkmann wrote: Ok, fair enough, please work with DMA folks to get this properly integrated and restored then. Applied, thanks! Daniel, you were too quick! Please revert this one; Christoph just submitted a 4-patch-series that addresses both the DMA API, and the

Re: [PATCH v1] riscv: Add jump-label implementation

entry) - > jump_entry_code(entry); The 20b jump offset of JAL is enough, but to catch future changes that might potentially break this, I would add a WARN to catch if offset >20b (or overkill fallback to JALR -- don't do that.). Somewhat related to that; The UN

Re: [PATCH v1] riscv: Add jump-label implementation

On Tue, 7 Jul 2020 at 17:08, Emil Renner Berthing wrote: > > Add jump-label implementation based on the ARM64 version. > > Tested on the HiFive Unleashed board. > > Signed-off-by: Emil Renner Berthing > --- > > Changes since RFC: > - Use RISCV_PTR and RISCV_LGPTR macros to match struct

Re: [PATCH v1] riscv: Add jump-label implementation

On Tue, 7 Jul 2020 at 17:08, Emil Renner Berthing wrote: > > Add jump-label implementation based on the ARM64 version. > > Tested on the HiFive Unleashed board. > I took your patch for a spin on qemu. The boot selftest (CONFIG_STATIC_KEYS_SELFTEST=y) passes, but the module test

Re: [PATCH net] xsk: remove cheap_dma optimization

On 2020-06-29 17:41, Robin Murphy wrote: On 2020-06-28 18:16, Björn Töpel wrote: [...]> Somewhat related to the DMA API; It would have performance benefits for AF_XDP if the DMA range of the mapped memory was linear, i.e. by IOMMU utilization. I've started hacking a thing a little

Re: [PATCH v2 1/2] riscv: Support R_RISCV_ADD64 and R_RISCV_SUB64 relocs

On Wed, 8 Jul 2020 at 23:10, Emil Renner Berthing wrote: > > These are needed for the __jump_table in modules using > static keys/jump-labels with the layout from > HAVE_ARCH_JUMP_LABEL_RELATIVE on 64bit kernels. > > Signed-off-by: Emil Renner Berthing Reviewed-by: Björn Töpel

Re: [PATCH v2 2/2] riscv: Add jump-label implementation

On Wed, 8 Jul 2020 at 23:10, Emil Renner Berthing wrote: > > Add jump-label implementation based on the ARM64 version > and add CONFIG_JUMP_LABEL=y to the defconfigs. > > Signed-off-by: Emil Renner Berthing > Reviewed-by: Björn Töpel Tested-by: Björn Töpel > --- >

Re: [RFC] riscv: Add jump-label implementation

On Fri, 3 Jul 2020 at 17:43, Emil Renner Berthing wrote: > > On Thu, 2 Jul 2020 at 22:07, Emil Renner Berthing wrote: > > > > Add basic jump-label implementation heavily based > > on the ARM64 version. > > > > Tested on the HiFive Unleashed. > > > > Signed-off-by: Emil Renner Berthing > > --- >

Re: [RFC] riscv: Add jump-label implementation

On Sat, 4 Jul 2020 at 13:35, Emil Renner Berthing wrote: > > On Sat, 4 Jul 2020 at 13:23, Björn Töpel wrote: [...] > > Indeed. And nice work! Can you respin the patch with the 32b fix > > above, and also without the RFC tag? > > Yes, of course. If you don't mind

Re: the XSK buffer pool needs be to reverted

On 2020-06-26 09:47, Christoph Hellwig wrote: Hi Björn, you addition of the xsk_buff_pool.c APIs in commit 2b43470add8c ("xsk: Introduce AF_XDP buffer allocation API") is unfortunately rather broken by making lots of assumptions and poking into dma-direct and swiotlb internals that are of no

Re: the XSK buffer pool needs be to reverted

On 2020-06-26 14:41, Christoph Hellwig wrote: On Fri, Jun 26, 2020 at 02:22:41PM +0200, Björn Töpel wrote: [...] Understood. Wdyt about something in the lines of the diff below? It's build tested only, but removes all non-dma API usage ("poking internals"). Would that be a w

[PATCH net] xsk: remove cheap_dma optimization

From: Björn Töpel When the AF_XDP buffer allocation API was introduced it had an optimization, "cheap_dma". The idea was that when the umem was DMA mapped, the pool also checked whether the mapping required a synchronization (CPU to device, and vice versa). If not, it would

Re: [PATCH net] xsk: remove cheap_dma optimization

On 2020-06-27 09:04, Christoph Hellwig wrote: On Sat, Jun 27, 2020 at 01:00:19AM +0200, Daniel Borkmann wrote: Given there is roughly a ~5 weeks window at max where this removal could still be applied in the worst case, could we come up with a fix / proposal first that moves this into the DMA

Re: [PATCH net] xsk: remove cheap_dma optimization

On 2020-06-29 17:18, Daniel Borkmann wrote: Nice, tossed from bpf tree then! (Looks like it didn't land on the bpf list yet, but seems other mails are currently stuck as well on vger. I presume it will be routed to Linus via Christoph?) Thanks! Christoph (according to the other mail) was

Re: [PATCH 1/2] xsk: do not use mmap_sem

Den tors 7 feb. 2019 kl 06:38 skrev Davidlohr Bueso : > > Holding mmap_sem exclusively for a gup() is an overkill. > Lets replace the call for gup_fast() and let the mm take > it if necessary. > > Cc: David S. Miller > Cc: Bjorn Topel > Cc: Magnus Karlsson > CC: net...@vger.kernel.org >

Re: [PATCH v2] xsk: share the mmap_sem for page pinning

Den mån 11 feb. 2019 kl 17:15 skrev Davidlohr Bueso : > > Holding mmap_sem exclusively for a gup() is an overkill. > Lets share the lock and replace the gup call for gup_longterm(), > as it is better suited for the lifetime of the pinning. > Thanks for the cleanup! Acked-by: Bjö

Re: [PATCH] x86, retpolines: raise limit for generating indirect calls from switch-case

and more generic solution to the issue we observed and > measured in XDP land. And hopefully other parts of the network stack > and kernel will also benefit. > > Acked-by: Jesper Dangaard Brouer > > Thanks for following up on this Daniel, I definitely prefer a switch-statement o

[PATCH] perf probe: Fix probe definition for inlined functions

From: Björn Töpel In commit 613f050d68a8 ("perf probe: Fix to probe on gcc generated functions in modules"), the offset from symbol is, incorrectly, added to the trace point address. This leads to incorrect probe trace points for inlined functions and when using relative line number

[PATCH] perf stat: Added '--polled-interval-print/-P' mode

5729 25 164 351 653 cycles Signed-off-by: Björn Töpel --- tools/perf/builtin-stat.c | 69 --- 1 file changed, 60 insertions(+), 9 deletions(-) diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c index ee7ada7..af7dde1 10

Re: linux-next: build failure after merge of the bpf-next tree

On 2021-03-11 01:47, Stephen Rothwell wrote: Hi all, After merging the bpf-next tree, today's linux-next build (perf) failed like this: make[3]: *** No rule to make target 'libbpf_util.h', needed by '/home/sfr/next/perf/staticobjs/xsk.o'. Stop. Hi Stephen, It's an incremental build

XDP socket rings, and LKMM litmus tests

Hi! Firstly; The long Cc-list is to reach the LKMM-folks. Some background; the XDP sockets use a ring-buffer to communicate between the kernel and userland. It's a single-consumer/single-producer ring, and described in net/xdp/xsk_queue.h. --8<--- /* The structure of the shared state of the

Re: XDP socket rings, and LKMM litmus tests

On Tue, 2 Mar 2021 at 21:04, Paul E. McKenney wrote: > [...] > > And if the answer is "yes", how about this one? > With the == to != change in P1, this is OK! > P0(int *prod, int *cons, int *data) > { > int p; > > p = READ_ONCE(*prod); > if (p == READ_ONCE(*cons)) { ...and now

Re: XDP socket rings, and LKMM litmus tests

On Tue, 2 Mar 2021 at 21:41, Paul E. McKenney wrote: > > On Tue, Mar 02, 2021 at 09:24:04PM +0100, Björn Töpel wrote: > > On Tue, 2 Mar 2021 at 20:57, Paul E. McKenney wrote: > > > > > > On Tue, Mar 02, 2021 at 07:46:27PM +0100, Björn Töpel wrote: > > >

Re: XDP socket rings, and LKMM litmus tests

On Tue, 2 Mar 2021 at 20:57, Paul E. McKenney wrote: > > On Tue, Mar 02, 2021 at 07:46:27PM +0100, Björn Töpel wrote: [...] > > Before digging in too deeply, does the following simplification > still capture your intent? > Thanks for having a look, Paul! > P0(int *prod,

[PATCH] tools/memory-model: Fix smp_mb__after_spinlock() spelling

From: Björn Töpel A misspelled invokation of git-grep, revealed that smp_mb__after_spinlock() was misspelled in explaination.txt. Add missing "_" to smp_mb__after_spinlock(). Fixes: 1c27b644c0fd ("Automate memory-barriers.txt; provide Linux-kernel memory model") Signed

Re: [PATCH] tools/memory-model: Fix smp_mb__after_spinlock() spelling

On 2021-03-05 16:36, Alan Stern wrote: On Fri, Mar 05, 2021 at 11:28:23AM +0100, Björn Töpel wrote: From: Björn Töpel A misspelled invokation of git-grep, revealed that ---^ Smetimes my brain is a little slow... Do you confirm that this is a joke? I wish, Alan. I wish

[PATCH v3] riscv: Only consider swbp/ss handlers for correct privileged mode

From: Björn Töpel RISC-V software breakpoint trap handlers are used for {k,u}probes. When trapping from kernelmode, only the kernelmode handlers should be considered. Vice versa, only usermode handlers for usermode traps. This is not the case on RISC-V, which can trigger a bug if a userspace

Re: [PATCH -fixes] riscv: Fix ftrace syscall handling which are now prefixed with __riscv_

ym_name() which allows us > to ignore this prefix. > > And also ignore compat syscalls like x86/arm64 by implementing > arch_trace_is_compat_syscall(). > > Fixes: 08d0ce30e0e4 ("riscv: Implement syscall wrappers") > Signed-off-by: Alexandre Ghiti This fix does the BPF test suite happier! Tested-by: Björn Töpel

Re: [PATCH -fixes] riscv: Fix ftrace syscall handling which are now prefixed with __riscv_

Alexandre Ghiti writes: > @Conor Dooley This fails checkpatch but the documentation here states > that this is how to do: > https://elixir.bootlin.com/linux/latest/source/Documentation/trace/ftrace-design.rst#L246 FWIW, I'll relax the PW CI checkpatch test going forward. It's way too strict...

Re: [PATCH] riscv: Fix text patching when icache flushes use IPIs

its a local icache flush and then avoids the use of > IPIs. > > Co-developed-by: Björn Töpel > Signed-off-by: Björn Töpel > Signed-off-by: Alexandre Ghiti FWIW, the BPF selftests pass nicely with this (especially the fentry/fexit tests ;-)). I don't know if it's worth much sayi

[PATCH v12 for-next 0/4] riscv: ftrace: Miscellaneous ftrace improvements

From: Björn Töpel NB! Song told me that he would not have the time work on this series, so I picked it up. This series includes a three ftrace improvements for RISC-V: 1. Do not require to run recordmcount at build time (patch 1) 2. Simplification of the function graph functionality (patch 2

[PATCH v12 for-next 3/4] riscv: ftrace: Add DYNAMIC_FTRACE_WITH_DIRECT_CALLS support

unc and the RESTORE_REGS in ftrace_regs_caller, direct_caller will be jumped to by the `jr` inst. Add DYNAMIC_FTRACE_WITH_DIRECT_CALLS support for RISC-V. Signed-off-by: Song Shuai Tested-by: Guo Ren Signed-off-by: Guo Ren Acked-by: Björn Töpel --- arch/riscv/Kconfig | 1 + arch/riscv/incl

[PATCH v12 for-next 4/4] samples: ftrace: Add RISC-V support for SAMPLE_FTRACE_DIRECT[_MULTI]

From: Song Shuai Add RISC-V variants of the ftrace-direct* samples. Tested-by: Evgenii Shatokhin Signed-off-by: Song Shuai Tested-by: Guo Ren Signed-off-by: Guo Ren Acked-by: Björn Töpel --- arch/riscv/Kconfig | 2 + samples/ftrace/ftrace-direct-modify.c

Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used

Conor Dooley writes: > On Tue, Mar 05, 2024 at 08:33:30AM +0530, Anup Patel wrote: >> On Tue, Mar 5, 2024 at 1:54 AM Björn Töpel wrote: >> > >> > Conor Dooley writes: >> > >> > > On Thu, Feb 29, 2024 at 01:10:56PM +0100, Alexandre Ghiti wrote:

Re: [PATCH v3 2/2] riscv: Fix text patching when IPI are used

; So instead, make sure every CPU executes the stop_machine() patching >> function and emit a local icache flush there. >> >> Co-developed-by: Björn Töpel >> Signed-off-by: Björn Töpel >> Signed-off-by: Alexandre Ghiti >> Reviewed-by: Andrea Parri >

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Puranjay! Puranjay Mohan writes: > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. > This allows each ftrace callsite to provide an ftrace_ops to the common > ftrace trampoline, allowing each callsite to invoke distinct tracer > functions without the need to fall back to

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Puranjay Mohan writes: > Hi Björn, > > On Thu, Mar 7, 2024 at 8:27 PM Björn Töpel wrote: >> >> Puranjay! >> >> Puranjay Mohan writes: >> >> > This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. >> > This allows ea

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Puranjay Mohan writes: >> Now, I think a better approach for RISC-V would be implementing what x86 >> has (arch_ftrace_update_trampoline()), rather than CALL_OPS for RISC-V. >> >> Thoughts? > > I am going to spin some patches for implementing > arch_ftrace_update_trampoline() for > RISC-V, then

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Puranjay Mohan writes: > Björn Töpel writes: > >> >> Hmm, depending on RISC-V's CMODX path, the pro/cons CALL_OPS vs dynamic >> trampolines changes quite a bit. >> >> The more I look at the pains of patching two instruction ("split >> immediates

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Björn Töpel writes: > Puranjay Mohan writes: > >> Björn Töpel writes: >> >>> >>> Hmm, depending on RISC-V's CMODX path, the pro/cons CALL_OPS vs dynamic >>> trampolines changes quite a bit. >>> >>> The more I look at the pains o

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Mark, Mark Rutland writes: >> A) Use auipc/jalr, only patch jalr to take us to a common >>dispatcher/trampoline >> >> | # probably on a data cache-line != func .text >> to avoid ping-pong >> | ... >> | func: >> | ...make sure ra isn't messed up... >> | aupic >> | nop <=>

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Andy, Pulling out the A option: >> > A) Use auipc/jalr, only patch jalr to take us to a common >> >dispatcher/trampoline >> > >> > | # probably on a data cache-line != func >> > .text to avoid ping-pong >> > | ... >> > | func: >> > | ...make sure ra isn't messed up... >> > | aupic

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Andy Chiu writes: > On Thu, Mar 21, 2024 at 4:48 PM Björn Töpel wrote: >> >> Andy, >> >> Pulling out the A option: >> >> >> > A) Use auipc/jalr, only patch jalr to take us to a common >> >> >dispatcher/trampoline >> &g

Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Mark Rutland writes: > Hi Bjorn > > (apologies, my corporate mail server has butchered your name here). Ha! That's the price I have to pay for carrying double-umlauts everywhere. Thanks for getting back with a really useful answer! >> On Arm64, CALL_OPS makes it possible to implement direct

Re: [RFC PATCH] ftrace: riscv: move from REGS to ARGS

Puranjay Mohan writes: > This commit replaces riscv's support for FTRACE_WITH_REGS with support > for FTRACE_WITH_ARGS. This is required for the ongoing effort to stop > relying on stop_machine() for RISCV's implementation of ftrace. > > The main relevant benefit that this change will bring for

Re: [PATCH] ftrace: riscv: move from REGS to ARGS

nally getting rid of the stop_machine() text patching. I've tested this on QEMU, and on the VisionFive2. No regressions (FTRACE_STARTUP_*, and kselftest), other than that KPROBES_ON_FTRACE no longer works. (Which will be addressed by [2]). Palmer, my preference is that this should go on for-next, rather than being part of the upcoming text patching support (worked on by Andy), but really up to you. Tested-by: Björn Töpel Reviewed-by: Björn Töpel

  1   2   >