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
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
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(+),
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
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
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
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
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
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/
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
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
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
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
files changed, 309 insertions(+), 254 deletions(-)
---
base-commit: 221f9cce949ac8042f65b71ed1fde13b99073256
change-id: 20240902-net-next-mptcp-mib-mpjtx-misc-d80298438016
Best regards,
--
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.
__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
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
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
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
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
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 |
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
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
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
'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
ase-commit: 221f9cce949ac8042f65b71ed1fde13b99073256
change-id: 20240902-net-next-mptcp-ksft-subtest-time-a83cec43d894
Best regards,
--
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
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
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-
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
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
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
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
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
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
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
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(
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:
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
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-
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,
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
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
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
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(
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
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 ..
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
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
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
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)
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
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
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
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)
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
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
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
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
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
> >>
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
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
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
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
>
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
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
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
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
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/
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
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
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
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 +
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
> > >
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
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
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
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
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
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
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
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
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
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:
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
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
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
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(
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:
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
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
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
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
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
94 matches
Mail list logo
