Re: [PATCH HID 4/7] HID: bpf: allow BPF programs to force using hid-generic

2024-09-02 Thread Peter Hutterer
On Tue, Sep 03, 2024 at 01:14:34AM +0900, Benjamin Tissoires wrote: > The use case is when we fix a device through HID-BPF, 99% of the cases > we want the device to use hid-generic now instead of a dedicated device. s/dedicated device/dedicated driver/ in the commit message > That's because the d

[PATCH v2 1/1] selftests/bpf: Fix procmap_query()'s params mismatch and compilation warning

2024-09-02 Thread Yuan Chen
From: Yuan Chen When the PROCMAP_QUERY is not defined, a compilation error occurs due to the mismatch of the procmap_query()'s params, procmap_query() only be called in the file where the function is defined, modify the params so they can match. We get a warning when build samples/bpf: trace

Re: [PATCH net-next RFC] selftests/net: integrate packetdrill with ksft

2024-09-02 Thread Willem de Bruijn
Jakub Kicinski wrote: > On Mon, 2 Sep 2024 09:46:12 -0700 Jakub Kicinski wrote: > > PRESERVE_TEST_DIRS > > This was meant to be: > > PRESERVE_TEST_DIRS := 1 Oh I like this. > Testing this more, looks like rsync -aR breaks networking tests, too. > The net/lib target, specifically, is no longer a

Re: [PATCH RFC 3/8] openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)

2024-09-02 Thread Arnd Bergmann
On Mon, Sep 2, 2024, at 16:08, Aleksa Sarai wrote: >> >if (unlikely(usize < OPEN_HOW_SIZE_VER0)) >> >return -EINVAL; >> > + if (unlikely(usize > PAGE_SIZE)) >> > + return -E2BIG; >> > >> >> Is PAGE_SIZE significant here? If there is a need to enforce a limit, >> I would

