Re: [PATCH] riscv: Fix early ftrace nop patching

manged to reproduce the crash on the VisionFive2 board (however only triggered when CONFIG_RELOCATABLE=y), and can verify that this fix solves the issue. Reviewed-by: Björn Töpel Tested-by: Björn Töpel

Re: [PATCH v3 2/9] riscv: mm: Pre-allocate vmemmap/direct map PGD entries

Björn Töpel writes: > From: Björn Töpel > > The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to > all userland page tables, which means that if the PGD level table is > changed, other page tables has to be updated as well. > > Instead of having the PGD chan

Re: [PATCH v3 5/9] riscv: mm: Add memory hotplugging support

Alexandre Ghiti writes: > On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote: >> >> From: Björn Töpel >> >> For an architecture to support memory hotplugging, a couple of >> callbacks needs to be implemented: >> >> arch_add_memory() >> T

Re: [PATCH v3 9/9] riscv: mm: Add support for ZONE_DEVICE

Alexandre Ghiti writes: > On Tue, May 21, 2024 at 1:49 PM Björn Töpel wrote: >> >> From: Björn Töpel >> >> ZONE_DEVICE pages need DEVMAP PTEs support to function >> (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit >> in the PTE for DEV

[PATCH v3 9/9] riscv: mm: Add support for ZONE_DEVICE

From: Björn Töpel ZONE_DEVICE pages need DEVMAP PTEs support to function (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit in the PTE for DEVMAP mark, add the corresponding helpers, and enable ARCH_HAS_PTE_DEVMAP for riscv64. Signed-off-by: Björn Töpel --- arch/riscv

[PATCH v3 8/9] virtio-mem: Enable virtio-mem for RISC-V

From: Björn Töpel Now that RISC-V has memory hotplugging support, virtio-mem can be used on the platform. Acked-by: David Hildenbrand Signed-off-by: Björn Töpel --- drivers/virtio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/virtio/Kconfig b/drivers

[PATCH v3 7/9] riscv: Enable memory hotplugging for RISC-V

From: Björn Töpel Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for RISC-V. Signed-off-by: Björn Töpel --- arch/riscv/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index fe5281398543..2724dc2af29f 100644 --- a/arch

[PATCH v3 6/9] riscv: mm: Take memory hotplug read-lock during kernel page table dump

From: Björn Töpel During memory hot remove, the ptdump functionality can end up touching stale data. Avoid any potential crashes (or worse), by holding the memory hotplug read-lock while traversing the page table. This change is analogous to arm64's commit bf2b59f60ee1 ("arm64/mm: Hold m

[PATCH v3 5/9] riscv: mm: Add memory hotplugging support

From: Björn Töpel For an architecture to support memory hotplugging, a couple of callbacks needs to be implemented: arch_add_memory() This callback is responsible for adding the physical memory into the direct map, and call into the memory hotplugging generic code via __add_pages

[PATCH v3 4/9] riscv: mm: Refactor create_linear_mapping_range() for memory hot add

From: Björn Töpel Add a parameter to the direct map setup function, so it can be used in arch_add_memory() later. Reviewed-by: Alexandre Ghiti Reviewed-by: David Hildenbrand Reviewed-by: Oscar Salvador Signed-off-by: Björn Töpel --- arch/riscv/mm/init.c | 15 ++- 1 file changed

[PATCH v3 3/9] riscv: mm: Change attribute from __init to __meminit for page functions

From: Björn Töpel Prepare for memory hotplugging support by changing from __init to __meminit for the page table functions that are used by the upcoming architecture specific callbacks. Changing the __init attribute to __meminit, avoids that the functions are removed after init. The __meminit

[PATCH v3 2/9] riscv: mm: Pre-allocate vmemmap/direct map PGD entries

From: Björn Töpel The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to all userland page tables, which means that if the PGD level table is changed, other page tables has to be updated as well. Instead of having the PGD changes ripple out to all tables, the synchronization can

[PATCH v3 1/9] riscv: mm: Properly forward vmemmap_populate() altmap parameter

From: Björn Töpel Make sure that the altmap parameter is properly passed on to vmemmap_populate_hugepages(). Signed-off-by: Björn Töpel --- arch/riscv/mm/init.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 2574f6a3b0e7

[PATCH v3 0/9] riscv: Memory Hot(Un)Plug support

From: Björn Töpel Memory Hot(Un)Plug support (and ZONE_DEVICE) for the RISC-V port Introduction To quote "Documentation/admin-guide/mm/m

Re: [PATCH v2 8/8] riscv: mm: Add support for ZONE_DEVICE

Björn Töpel writes: > From: Björn Töpel > > ZONE_DEVICE pages need DEVMAP PTEs support to function > (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit > in the PTE for DEVMAP mark, add the corresponding helpers, and enable > ARCH_HAS_PTE_DEVMAP for riscv64.

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

Oscar Salvador writes: > On Tue, May 14, 2024 at 04:04:42PM +0200, Björn Töpel wrote: >> +static void __meminit free_vmemmap_storage(struct page *page, size_t size, >> + struct vmem_altmap *altmap) >> +{ >> +if (altmap) >&

Re: [PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions

Oscar Salvador writes: > On Tue, May 14, 2024 at 04:04:40PM +0200, Björn Töpel wrote: >> From: Björn Töpel >> >> Prepare for memory hotplugging support by changing from __init to >> __meminit for the page table functions that are used by the upcoming >>

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

Alexandre Ghiti writes: > On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote: >> +int __ref arch_add_memory(int nid, u64 start, u64 size, struct mhp_params >> *params) >> +{ >> + int ret; >> + >> + create_linear_mappin

Re: [PATCH v2 6/8] riscv: Enable memory hotplugging for RISC-V

Alexandre Ghiti writes: > On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote: >> >> From: Björn Töpel >> >> Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for >> RISC-V. >> >> Signed-off-by: Björn Töpel >> --- >> a

Re: [PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions

Alexandre Ghiti writes: > On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote: >> >> From: Björn Töpel >> >> Prepare for memory hotplugging support by changing from __init to >> __meminit for the page table functions that are used by the upcoming &

Re: [PATCH v2 4/8] riscv: mm: Add memory hotplugging support

David Hildenbrand writes: > On 14.05.24 16:04, Björn Töpel wrote: >> From: Björn Töpel >> >> For an architecture to support memory hotplugging, a couple of >> callbacks needs to be implemented: >> >> arch_add_memory() >>This callback

Re: [PATCH v2 1/8] riscv: mm: Pre-allocate vmemmap/direct map PGD entries

Alexandre Ghiti writes: > Hi Björn, > > On Tue, May 14, 2024 at 4:05 PM Björn Töpel wrote: >> >> From: Björn Töpel >> >> The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to >> all userland page tables, which means that if the PGD level tab

[PATCH v2 8/8] riscv: mm: Add support for ZONE_DEVICE

From: Björn Töpel ZONE_DEVICE pages need DEVMAP PTEs support to function (ARCH_HAS_PTE_DEVMAP). Claim another RSW (reserved for software) bit in the PTE for DEVMAP mark, add the corresponding helpers, and enable ARCH_HAS_PTE_DEVMAP for riscv64. Signed-off-by: Björn Töpel --- arch/riscv

[PATCH v2 6/8] riscv: Enable memory hotplugging for RISC-V

From: Björn Töpel Enable ARCH_ENABLE_MEMORY_HOTPLUG and ARCH_ENABLE_MEMORY_HOTREMOVE for RISC-V. Signed-off-by: Björn Töpel --- arch/riscv/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 6bec1bce6586..b9398b64bb69 100644 --- a/arch

[PATCH v2 7/8] virtio-mem: Enable virtio-mem for RISC-V

From: Björn Töpel Now that RISC-V has memory hotplugging support, virtio-mem can be used on the platform. Signed-off-by: Björn Töpel --- drivers/virtio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig index

[PATCH v2 4/8] riscv: mm: Add memory hotplugging support

From: Björn Töpel For an architecture to support memory hotplugging, a couple of callbacks needs to be implemented: arch_add_memory() This callback is responsible for adding the physical memory into the direct map, and call into the memory hotplugging generic code via __add_pages

[PATCH v2 5/8] riscv: mm: Take memory hotplug read-lock during kernel page table dump

From: Björn Töpel During memory hot remove, the ptdump functionality can end up touching stale data. Avoid any potential crashes (or worse), by holding the memory hotplug read-lock while traversing the page table. This change is analogous to arm64's commit bf2b59f60ee1 ("arm64/mm: Hold m

[PATCH v2 3/8] riscv: mm: Refactor create_linear_mapping_range() for memory hot add

From: Björn Töpel Add a parameter to the direct map setup function, so it can be used in arch_add_memory() later. Signed-off-by: Björn Töpel --- arch/riscv/mm/init.c | 15 ++- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c

[PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions

From: Björn Töpel Prepare for memory hotplugging support by changing from __init to __meminit for the page table functions that are used by the upcoming architecture specific callbacks. Changing the __init attribute to __meminit, avoids that the functions are removed after init. The __meminit

[PATCH v2 1/8] riscv: mm: Pre-allocate vmemmap/direct map PGD entries

From: Björn Töpel The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to all userland page tables, which means that if the PGD level table is changed, other page tables has to be updated as well. Instead of having the PGD changes ripple out to all tables, the synchronization can

[PATCH v2 0/8] riscv: Memory Hot(Un)Plug support

From: Björn Töpel Memory Hot(Un)Plug support (and ZONE_DEVICE) for the RISC-V port Introduction To quote "Documentation/admin-guide/mm/m

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

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: [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, 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

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

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

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] 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: > 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! 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: [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: [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 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

[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 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

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...

[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: 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

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] 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: 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 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 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,

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: general protection fault in xsk_recvmsg

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

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 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: 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][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: [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] 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: [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][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: [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: [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: [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: [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

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 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 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: [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: [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 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 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

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: [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: [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: [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 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: 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 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 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

[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: 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

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: 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] 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

[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

[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

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

[tip: perf/core] samples/bpf: fix build by setting HAVE_ATTR_TEST to zero

The following commit has been merged into the perf/core branch of tip: Commit-ID: fce9501aec6bdda45ef3a5e365a5e0de7de7fe2d Gitweb: https://git.kernel.org/tip/fce9501aec6bdda45ef3a5e365a5e0de7de7fe2d Author:Björn Töpel AuthorDate:Tue, 01 Oct 2019 13:33:07 +02:00 Committer

[tip: perf/core] perf tools: Make usage of test_attr__* optional for perf-sys.h

The following commit has been merged into the perf/core branch of tip: Commit-ID: 06f84d1989b7e58d56fa2e448664585749d41221 Gitweb: https://git.kernel.org/tip/06f84d1989b7e58d56fa2e448664585749d41221 Author:Björn Töpel AuthorDate:Tue, 01 Oct 2019 13:33:06 +02:00 Committer

[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

[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 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

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

  1   2   >