Add selftest for cases where btf_name_valid_section() does not properly
check for certain types of names.
Suggested-by: Eduard Zingerman
Signed-off-by: Jeongjun Park
---
tools/testing/selftests/bpf/prog_tests/btf.c | 34
1 file changed, 34 insertions(+)
diff --git a/tools
If the length of the name string is 1 and the value of name[0] is NULL
byte, an OOB vulnerability occurs in btf_name_valid_section() and the
return value is true, so the invalid name passes the check.
To solve this, you need to check if the first position is NULL byte and
if the first character i
This patch was written to fix an issue where btf_name_valid_section() would
not properly check names with certain conditions and would throw an OOB vuln.
And selftest was added to verify this patch.
Jeongjun Park (2):
bpf: add check for invalid name in btf_name_valid_section()
selftest/bpf :
On 8/30/24 8:37 PM, Shuah Khan wrote:
On 8/27/24 21:40, Rong Tao wrote:
From: Rong Tao
Add test scripts and prompts.
Can you give more details on what these scripts and prompts do?
I just push
v2(https://lore.kernel.org/lkml/tencent_0aea8fb622de1a740841643d5f36abf8b...@qq.com/)
At the
From: Rong Tao
Give the programmer more help information to inform the program on how to
use it.
Signed-off-by: Rong Tao
---
tools/testing/selftests/splice/splice_read.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/splice/splice_read.c
b/
On 2024-08-27 00:36, Charlie Jenkins wrote:
The hint address should not forcefully restrict the addresses returned
by mmap as this causes mmap to report ENOMEM when there is memory still
available.
Signed-off-by: Charlie Jenkins
Fixes: b5b4287accd7 ("riscv: mm: Use hint address in mmap if avail
On Fri, Aug 30, 2024 at 10:52:01AM +0100, Lorenzo Stoakes wrote:
> On Thu, Aug 29, 2024 at 03:16:53PM GMT, Charlie Jenkins wrote:
> > On Thu, Aug 29, 2024 at 10:54:25AM +0100, Lorenzo Stoakes wrote:
> > > On Thu, Aug 29, 2024 at 09:42:22AM GMT, Lorenzo Stoakes wrote:
> > > > On Thu, Aug 29, 2024 at
On Fri, 2024-08-30 at 14:25 -0700, Andrii Nakryiko wrote:
[...]
> > err = bpf_object__elf_init(obj);
> > - err = err ? : bpf_object__check_endianness(obj);
> > err = err ? : bpf_object__elf_collect(obj);
> > err = err ? : bpf_object__collect_externs(obj);
> >
On Fri, Aug 30, 2024 at 2:31 PM Andrii Nakryiko
wrote:
>
>
>
> for the rest, Alexei, can you please review and give your ack?
It looks fine.
All of the additional pr_debug()s look a bit excessive.
Will take another look at respin.
On Fri, 2024-08-30 at 00:29 -0700, Tony Ambardar wrote:
[...]
> @@ -940,6 +942,21 @@ bpf_object__add_programs(struct bpf_object *obj,
> Elf_Data *sec_data,
> return 0;
> }
>
> +static void bpf_object_bswap_progs(struct bpf_object *obj)
> +{
> + struct bpf_program *prog = obj->progra
On Thu, 29 Aug 2024 13:09:41 +0100 Lorenzo Stoakes
wrote:
> Relevant section from MAINTAINERS:
>
> MEMORY MAPPING
I always thought it meant "memory management" ;)
ncdevmem is a devmem TCP netcat. It works similarly to netcat, but it
sends and receives data using the devmem TCP APIs. It uses udmabuf as
the dmabuf provider. It is compatible with a regular netcat running on
a peer, or a ncdevmem running on a peer.
In addition to normal netcat support, ncdevmem
Add dmabuf information to page_pool stats:
$ ./cli.py --spec ../netlink/specs/netdev.yaml --dump page-pool-get
...
{'dmabuf': 10,
'id': 456,
'ifindex': 3,
'inflight': 1023,
'inflight-mem': 4190208},
{'dmabuf': 10,
'id': 455,
'ifindex': 3,
'inflight': 1023,
'inflight-mem': 4190208
Add an interface for the user to notify the kernel that it is done
reading the devmem dmabuf frags returned as cmsg. The kernel will
drop the reference on the frags to make them available for reuse.
Signed-off-by: Willem de Bruijn
Signed-off-by: Kaiyuan Zhang
Signed-off-by: Mina Almasry
Reviewe
Add documentation outlining the usage and details of devmem TCP.
Signed-off-by: Mina Almasry
Reviewed-by: Bagas Sanjaya
Reviewed-by: Donald Hunter
---
v16:
- Add documentation on unbinding the NIC from dmabuf (Donald).
- Add note that any dmabuf should work (Donald).
v9:
https://lore.kernel
In tcp_recvmsg_locked(), detect if the skb being received by the user
is a devmem skb. In this case - if the user provided the MSG_SOCK_DEVMEM
flag - pass it to tcp_recvmsg_devmem() for custom handling.
tcp_recvmsg_devmem() copies any data in the skb header to the linear
buffer, and returns a cmsg
For device memory TCP, we expect the skb headers to be available in host
memory for access, and we expect the skb frags to be in device memory
and unaccessible to the host. We expect there to be no mixing and
matching of device memory frags (unaccessible) with host memory frags
(accessible) in the
Make skb_frag_page() fail in the case where the frag is not backed
by a page, and fix its relevant callers to handle this case.
Signed-off-by: Mina Almasry
Reviewed-by: Eric Dumazet
---
v10:
- Fixed newly generated kdoc warnings found by patchwork. While we're
at it, fix the Return section
Implement a memory provider that allocates dmabuf devmem in the form of
net_iov.
The provider receives a reference to the struct netdev_dmabuf_binding
via the pool->mp_priv pointer. The driver needs to set this pointer for
the provider in the net_iov.
The provider obtains a reference on the netde
Convert netmem to be a union of struct page and struct netmem. Overload
the LSB of struct netmem* to indicate that it's a net_iov, otherwise
it's a page.
Currently these entries in struct page are rented by the page_pool and
used exclusively by the net stack:
struct {
unsigned long pp_mag
Implement netdev devmem allocator. The allocator takes a given struct
netdev_dmabuf_binding as input and allocates net_iov from that
binding.
The allocation simply delegates to the binding's genpool for the
allocation logic and wraps the returned memory region in a net_iov
struct.
Signed-off-by:
Add a netdev_dmabuf_binding struct which represents the
dma-buf-to-netdevice binding. The netlink API will bind the dma-buf to
rx queues on the netdevice. On the binding, the dma_buf_attach
& dma_buf_map_attachment will occur. The entries in the sg_table from
mapping will be inserted into a genpool
API takes the dma-buf fd as input, and binds it to the netdevice. The
user can specify the rx queues to bind the dma-buf to.
Suggested-by: Stanislav Fomichev
Signed-off-by: Mina Almasry
Reviewed-by: Donald Hunter
Reviewed-by: Jakub Kicinski
---
v16:
- Use subset-of: queue queue-id instead of
Add netdev_rx_queue_restart(), which resets an rx queue using the
queue API recently merged[1].
The queue API was merged to enable the core net stack to reset individual
rx queues to actuate changes in the rx queue's configuration. In later
patches in this series, we will use netdev_rx_queue_resta
v24: https://patchwork.kernel.org/project/netdevbpf/list/?series=884556&state=*
Changes:
- Fix failing ynl regen error.
- Error path fixes & extack error messages in dmabuf binding.
Full devmem TCP changes including the full GVE driver implementation is
here:
https://github.com/mina/linux/c
On Tue, 09 Jul 2024 11:29:36 -0700, Peter Gonda wrote:
> Regression test for ae20eef5 ("KVM: SVM: Update SEV-ES shutdown intercepts
> with more metadata"). Test confirms userspace is correctly indicated of
> a guest shutdown not previous behavior of an EINVAL from KVM_RUN.
Applied to kvm-x86 selft
On Fri, 2024-08-30 at 00:29 -0700, Tony Ambardar wrote:
[...]
> @@ -3050,11 +3127,42 @@ static int btf_ext_parse_hdr(__u8 *data, __u32
> data_size)
> return -ENOTSUP;
> }
>
> - if (data_size == hdr->hdr_len) {
> + if (data_size < hdr_len) {
> + pr_debug(
On Fri, Aug 30, 2024 at 12:23 PM Lorenzo Stoakes
wrote:
>
> On Fri, Aug 30, 2024 at 07:43:12PM GMT, Lorenzo Stoakes wrote:
> > On Fri, Aug 30, 2024 at 06:02:36PM GMT, jef...@chromium.org wrote:
> > > From: Jeff Xu
> > >
> > > Add sealing test to cover mmap for
> > > Expand/shrink across sealed vm
On Fri, 2024-08-30 at 00:29 -0700, Tony Ambardar wrote:
> Object linking output data uses the default ELF_T_BYTE type for '.symtab'
> section data, which disables any libelf-based translation. Explicitly set
> the ELF_T_SYM type for output to restore libelf's byte-order conversion,
> noting that in
Jakub Kicinski wrote:
> On Fri, 30 Aug 2024 14:47:43 -0400 Willem de Bruijn wrote:
> > > We have directories in net/lib, and it's a target, and it works, no?
> >
> > net/lib is not a TARGET in tools/testing/selftests/Makefile. Its
> > Makefile only generates dependencies for other targets: TEST_
Willem de Bruijn wrote:
> Jakub Kicinski wrote:
> > On Fri, 30 Aug 2024 11:20:05 -0400 Willem de Bruijn wrote:
> > > Kselftest install does not preserve directories.
> > >
> > > So all .pkt files are copied into net/packetdrill root. This is messy.
> > > More fundamentally it breaks the includes i
On Fri, 30 Aug 2024 14:47:43 -0400 Willem de Bruijn wrote:
> > We have directories in net/lib, and it's a target, and it works, no?
>
> net/lib is not a TARGET in tools/testing/selftests/Makefile. Its
> Makefile only generates dependencies for other targets: TEST_FILES,
> TEST_GEN_FILES and TEST
On Fri, Aug 30, 2024 at 12:30 AM Tony Ambardar wrote:
>
> Track target endianness in 'struct bpf_gen' and process in-memory data in
> native byte-order, but on finalization convert the embedded loader BPF
> insns to target endianness.
>
> The light skeleton also includes a target-accessed data blo
On Fri, Aug 30, 2024 at 12:30 AM Tony Ambardar wrote:
>
> Allow bpf_object__open() to access files of either endianness, and convert
> included BPF programs to native byte-order in-memory for introspection.
> Loading BPF objects of non-native byte-order is still disallowed however.
>
> Signed-off-
On Fri, Aug 30, 2024 at 12:30 AM Tony Ambardar wrote:
>
> Allow static linking object files of either endianness, checking that input
> files have consistent byte-order, and setting output endianness from input.
>
> Linking requires in-memory processing of programs, relocations, sections,
> etc. i
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 [2] provided a use case, but this feature and later ones
> were restricted to
Hello, thank you for reviewing the v2.
> Patch looks fine to me but can you please do the followings?
>
> - Add subsystem prefix to the patch titles. Look other commits for examples.
> - Add Signed-off-by to both.
> --
> tejun
I will send out a v3 with the signed-off-by, and I will add
cgroup/rst
With the current API the only way to remove an allowed IP is to
completely rebuild the allowed IPs set for a peer using
WGPEER_F_REPLACE_ALLOWEDIPS. In other words, if my current configuration
is such that a peer has allowed IP IPs 192.168.0.2 and 192.168.0.3 and I
want to remove 192.168.0.2 the ac
On Fri, Aug 30, 2024 at 07:19:38AM -0700, Joshua Hahn wrote:
> From: Joshua Hahn
>
> Cgroup-level CPU statistics currently include time spent on
> user/system processes, but do not include niced CPU time (despite
> already being tracked). This patch exposes niced CPU time to the
> userspace, allo
On Tue, Aug 20, 2024 at 03:55:34PM -0400, Waiman Long wrote:
> The current cpuset code and test_cpuset_prs.sh test have not fully
> account for the possibility of pre-isolated CPUs added by the "isolcpus"
> boot command line parameter. This patch series modifies them to do the
> right thing whether
On Fri, Aug 30, 2024 at 07:43:12PM GMT, Lorenzo Stoakes wrote:
> On Fri, Aug 30, 2024 at 06:02:36PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add sealing test to cover mmap for
> > Expand/shrink across sealed vmas (MAP_FIXED)
> > Reuse the same address in !MAP_FIXED case.
>
> This
On Fri, Aug 30, 2024 at 06:02:32PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> This series increase the test coverage of mseal_test by:
>
> Add check for vma_size, prot, and error code for existing tests.
> Add more testcases for madvise, munmap, mmap and mremap to cover
> sealing in diffe
Le 30/08/2024 à 18:17, Jason A. Donenfeld a écrit :
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
@@ -14,6 +14,10 @@ ifeq ($(uname_M),x86_64)
TEST_GEN_PROGS += vdso_test_getrandom
TEST_GEN_PROGS += vdso_test_chacha
endif
+ifeq ($(ARCH),powerpc)
+TEST_GEN_PROGS += vds
Jakub Kicinski wrote:
> On Fri, 30 Aug 2024 11:20:05 -0400 Willem de Bruijn wrote:
> > Kselftest install does not preserve directories.
> >
> > So all .pkt files are copied into net/packetdrill root. This is messy.
> > More fundamentally it breaks the includes in the files (e..g, `source
> > ../co
On Fri, Aug 30, 2024 at 06:02:36PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add sealing test to cover mmap for
> Expand/shrink across sealed vmas (MAP_FIXED)
> Reuse the same address in !MAP_FIXED case.
This commit message is woefully small. I told you on v1 to improve the
commit messa
From: Jeff Xu
Add sealing test to cover mremap for
Expand/shrink/move across vmas.
Signed-off-by: Jeff Xu
---
tools/testing/selftests/mm/mseal_test.c | 202 +++-
1 file changed, 201 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/mm/mseal_test.c
b/tools/
From: Jeff Xu
Add sealing test to cover mmap for
Expand/shrink across sealed vmas (MAP_FIXED)
Reuse the same address in !MAP_FIXED case.
Signed-off-by: Jeff Xu
---
tools/testing/selftests/mm/mseal_test.c | 126 +++-
1 file changed, 125 insertions(+), 1 deletion(-)
diff --g
From: Jeff Xu
Add a test to munmap across multiple vma ranges.
Signed-off-by: Jeff Xu
---
tools/testing/selftests/mm/mseal_test.c | 80 -
1 file changed, 79 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/mm/mseal_test.c
b/tools/testing/selftests/mm/
From: Jeff Xu
Add more checks for vma size, prot bits and api errcode
after attempt of modifing sealed mappings.
Signed-off-by: Jeff Xu
---
tools/testing/selftests/mm/mseal_test.c | 398
1 file changed, 332 insertions(+), 66 deletions(-)
diff --git a/tools/testing/sel
From: Jeff Xu
Add a testcase to cover all sealed madvise type.
Signed-off-by: Jeff Xu
---
tools/testing/selftests/mm/mseal_test.c | 30 -
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/mm/mseal_test.c
b/tools/testing/selftests/mm/
From: Jeff Xu
This series increase the test coverage of mseal_test by:
Add check for vma_size, prot, and error code for existing tests.
Add more testcases for madvise, munmap, mmap and mremap to cover
sealing in different scenarios.
The increase test coverage hopefully help to prevent future re
On Thu, 29 Aug 2024 22:41:17 -0700 Mina Almasry wrote:
> Thank you, I think the right fix here is to reacquire rtnl_lock before
> the `goto err_unbind;`, since err_unbind expects rtnl to be locked at
> this point.
FWIW it's best to keep the error path a mirror image of the success
path, so I'd add
On Fri, 30 Aug 2024 11:20:05 -0400 Willem de Bruijn wrote:
> Kselftest install does not preserve directories.
>
> So all .pkt files are copied into net/packetdrill root. This is messy.
> More fundamentally it breaks the includes in the files (e..g, `source
> ../common/defaults.sh`).
Can you show
Le 30/08/2024 à 18:42, Christophe Leroy a écrit :
Le 30/08/2024 à 18:14, Jason A. Donenfeld a écrit :
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
+ * r5: 8-byte counter input/output (saved on stack)
+ *
+ * r14-r15: counter
+ */
+SYM_FUNC_START(__arch_chacha20_b
Le 30/08/2024 à 18:14, Jason A. Donenfeld a écrit :
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
+ * r5: 8-byte counter input/output (saved on stack)
+ *
+ * r14-r15: counter
+ */
+SYM_FUNC_START(__arch_chacha20_blocks_nostack)
+ stwur1, -96(r1)
+
On 8/27/24 17:16, Dev Jain wrote:
On 8/27/24 17:14, Shuah Khan wrote:
On 8/22/24 06:14, Dev Jain wrote:
Rename sigaltstack to generic signal directory, to allow adding more
signal tests in the future.
Sorry - I think I mentioned I don't like this test renamed. Why are
you sending
this re
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
> @@ -14,6 +14,10 @@ ifeq ($(uname_M),x86_64)
> TEST_GEN_PROGS += vdso_test_getrandom
> TEST_GEN_PROGS += vdso_test_chacha
> endif
> +ifeq ($(ARCH),powerpc)
> +TEST_GEN_PROGS += vdso_test_getrandom
> +TEST_GEN_PROGS += vdso_test_c
On Fri, Aug 30, 2024 at 05:57:08PM +0200, Christophe Leroy wrote:
> + * r5: 8-byte counter input/output (saved on stack)
> + *
> + * r14-r15: counter
> + */
> +SYM_FUNC_START(__arch_chacha20_blocks_nostack)
> + stwur1, -96(r1)
> + stw r5, 20(r1)
> + stmwr14, 24(r1)
> +
On Fri, 30 Aug 2024 10:59:11 +0530, Dev Jain wrote:
> A "%s" is missing in ksft_exit_fail_msg(); instead, use the newly
> introduced ksft_exit_fail_perror().
>
>
Applied to arm64 (for-next/selftests), thanks!
[1/1] kselftest/arm64: Fix build warnings for ptrace
https://git.kernel.org/arm6
On Thu, 29 Aug 2024 18:20:09 +0100, Mark Brown wrote:
> The test case for SME vector length changes via sigreturn use a bit too
> much cut'n'paste and only actually changed the SVE vector length in the
> test itself. Andre's recent factoring out of the initialisation code caused
> this to be expose
On Fri, Aug 30, 2024 at 05:54:35PM +0200, Jason A. Donenfeld wrote:
> From: Mark Brown
>
> Unlike the check for the standalone x86 test, the check for building the
> vDSO getrandom and chacaha tests looks at the architecture for the host
> rather than the architecture for the target when deciding
Hi Ilpo,
On 8/30/24 4:13 AM, Ilpo Järvinen wrote:
On Thu, 29 Aug 2024, Reinette Chatre wrote:
The benchmark used during the CMT, MBM, and MBA tests can be provided by
the user via (-b) parameter to the tests, if not provided the default
"fill_buf" benchmark is used.
The "fill_buf" benchmark r
Hi Ilpo,
On 8/30/24 4:25 AM, Ilpo Järvinen wrote:
On Thu, 29 Aug 2024, Reinette Chatre wrote:
By default the MBM and MBA tests use the "fill_buf" benchmark to
read from a buffer with the goal to measure the memory bandwidth
generated by this buffer access.
Care should be taken when sizing the
Hi Ilpo,
On 8/30/24 4:42 AM, Ilpo Järvinen wrote:
On Thu, 29 Aug 2024, Reinette Chatre wrote:
The MBA test incrementally throttles memory bandwidth, each time
followed by a comparison between the memory bandwidth observed
by the performance counters and resctrl respectively.
While a compariso
Hi Ilpo,
Thank you for taking a look.
On 8/30/24 3:56 AM, Ilpo Järvinen wrote:
On Thu, 29 Aug 2024, Reinette Chatre wrote:
...
@@ -684,11 +622,13 @@ int resctrl_val(const struct resctrl_test *test,
const char * const *benchmark_cmd,
struct resctrl_val_param
in there (I see the
> master branch is included). This is also breaking in for example
> kernelci:
>
> https://storage.kernelci.org/next/master/next-20240830/x86_64/x86_64_defconfig/gcc-12/logs/kselftest.log
>
> in the same way.
Ahh yea it looks like that is running into the same thing a
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
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:
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(
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
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
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
From: Mark Brown
Unlike the check for the standalone x86 test, the check for building the
vDSO getrandom and chacaha tests looks at the architecture for the host
rather than the architecture for the target when deciding if they should
be built. Since the chacha test includes some assembler code t
Hi Pedro
On Fri, Aug 30, 2024 at 5:57 AM Pedro Falcato wrote:
>
> On Thu, Aug 29, 2024 at 09:43:51PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add sealing test to cover mmap for
> > Expand/shrink across vmas.
> > Reuse the same address in !MAP_FIXED case.
> >
> > Signed-off-by: J
On Fri Aug 23, 2024 at 9:59 AM CEST, Janosch Frank wrote:
> On 8/19/24 6:00 PM, Christoph Schlameuss wrote:
> > On Fri Aug 16, 2024 at 4:36 PM CEST, Janosch Frank wrote:
> >> On 8/15/24 5:45 PM, Christoph Schlameuss wrote:
> [...]
> >>> +TEST_F(uc_kvm, uc_skey)
> >>> +{
> >>> + u64 test_vaddr = sel
On Fri, Aug 30, 2024 at 5:52 AM Pedro Falcato wrote:
>
> On Thu, Aug 29, 2024 at 09:43:50PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add a testcase to cover all sealed madvise type.
> >
> > Signed-off-by: Jeff Xu
> > ---
> > tools/testing/selftests/mm/mseal_test.c | 108 +++
Hi Pedro
On Fri, Aug 30, 2024 at 5:45 AM Pedro Falcato wrote:
>
> On Thu, Aug 29, 2024 at 09:43:49PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > Add check for vma size, prot bits and error return.
> >
> > Signed-off-by: Jeff Xu
> > ---
> > tools/testing/selftests/mm/mseal_test.c
On Fri, Aug 30, 2024 at 05:34:13PM +0200, Jason A. Donenfeld wrote:
> > +ifeq ($(ARCH),$(filter $(ARCH),x86_64))
> Actually... this doesn't work. Because:
> ARCH ?= $(shell echo $(uname_M) | sed -e s/i.86/x86/ -e s/x86_64/x86/)
> The x86_64 gets turned into an x86. It's a little trickier when
>
> That's where all these fixups are going for 6.12. (And yea, there are a
> lot.)
I was using -next, hopefully it's getting merged in there (I see the
master branch is included). This is also breaking in for example
kernelci:
https://storage.kernelci.org/next/master/next-2024083
Hi Pedro
On Fri, Aug 30, 2024 at 5:31 AM Pedro Falcato wrote:
>
> On Thu, Aug 29, 2024 at 09:43:48PM GMT, jef...@chromium.org wrote:
> > From: Jeff Xu
> >
> > This series increase the test coverage of mseal_test by:
> >
> > Add check for vma_size, prot, and error code for existing tests.
> > Add
On Fri, Aug 30, 2024 at 03:06:35PM +0100, Mark Brown wrote:
> Unlike the check for the standalone x86 test the check for building the
> vDSO getrandom and chacaha tests looks at the architecture for the host
> rather than the architecture for the target when deciding if they should
> be built. Sinc
On Fri, Aug 30, 2024 at 03:06:35PM +0100, Mark Brown wrote:
> Unlike the check for the standalone x86 test the check for building the
> vDSO getrandom and chacaha tests looks at the architecture for the host
> rather than the architecture for the target when deciding if they should
> be built. Sinc
On Fri, Aug 30, 2024 at 08:03:25AM GMT, Dave Hansen wrote:
> On 8/29/24 01:42, Lorenzo Stoakes wrote:
> >> These applications work on x86 because x86 does an implicit 47-bit
> >> restriction of mmap() address that contain a hint address that is less
> >> than 48 bits.
> > You mean x86 _has_ to limi
Jakub Kicinski wrote:
> On Wed, 28 Aug 2024 15:33:33 -0400 Willem de Bruijn wrote:
> > That could work.
> >
> > Is reporting one KTAP and exitcode per directory vs per packetdrill
> > invocation good/bad/neither?
>
> To me "neither", hopefully and unhelpfully I won't tell you anything
> that's no
On 8/29/24 01:42, Lorenzo Stoakes wrote:
>> These applications work on x86 because x86 does an implicit 47-bit
>> restriction of mmap() address that contain a hint address that is less
>> than 48 bits.
> You mean x86 _has_ to limit to physically available bits in a canonical
> format 🙂 this will no
From: Joshua Hahn
Creates a cgroup with a single nice CPU hog process running.
fork() is called to generate the nice process because un-nicing is
not possible (see man nice(3)). If fork() was not used to generate
the CPU hog, we would run the rest of the cgroup selftest suite as a
nice process.
-
From: Joshua Hahn
Cgroup-level CPU statistics currently include time spent on
user/system processes, but do not include niced CPU time (despite
already being tracked). This patch exposes niced CPU time to the
userspace, allowing users to get a better understanding of their
hardware limits and can
From: Joshua Hahn
v1 -> v2: Edited commit messages for clarity.
Niced CPU usage is a metric reported in host-level /prot/stat, but is
not reported in cgroup-level statistics in cpu.stat. However, when a
host contains multiple tasks across different workloads, it becomes
difficult to gauge how mu
lone_test_x86
endif
TEST_GEN_PROGS += vdso_test_correctness
-ifeq ($(uname_M),x86_64)
+ifeq ($(ARCH),$(filter $(ARCH),x86_64))
TEST_GEN_PROGS += vdso_test_getrandom
TEST_GEN_PROGS += vdso_test_chacha
endif
---
base-commit: 985bf40edf4343dcb04c33f58b40b4a85c1776d4
change-id: 20240830-vdso-chacha-build-8d3789
On 8/30/24 06:41, Jason A. Donenfeld wrote:
Hi Shuah,
No 0/5 patch, so replying to the first one.
These are fixes to the vDSO selftests that Christophe is ostensibly
providing as a preamble to his work porting vgetrandom to PPC. Do you
mind if I take these via my random tree so his PPC vgetrand
On 8/29/24 23:29, Dev Jain wrote:
A "%s" is missing in ksft_exit_fail_msg(); instead, use the newly
introduced ksft_exit_fail_perror().
Signed-off-by: Dev Jain
---
tools/testing/selftests/arm64/abi/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing
On Thu, Aug 29, 2024 at 09:43:51PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add sealing test to cover mmap for
> Expand/shrink across vmas.
> Reuse the same address in !MAP_FIXED case.
>
> Signed-off-by: Jeff Xu
> ---
> tools/testing/selftests/mm/mseal_test.c | 125 +
On Thu, Aug 29, 2024 at 09:43:50PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add a testcase to cover all sealed madvise type.
>
> Signed-off-by: Jeff Xu
> ---
> tools/testing/selftests/mm/mseal_test.c | 108 +++-
> 1 file changed, 107 insertions(+), 1 deletion(-)
On Thu, Aug 29, 2024 at 09:43:49PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> Add check for vma size, prot bits and error return.
>
> Signed-off-by: Jeff Xu
> ---
> tools/testing/selftests/mm/mseal_test.c | 398
> 1 file changed, 332 insertions(+), 66 deletion
Hi Shuah,
No 0/5 patch, so replying to the first one.
These are fixes to the vDSO selftests that Christophe is ostensibly
providing as a preamble to his work porting vgetrandom to PPC. Do you
mind if I take these via my random tree so his PPC vgetrandom code can
go on top of it?
Jason
On 8/27/24 21:40, Rong Tao wrote:
From: Rong Tao
Add test scripts and prompts.
Can you give more details on what these scripts and prompts do?
Signed-off-by: Rong Tao
---
tools/testing/selftests/splice/splice_read.c | 1 +
tools/testing/selftests/splice/splice_read.sh | 9 +
On Thu, Aug 29, 2024 at 09:43:48PM GMT, jef...@chromium.org wrote:
> From: Jeff Xu
>
> This series increase the test coverage of mseal_test by:
>
> Add check for vma_size, prot, and error code for existing tests.
> Add more testcases for madvise, munmap, mmap and mremap to cover
> sealing in dif
Don't duplicate parse_vdso function prototypes, include
the header instead.
Fixes: 693f5ca08ca0 ("kselftest: Extend vDSO selftest")
Signed-off-by: Christophe Leroy
---
tools/testing/selftests/vDSO/vdso_test_abi.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/tools/testi
vdso_test_correctness test fails on powerpc:
~ # ./vdso_test_correctness
...
[RUN] Testing clock_gettime for clock CLOCK_REALTIME_ALARM (8)...
[FAIL] No such clock, but __vdso_clock_gettime returned 22
[RUN] Testing clock_gettime for clock CLOCK_BOOTTIME_ALARM (9)...
[FAIL] No such clock, bu
On powerpc64, following tests fail locating vDSO functions:
~ # ./vdso_test_abi
TAP version 13
1..16
# [vDSO kselftest] VDSO_VERSION: LINUX_2.6.15
# Couldn't find __kernel_gettimeofday
ok 1 # SKIP __kernel_gettimeofday
# clock_id: CLOCK_REALTIME
# Couldn't find __kernel_clock_getti
1 - 100 of 131 matches
Mail list logo