[PATCH v5 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on VDSO64

2024-09-02 Thread Christophe Leroy
Extend getrandom() vDSO implementation to VDSO64 Tested on QEMU on both ppc64_defconfig and ppc64le_defconfig. The results are not precise as it is QEMU on an x86 laptop, but no need to be precise to see the benefit. ~ # ./vdso_test_getrandom bench-single vdso: 2500 times in 4.97162 s

[PATCH v5 4/5] powerpc/vdso: Wire up getrandom() vDSO implementation on VDSO32

2024-09-02 Thread Christophe Leroy
To be consistent with other VDSO functions, the function is called __kernel_getrandom() __arch_chacha20_blocks_nostack() fonction is implemented basically with 32 bits operations. It performs 4 QUARTERROUND operations in parallele. There are enough registers to avoid using the stack: On input:

[PATCH v5 3/5] powerpc/vdso: Refactor CFLAGS for CVDSO build

2024-09-02 Thread Christophe Leroy
In order to avoid two much duplication when we add new VDSO functionnalities in C like getrandom, refactor common CFLAGS. Signed-off-by: Christophe Leroy --- v3: Also refactor removed flags --- arch/powerpc/kernel/vdso/Makefile | 32 +-- 1 file changed, 13 insertions(

[PATCH v5 2/5] powerpc/vdso32: Add crtsavres

2024-09-02 Thread Christophe Leroy
Commit 08c18b63d965 ("powerpc/vdso32: Add missing _restgpr_31_x to fix build failure") added _restgpr_31_x to the vdso for gettimeofday, but the work on getrandom shows that we will need more of those functions. Remove _restgpr_31_x and link in crtsavres.o so that we get all save/restore functions

[PATCH v5 1/5] mm: Define VM_DROPPABLE for powerpc/32

2024-09-02 Thread Christophe Leroy
Commit 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings") only adds VM_DROPPABLE for 64 bits architectures. In order to also use the getrandom vDSO implementation on powerpc/32, use VM_ARCH_1 for VM_DROPPABLE on powerpc/32. This is possible because VM_ARCH_1 is

[PATCH v5 0/5] Wire up getrandom() vDSO implementation on powerpc

2024-09-02 Thread Christophe Leroy
This series wires up getrandom() vDSO implementation on powerpc. Tested on PPC32 on real hardware. Tested on PPC64 (both BE and LE) on QEMU: Performance on powerpc 885: ~# ./vdso_test_getrandom bench-single vdso: 2500 times in 62.938002291 seconds libc: 2500

Re: [PATCH v5 06/30] arm64: context switch POR_EL0 register

2024-09-02 Thread Catalin Marinas
On Tue, Aug 27, 2024 at 12:38:04PM +0100, Will Deacon wrote: > On Fri, Aug 23, 2024 at 07:40:52PM +0100, Catalin Marinas wrote: > > On Fri, Aug 23, 2024 at 06:08:36PM +0100, Will Deacon wrote: > > > On Fri, Aug 23, 2024 at 05:41:06PM +0100, Catalin Marinas wrote: > > > > On Fri, Aug 23, 2024 at 03:

Re: [PATCH v12 26/39] arm64/ptrace: Expose GCS via ptrace and core files

2024-09-02 Thread Mark Brown
On Mon, Sep 02, 2024 at 07:56:32PM +0100, Catalin Marinas wrote: > On Thu, Aug 29, 2024 at 12:27:42AM +0100, Mark Brown wrote: > > +static int gcs_get(struct task_struct *target, > > + const struct user_regset *regset, > > + struct membuf to) > > + if (target == curren

Re: [PATCH v12 26/39] arm64/ptrace: Expose GCS via ptrace and core files

2024-09-02 Thread Catalin Marinas
On Thu, Aug 29, 2024 at 12:27:42AM +0100, Mark Brown wrote: > +static int gcs_get(struct task_struct *target, > +const struct user_regset *regset, > +struct membuf to) > +{ > + struct user_gcs user_gcs; > + > + if (target == current) > + gcs_prese

Re: [PATCH v12 25/39] arm64/signal: Expose GCS state in signal frames

2024-09-02 Thread Catalin Marinas
On Thu, Aug 29, 2024 at 12:27:41AM +0100, Mark Brown wrote: > Add a context for the GCS state and include it in the signal context when > running on a system that supports GCS. We reuse the same flags that the > prctl() uses to specify which GCS features are enabled and also provide the > current G

Re: [PATCH v12 19/39] arm64/mm: Handle GCS data aborts

2024-09-02 Thread Catalin Marinas
On Thu, Aug 29, 2024 at 12:27:35AM +0100, Mark Brown wrote: > All GCS operations at EL0 must happen on a page which is marked as > having UnprivGCS access, including read operations. If a GCS operation > attempts to access a page without this then it will generate a data > abort with the GCS bit s

Re: [PATCH] selftests/bpf: Fix procmap_query()'s params mismatch and compilation warning

2024-09-02 Thread Jiri Olsa
On Mon, Sep 02, 2024 at 05:32:48PM +0800, Yuan Chen wrote: > From: Yuan Chen > > When the PROCMAP_QUERY is not defined, a compilation error occurs due to the > mismatch of the procmap_query()'s params, procmap_query() only be called in > the file where the function is defined, modify the params s

Re: [PATCH 3/6] KVM: x86: selftests: Set up AMD VM in pmu_counters_test

2024-09-02 Thread Colton Lewis
Sean Christopherson writes: On Wed, Aug 28, 2024, Mingwei Zhang wrote: > >> +static void test_core_counters(void) > >> +{ > >> +uint8_t nr_counters = nr_core_counters(); > >> +bool core_ext = kvm_cpu_has(X86_FEATURE_PERF_CTR_EXT_CORE); > >> +bool perf_mon_v2 = kvm_cpu_has(X86_FEATU

Re: [PATCH net-next RFC] selftests/net: integrate packetdrill with ksft

2024-09-02 Thread Jakub Kicinski
On Mon, 2 Sep 2024 09:46:12 -0700 Jakub Kicinski wrote: > PRESERVE_TEST_DIRS This was meant to be: PRESERVE_TEST_DIRS := 1 Testing this more, looks like rsync -aR breaks networking tests, too. The net/lib target, specifically, is no longer able to copy out the files outside of tools/testing/sel

Re: [PATCH RFC 3/8] openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)

2024-09-02 Thread Aleksa Sarai
On 2024-09-02, Arnd Bergmann wrote: > On Mon, Sep 2, 2024, at 07:06, Aleksa Sarai wrote: > > While we do currently return -EFAULT in this case, it seems prudent to > > follow the behaviour of other syscalls like clone3. It seems quite > > unlikely that anyone depends on this error code being EFAUL

Re: [PATCH net-next RFC] selftests/net: integrate packetdrill with ksft

2024-09-02 Thread Jakub Kicinski
On Sun, 01 Sep 2024 17:15:38 -0400 Willem de Bruijn wrote: > Changing kselftests to preserve directories turns out to be trivial. > Patch inline below. > > But, existing TARGETS of course then start failing. Because they > depend on existing rsync without -R. In (at least) two ways: > > amd-pstat

Re: [PATCH net-next] selftests: add selftest for UDP SO_PEEK_OFF support

2024-09-02 Thread Willem de Bruijn
Jason Xing wrote: > On Mon, Sep 2, 2024 at 11:02 PM Willem de Bruijn > wrote: > > > > Jason Xing wrote: > > > From: Jason Xing > > > > > > Add the SO_PEEK_OFF selftest for UDP. In this patch, I mainly do > > > three things: > > > 1. rename tcp_so_peek_off.c > > > 2. adjust for UDP protocol > > >

[PATCH HID 3/7] selftests/hid: allow to parametrize bus/vid/pid/rdesc on the test device

2024-09-02 Thread Benjamin Tissoires
This will be useful to introduce variants in tests to test the interactions between HID-BPF and some kernel modules. Signed-off-by: Benjamin Tissoires --- tools/testing/selftests/hid/hid_bpf.c| 2 +- tools/testing/selftests/hid/hid_common.h | 46 tools/testi

[PATCH HID 2/7] selftests/hid: cleanup C tests by adding a common struct uhid_device

2024-09-02 Thread Benjamin Tissoires
Allows to have an abstract class uhid_device which handles all of the uhid part without having to mess up with individual fds. struct attach_prog_args is now never used in hid_bpf.c, so drop it as well Signed-off-by: Benjamin Tissoires --- tools/testing/selftests/hid/hid_bpf.c| 77 +

[PATCH HID 5/7] selftests/hid: add test for assigning a given device to hid-generic

2024-09-02 Thread Benjamin Tissoires
We use a well known VID/PID on a driver that doesn't need to talk to the device, ensures we created the device against the target driver, then load our program and ensure we have unbound to this driver and use hid-generic instead. Signed-off-by: Benjamin Tissoires --- tools/testing/selftests/hid

[PATCH HID 4/7] HID: bpf: allow BPF programs to force using hid-generic

2024-09-02 Thread Benjamin Tissoires
The use case is when we fix a device through HID-BPF, 99% of the cases we want the device to use hid-generic now instead of a dedicated device. That's because the dedicated device might also want to change the report descriptor, or will be handling the device in a different way the new fixed devic

[PATCH HID 7/7] selftests/hid: add test to disable hid-input

2024-09-02 Thread Benjamin Tissoires
Add a test for the newly enabled feature to control the connect_mask of hid-generic. Signed-off-by: Benjamin Tissoires --- tools/testing/selftests/hid/hid_bpf.c | 60 +- tools/testing/selftests/hid/progs/hid.c| 6 ++- .../testing/selftests/hid/progs/

[PATCH net-next v2] selftests: add selftest for UDP SO_PEEK_OFF support

2024-09-02 Thread Jason Xing
From: Jason Xing Add the SO_PEEK_OFF selftest for UDP. In this patch, I mainly do three things: 1. rename tcp_so_peek_off.c 2. adjust for UDP protocol 3. add selftests into it Suggested-by: Jon Maloy Reviewed-by: Willem de Bruijn Signed-off-by: Jason Xing --- v2 Link: https://lore.kernel.org

[PATCH HID 0/7] HID: bpf: add a new hook to control hid-generic

2024-09-02 Thread Benjamin Tissoires
This is a slight change from the fundamentals of HID-BPF. In theory, HID-BPF is abstract to the kernel itself, and makes only changes at the HID level (through report descriptors or events emitted to/from the device). However, we have seen a few use cases where HID-BPF might interact with the runn

[PATCH HID 1/7] selftests/hid: add dependency on hid_common.h

2024-09-02 Thread Benjamin Tissoires
Allows to recompile the C tests when that file changes Signed-off-by: Benjamin Tissoires --- tools/testing/selftests/hid/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/hid/Makefile b/tools/testing/selftests/hid/Makefile index 72be55ac4bdf..9

[PATCH HID 6/7] HID: bpf: Allow to control the connect mask of hid-generic from BPF

2024-09-02 Thread Benjamin Tissoires
We make struct hid_device_id writeable and use the .driver_data field of hid-generic as the connect mask. This way, we can control from a HID-BPF program if a device needs to be exported through hidraw and/or hid-input mainly. This is useful in case we want to have a third party program that dire

Re: [PATCH RFC 1/8] uaccess: add copy_struct_to_user helper

2024-09-02 Thread Aleksa Sarai
On 2024-09-02, Arnd Bergmann wrote: > On Mon, Sep 2, 2024, at 07:06, Aleksa Sarai wrote: > > This is based on copy_struct_from_user(), but there is one additional > > case to consider when creating a syscall that returns an > > extensible-struct to userspace -- how should data in the struct that >

Re: [PATCH v2 0/2] Exposing nice CPU usage to userspace

2024-09-02 Thread Michal Koutný
Hello Joshua. On Fri, Aug 30, 2024 at 07:19:37AM GMT, Joshua Hahn wrote: > Exposing this metric will allow users to accurately probe the niced CPU > metric for each workload, and make more informed decisions when > directing higher priority tasks. I'm afraid I can't still appreciate exposing th

Re: [PATCH net-next] selftests: add selftest for UDP SO_PEEK_OFF support

2024-09-02 Thread Jason Xing
On Mon, Sep 2, 2024 at 11:02 PM Willem de Bruijn wrote: > > Jason Xing wrote: > > From: Jason Xing > > > > Add the SO_PEEK_OFF selftest for UDP. In this patch, I mainly do > > three things: > > 1. rename tcp_so_peek_off.c > > 2. adjust for UDP protocol > > 3. add selftests into it > > > > Suggest

Re: [PATCH net-next] selftests: add selftest for UDP SO_PEEK_OFF support

2024-09-02 Thread Willem de Bruijn
Jason Xing wrote: > From: Jason Xing > > Add the SO_PEEK_OFF selftest for UDP. In this patch, I mainly do > three things: > 1. rename tcp_so_peek_off.c > 2. adjust for UDP protocol > 3. add selftests into it > > Suggested-by: Jon Maloy > Signed-off-by: Jason Xing A few minor comments. Nothing

Re: [PATCH v4 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC64

2024-09-02 Thread Jason A. Donenfeld
On Mon, Sep 02, 2024 at 04:27:12PM +0200, Christophe Leroy wrote: > Hi Jason, hi Michael, > > Le 02/09/2024 à 16:19, Jason A. Donenfeld a écrit : > > On Mon, Sep 02, 2024 at 04:16:48PM +0200, Christophe Leroy wrote: > >> Can do that, but there will still be a problem with chacha selftests if > >>

Re: [PATCH v4 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC64

2024-09-02 Thread Christophe Leroy
Hi Jason, hi Michael, Le 02/09/2024 à 16:19, Jason A. Donenfeld a écrit : On Mon, Sep 02, 2024 at 04:16:48PM +0200, Christophe Leroy wrote: Can do that, but there will still be a problem with chacha selftests if I don't opt-out the entire function content when it is ppc64. It will build properl

Re: [PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

2024-09-02 Thread Christophe Leroy
Le 02/09/2024 à 16:18, Christophe Leroy a écrit : Le 02/09/2024 à 15:57, Jason A. Donenfeld a écrit : On Mon, Sep 02, 2024 at 03:23:47PM +0200, Christophe Leroy wrote: Le 02/09/2024 à 14:37, Mark Brown a écrit : On Mon, Sep 02, 2024 at 02:22:38PM +0200, Christophe Leroy wrote: When vds

Re: [PATCH v4 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC64

2024-09-02 Thread Jason A. Donenfeld
On Mon, Sep 02, 2024 at 04:16:48PM +0200, Christophe Leroy wrote: > Can do that, but there will still be a problem with chacha selftests if > I don't opt-out the entire function content when it is ppc64. It will > build properly but if someone runs it on a ppc64 it will likely crash > because on

Re: [PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

2024-09-02 Thread Christophe Leroy
Le 02/09/2024 à 15:57, Jason A. Donenfeld a écrit : On Mon, Sep 02, 2024 at 03:23:47PM +0200, Christophe Leroy wrote: Le 02/09/2024 à 14:37, Mark Brown a écrit : On Mon, Sep 02, 2024 at 02:22:38PM +0200, Christophe Leroy wrote: When vdso_test_getcpu doesn't find the vDSO entry point, it

Re: [PATCH v4 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC64

2024-09-02 Thread Christophe Leroy
Le 02/09/2024 à 16:00, Jason A. Donenfeld a écrit : On Mon, Sep 02, 2024 at 03:12:47PM +0200, Christophe Leroy wrote: Le 02/09/2024 à 14:41, Jason A. Donenfeld a écrit : On Mon, Sep 02, 2024 at 02:04:42PM +0200, Christophe Leroy wrote: SYM_FUNC_START(__arch_chacha20_blocks_nostack)

Re: [PATCH v4 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC64

2024-09-02 Thread Jason A. Donenfeld
On Mon, Sep 02, 2024 at 03:12:47PM +0200, Christophe Leroy wrote: > > > Le 02/09/2024 à 14:41, Jason A. Donenfeld a écrit : > > On Mon, Sep 02, 2024 at 02:04:42PM +0200, Christophe Leroy wrote: > >> SYM_FUNC_START(__arch_chacha20_blocks_nostack) > >> #ifdef __powerpc64__ > >> - blr > >> + s

Re: [PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

2024-09-02 Thread Jason A. Donenfeld
On Mon, Sep 02, 2024 at 03:23:47PM +0200, Christophe Leroy wrote: > > > Le 02/09/2024 à 14:37, Mark Brown a écrit : > > On Mon, Sep 02, 2024 at 02:22:38PM +0200, Christophe Leroy wrote: > > > >> When vdso_test_getcpu doesn't find the vDSO entry point, it prints an error > >> text and returns KSF

Re: [PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

2024-09-02 Thread Christophe Leroy
Le 02/09/2024 à 14:37, Mark Brown a écrit : On Mon, Sep 02, 2024 at 02:22:38PM +0200, Christophe Leroy wrote: When vdso_test_getcpu doesn't find the vDSO entry point, it prints an error text and returns KSFT_SKIP I thought it would be more correct to have the same behaviour on vdso_test_g

Re: [PATCH v4 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC64

2024-09-02 Thread Christophe Leroy
Le 02/09/2024 à 14:41, Jason A. Donenfeld a écrit : On Mon, Sep 02, 2024 at 02:04:42PM +0200, Christophe Leroy wrote: SYM_FUNC_START(__arch_chacha20_blocks_nostack) #ifdef __powerpc64__ - blr + std r5, -216(r1) + + std r14, -144(r1) + std r15, -136(r1)

Re: [PATCH v4 4/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC32

2024-09-02 Thread Christophe Leroy
Le 02/09/2024 à 14:34, Jason A. Donenfeld a écrit : On Mon, Sep 02, 2024 at 02:04:41PM +0200, Christophe Leroy wrote: This first patch adds support for PPC32. As selftests cannot easily be generated only for PPC32, and because the following patch brings support for PPC64 anyway, this patch op

Re: [PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

2024-09-02 Thread Jason A. Donenfeld
On Mon, Sep 02, 2024 at 12:39:17PM +, LEROY Christophe wrote: > > > Le 02/09/2024 à 03:20, Jason A. Donenfeld a écrit : > > On Sun, Sep 01, 2024 at 08:43:10PM +0200, Christophe Leroy wrote: > How would this fit in the logic where IIUC you just remove '_64' from > 'x86_64' to get 'x8

Re: [PATCH v4 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC64

2024-09-02 Thread Jason A. Donenfeld
On Mon, Sep 02, 2024 at 02:04:42PM +0200, Christophe Leroy wrote: > SYM_FUNC_START(__arch_chacha20_blocks_nostack) > #ifdef __powerpc64__ > - blr > + std r5, -216(r1) > + > + std r14, -144(r1) > + std r15, -136(r1) > + std r16, -128(r1) > + std r17, -12

Re: [PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

2024-09-02 Thread LEROY Christophe
Le 02/09/2024 à 03:20, Jason A. Donenfeld a écrit : > On Sun, Sep 01, 2024 at 08:43:10PM +0200, Christophe Leroy wrote: How would this fit in the logic where IIUC you just remove '_64' from 'x86_64' to get 'x86' >>> >>> Huh? That's not what tools/scripts/Makefile.arch does. >> >> Hum ..

Re: [PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

2024-09-02 Thread Mark Brown
On Mon, Sep 02, 2024 at 02:22:38PM +0200, Christophe Leroy wrote: > When vdso_test_getcpu doesn't find the vDSO entry point, it prints an error > text and returns KSFT_SKIP > I thought it would be more correct to have the same behaviour on > vdso_test_getrandom instead of trying to build it only

Re: [PATCH v4 4/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC32

2024-09-02 Thread Jason A. Donenfeld
On Mon, Sep 02, 2024 at 02:04:41PM +0200, Christophe Leroy wrote: > This first patch adds support for PPC32. As selftests cannot easily > be generated only for PPC32, and because the following patch brings > support for PPC64 anyway, this patch opts out all code in > __arch_chacha20_blocks_nostack(

Re: [PATCH] selftests: vDSO: Do not rely on $ARCH for vdso_test_getrandom && vdso_test_chacha

2024-09-02 Thread Christophe Leroy
Hi Jason, Le 01/09/2024 à 15:22, Jason A. Donenfeld a écrit : Hi Christophe, Hmm, I'm not so sure I like this very much. I think it's important for these tests to fail when an arch tries to hook up the function to the vDSO, but it's still not exported for some reason. This also regresses the AR

[PATCH net-next v17 11/14] mm: page_frag: add testing for the newly added prepare API

2024-09-02 Thread Yunsheng Lin
Add testing for the newly added prepare API, for both aligned and non-aligned API, also probe API is also tested along with prepare API. CC: Alexander Duyck Signed-off-by: Yunsheng Lin --- .../selftests/mm/page_frag/page_frag_test.c | 66 +-- tools/testing/selftests/mm/run_vmt

[PATCH net-next v17 04/14] mm: page_frag: avoid caller accessing 'page_frag_cache' directly

2024-09-02 Thread Yunsheng Lin
Use appropriate frag_page API instead of caller accessing 'page_frag_cache' directly. CC: Alexander Duyck Signed-off-by: Yunsheng Lin Reviewed-by: Alexander Duyck Acked-by: Chuck Lever --- drivers/vhost/net.c | 2 +- include/linux/page_frag_cache.h

[PATCH net-next v17 02/14] mm: move the page fragment allocator from page_alloc into its own file

2024-09-02 Thread Yunsheng Lin
Inspired by [1], move the page fragment allocator from page_alloc into its own c file and header file, as we are about to make more change for it to replace another page_frag implementation in sock.c As this patchset is going to replace 'struct page_frag' with 'struct page_frag_cache' in sched.h,

[PATCH net-next v17 01/14] mm: page_frag: add a test module for page_frag

2024-09-02 Thread Yunsheng Lin
The testing is done by ensuring that the fragment allocated from a frag_frag_cache instance is pushed into a ptr_ring instance in a kthread binded to a specified cpu, and a kthread binded to a specified cpu will pop the fragment from the ptr_ring and free the fragment. CC: Alexander Duyck Signed-

[PATCH v4 5/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC64

2024-09-02 Thread Christophe Leroy
Extend getrandom() vDSO implementation to powerpc64. Tested on QEMU on both ppc64_defconfig and ppc64le_defconfig. The results are not precise as it is QEMU on an x86 laptop, but no need to be precise to see the benefit. ~ # ./vdso_test_getrandom bench-single vdso: 2500 times in 4.971

[PATCH v4 4/5] powerpc/vdso: Wire up getrandom() vDSO implementation on PPC32

2024-09-02 Thread Christophe Leroy
To be consistent with other VDSO functions, the function is called __kernel_getrandom() __arch_chacha20_blocks_nostack() fonction is implemented basically with 32 bits operations. It performs 4 QUARTERROUND operations in parallele. There are enough registers to avoid using the stack: On input:

[PATCH v4 3/5] powerpc/vdso: Refactor CFLAGS for CVDSO build

2024-09-02 Thread Christophe Leroy
In order to avoid two much duplication when we add new VDSO functionnalities in C like getrandom, refactor common CFLAGS. Signed-off-by: Christophe Leroy --- v3: Also refactor removed flags --- arch/powerpc/kernel/vdso/Makefile | 32 +-- 1 file changed, 13 insertions(

[PATCH v4 2/5] powerpc/vdso32: Add crtsavres

2024-09-02 Thread Christophe Leroy
Commit 08c18b63d965 ("powerpc/vdso32: Add missing _restgpr_31_x to fix build failure") added _restgpr_31_x to the vdso for gettimeofday, but the work on getrandom shows that we will need more of those functions. Remove _restgpr_31_x and link in crtsavres.o so that we get all save/restore functions

[PATCH v4 1/5] mm: Define VM_DROPPABLE for powerpc/32

2024-09-02 Thread Christophe Leroy
Commit 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings") only adds VM_DROPPABLE for 64 bits architectures. In order to also use the getrandom vDSO implementation on powerpc/32, use VM_ARCH_1 for VM_DROPPABLE on powerpc/32. This is possible because VM_ARCH_1 is

[PATCH v4 0/5] Wire up getrandom() vDSO implementation on powerpc

2024-09-02 Thread Christophe Leroy
This series wires up getrandom() vDSO implementation on powerpc. Tested on PPC32 on real hardware. Tested on PPC64 (both BE and LE) on QEMU: Performance on powerpc 885: ~# ./vdso_test_getrandom bench-single vdso: 2500 times in 62.938002291 seconds libc: 2500

[PATCH v2 3/3] selftests: kvm: s390: Verify reject memory region operations for ucontrol VMs

2024-09-02 Thread Christoph Schlameuss
Add a test case verifying KVM_SET_USER_MEMORY_REGION and KVM_SET_USER_MEMORY_REGION2 cannot be executed on ucontrol VMs. Executing this test case on not patched kernels will cause a null pointer dereference in the host kernel. This is fixed with commit: commit 7816e58967d0 ("kvm: s390: Reject memo

[PATCH v2 1/3] selftests: kvm: s390: Add uc_map_unmap VM test case

2024-09-02 Thread Christoph Schlameuss
Add a test case verifying basic running and interaction of ucontrol VMs. Fill the segment and page tables for allocated memory and map memory on first access. * uc_map_unmap Store and load data to mapped and unmapped memory and use pic segment translation handling to map memory on access. Sig

[PATCH v2 2/3] selftests: kvm: s390: Add uc_skey VM test case

2024-09-02 Thread Christoph Schlameuss
Add a test case manipulating s390 storage keys from within the ucontrol VM. Signed-off-by: Christoph Schlameuss --- .../selftests/kvm/s390x/ucontrol_test.c | 89 ++- 1 file changed, 88 insertions(+), 1 deletion(-) diff --git a/tools/testing/selftests/kvm/s390x/ucontrol_tes

[PATCH v2 0/3] selftests: kvm: s390: Add ucontrol memory selftests

2024-09-02 Thread Christoph Schlameuss
This patch series adds a some not yet picked selftests to the kvm s390x selftest suite. The additional test cases are covering: * Assert KVM_EXIT_S390_UCONTROL exit on not mapped memory access * Assert functionality of storage keys in ucontrol VM * Assert that memory region operations are rejected

[PATCH net-next 3/3] selftests: mptcp: reset the last TS before the first test

2024-09-02 Thread Matthieu Baerts (NGI0)
Just to slightly improve the precision of the duration of the first test. In mptcp_join.sh, the last append_prev_results is now done as soon as the last test is over: this will add the last result in the list, and get a more precise time for this last test. Reviewed-by: Mat Martineau Signed-off-

[PATCH net-next 2/3] sefltests: mptcp: connect: remote time in TAP output

2024-09-02 Thread Matthieu Baerts (NGI0)
It is now added by the MPTCP lib automatically, see the parent commit. The time in the TAP output might be sligly different from the one displayed before, but that's OK. Reviewed-by: Mat Martineau Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_connect.sh | 1

[PATCH net-next 1/3] selftests: mptcp: lib: add time per subtests in TAP output

2024-09-02 Thread Matthieu Baerts (NGI0)
It adds 'time=ms' in the diagnostic data of the TAP output, e.g. ok 1 - pm_netlink: defaults addr list # time=9ms This addition is useful to quickly identify which subtests are taking a longer time than the others, or more than expected. Note that there are no specific formats to follow to sho

[PATCH net-next 0/3] selftests: mptcp: add time per subtests in TAP output

2024-09-02 Thread Matthieu Baerts (NGI0)
ase-commit: 221f9cce949ac8042f65b71ed1fde13b99073256 change-id: 20240902-net-next-mptcp-ksft-subtest-time-a83cec43d894 Best regards, -- Matthieu Baerts (NGI0)

[PATCH net-next 11/11] selftests: mptcp: pm_nl_ctl: remove re-definition

2024-09-02 Thread Matthieu Baerts (NGI0)
'MPTCP_PM_NAME' is defined in 'linux/mptcp_pm.h', included in 'linux/mptcp.h', no need to re-define it. 'MPTCP_PM_EVENTS' is not defined in 'linux/mptcp.h', but 'MPTCP_PM_EV_GRP_NAME' is, with the same value. We can then use the latter, and drop the other one. Reviewed-by: Geliang Tang Signed-of

[PATCH net-next 10/11] selftests: mptcp: join: simplify checksum_tests

2024-09-02 Thread Matthieu Baerts (NGI0)
From: Geliang Tang The four checksum tests are similar, only one line is different. So a for-loop can be used to simplify these tests. Signed-off-by: Geliang Tang Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh | 4

[PATCH net-next 09/11] selftests: mptcp: join: mute errors when ran in the background

2024-09-02 Thread Matthieu Baerts (NGI0)
The test is supposed to be killed before the end, which will likely cause "Connection reset by peer" errors. It is confusing, especially because in case of real transfer errors, the test will not be marked as failed. But that's OK, there are many other tests checking that. Reviewed-by: Geliang Tan

[PATCH net-next 08/11] selftests: mptcp: join: specify host being checked

2024-09-02 Thread Matthieu Baerts (NGI0)
Instead of displaying 'invert' when looking at some events like MP_FAIL, MP_FASTCLOSE, MP_RESET, RM_ADDR, which is a bit vague because they are not traditionnaly sent from one side, the host being checked is now printed. For the ADD_ADDR, only display the host when it is the client sending it, whi

[PATCH net-next 07/11] selftests: mptcp: join: more explicit check name

2024-09-02 Thread Matthieu Baerts (NGI0)
Before, the check names had to be very short. It is no longer the case now that these checks are printed on a dedicated line. Then, it looks better to have more explicit names. Reviewed-by: Geliang Tang Signed-off-by: Matthieu Baerts (NGI0) --- tools/testing/selftests/net/mptcp/mptcp_join.sh |

[PATCH net-next 06/11] selftests: mptcp: join: validate MPJ SYN TX MIB counters

2024-09-02 Thread Matthieu Baerts (NGI0)
A few new MPJoinSynTx MIB counters have been added in a previous commit. They are being validated here in mptcp_join.sh selftest, each time the number of received MPJ are checked. Most of the time, the number of sent SYN+MPJ is the same as the received ones. But sometimes, there are more, because

[PATCH net-next 05/11] selftests: mptcp: join: one line for join check

2024-09-02 Thread Matthieu Baerts (NGI0)
Most tests are checking if the expected number of SYN/SYN+ACK/ACK JOINs have been received, each of them on one line. More Join related tests are going to be checked soon, no need to add 5 new lines per test in case of success, just one is enough. In case of issue, the errors will still be reporte

[PATCH net-next 04/11] selftests: mptcp: join: reduce join_nr params

2024-09-02 Thread Matthieu Baerts (NGI0)
chk_join_nr() currently takes 9 positional parameters, 6 of them are optional. It makes it hard to read: chk_join_nr 1 1 1 1 0 1 1 0 4 Naming these vars helps to make it easier to read: join_csum_ns1=1 join_csum_ns2=0 \ join_fail_nr=1 join_rst_nr=1 join_infi_nr=0 \ join_corrupted_pkt

[PATCH net-next 03/11] mptcp: MIB counters for sent MP_JOIN

2024-09-02 Thread Matthieu Baerts (NGI0)
Recently, a few issues have been discovered around the creation of additional subflows. Without these counters, it was difficult to point out the reason why some subflows were not created as expected. These counters should have been added earlier, because there is no other simple ways to extract s

[PATCH net-next 02/11] mptcp: pm: reduce entries iterations on connect

2024-09-02 Thread Matthieu Baerts (NGI0)
__mptcp_subflow_connect() is currently called from the path-managers, which have all the required information to create subflows. No need to call the PM again to re-iterate over the list of entries with RCU lock to get more info. Instead, it is possible to pass a mptcp_pm_addr_entry structure, ins

[PATCH net-next 01/11] mptcp: pm: rename helpers linked to 'flush'

2024-09-02 Thread Matthieu Baerts (NGI0)
Rename all the helpers specific to the flushing operations to make it clear that the intention is to flush all created subflows, and remove all announced addresses, not just a specific selection. That way, it is easier to understand why the id_avail_bitmap and local_addr_used are reset at the end.

[PATCH net-next 00/11] mptcp: MIB counters for MPJ TX + misc improvements

2024-09-02 Thread Matthieu Baerts (NGI0)
files changed, 309 insertions(+), 254 deletions(-) --- base-commit: 221f9cce949ac8042f65b71ed1fde13b99073256 change-id: 20240902-net-next-mptcp-mib-mpjtx-misc-d80298438016 Best regards, -- Matthieu Baerts (NGI0)

[PATCH] selftests/bpf: Fix procmap_query()'s params mismatch and compilation warning

2024-09-02 Thread Yuan Chen
From: Yuan Chen When the PROCMAP_QUERY is not defined, a compilation error occurs due to the mismatch of the procmap_query()'s params, procmap_query() only be called in the file where the function is defined, modify the params so they can match. We get a warning when build samples/bpf: trace

Re: [PATCH RFC 3/8] openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)

2024-09-02 Thread Arnd Bergmann
On Mon, Sep 2, 2024, at 07:06, Aleksa Sarai wrote: > While we do currently return -EFAULT in this case, it seems prudent to > follow the behaviour of other syscalls like clone3. It seems quite > unlikely that anyone depends on this error code being EFAULT, but we can > always revert this if it turn

Re: [PATCH RFC 1/8] uaccess: add copy_struct_to_user helper

2024-09-02 Thread Arnd Bergmann
On Mon, Sep 2, 2024, at 07:06, Aleksa Sarai wrote: > This is based on copy_struct_from_user(), but there is one additional > case to consider when creating a syscall that returns an > extensible-struct to userspace -- how should data in the struct that > cannot fit into the userspace struct be hand

Re: [PATCH bpf-next v4 4/8] libbpf: Support BTF.ext loading and output in either endianness

2024-09-02 Thread Tony Ambardar
On Fri, Aug 30, 2024 at 02:14:19PM -0700, Andrii Nakryiko wrote: > On Fri, Aug 30, 2024 at 12:30 AM Tony Ambardar > wrote: > > > > Support for handling BTF data of either endianness was added in [1], but > > did not include BTF.ext data for lack of use cases. Later, support for > > static linking

[PATCH RFC 8/8] selftests: clone3: add CHECK_FIELDS selftests

2024-09-02 Thread Aleksa Sarai
Signed-off-by: Aleksa Sarai --- tools/testing/selftests/clone3/.gitignore | 1 + tools/testing/selftests/clone3/Makefile| 2 +- .../testing/selftests/clone3/clone3_check_fields.c | 229 + 3 files changed, 231 insertions(+), 1 deletion(-) diff --git a/

[PATCH RFC 7/8] selftests: openat2: add CHECK_FIELDS selftests

2024-09-02 Thread Aleksa Sarai
Signed-off-by: Aleksa Sarai --- tools/testing/selftests/openat2/openat2_test.c | 122 - 1 file changed, 120 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/openat2/openat2_test.c b/tools/testing/selftests/openat2/openat2_test.c index 4ca175a16ad6..8afb

[PATCH RFC 6/8] selftests: openat2: add 0xFF poisoned data after misaligned struct

2024-09-02 Thread Aleksa Sarai
We should also verify that poisoned data after a misaligned struct is also handled correctly by is_zeroed_user(). This test passes with no kernel changes needed, so is_zeroed_user() was correct already. Fixes: b28a10aedcd4 ("selftests: add openat2(2) selftests") Signed-off-by: Aleksa Sarai --- t

[PATCH RFC 5/8] clone3: add CHECK_FIELDS flag to usize argument

2024-09-02 Thread Aleksa Sarai
As with openat2(2), this allows userspace to easily figure out what flags and fields are supported by clone3(2). For fields which are not flag-based, we simply set every bit in the field so that a naive bitwise-and would show that any value of the field is valid. For args->exit_signal, since we ha

[PATCH RFC 4/8] openat2: add CHECK_FIELDS flag to usize argument

2024-09-02 Thread Aleksa Sarai
In order for userspace to be able to know what flags and fields the kernel supports, it is currently necessary for them to do a bunch of fairly subtle self-checks where you need to get a syscall to return a non-EINVAL error or no-op for each flag you wish to use. If you get -EINVAL you know the fla

[PATCH RFC 3/8] openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)

2024-09-02 Thread Aleksa Sarai
While we do currently return -EFAULT in this case, it seems prudent to follow the behaviour of other syscalls like clone3. It seems quite unlikely that anyone depends on this error code being EFAULT, but we can always revert this if it turns out to be an issue. Cc: # v5.6+ Fixes: fddb5d430ad9 ("o

[PATCH RFC 2/8] sched_getattr: port to copy_struct_to_user

2024-09-02 Thread Aleksa Sarai
sched_getattr(2) doesn't care about trailing non-zero bytes in the (ksize > usize) case, so just use copy_struct_to_user() without checking ignored_trailing. Signed-off-by: Aleksa Sarai --- kernel/sched/syscalls.c | 42 ++ 1 file changed, 2 insertions(+),

[PATCH RFC 1/8] uaccess: add copy_struct_to_user helper

2024-09-02 Thread Aleksa Sarai
This is based on copy_struct_from_user(), but there is one additional case to consider when creating a syscall that returns an extensible-struct to userspace -- how should data in the struct that cannot fit into the userspace struct be handled (ksize > usize)? There are three possibilies: 1. The

[PATCH RFC 0/8] extensible syscalls: CHECK_FIELDS to allow for easier feature detection

2024-09-02 Thread Aleksa Sarai
This is something that I've been thinking about for a while. We had a discussion at LPC 2020 about this[1] but the proposals suggested there never materialised. In short, it is quite difficult for userspace to detect the feature capability of syscalls at runtime. This is something a lot of program