On Wed, May 7, 2025 at 2:14 AM Lorenz Bauer wrote:
>
> On Tue, May 6, 2025 at 10:39 PM Andrii Nakryiko
> wrote:
>
> > > + raw_data = mmap(NULL, end, PROT_READ, MAP_PRIVATE, fd, 0);
> > > + if (!ASSERT_NEQ(raw_data, MAP_FAILED, "mmap_btf"))
> >
> > ASSERT_OK_PTR()?
>
> Don't think that
gt; >> "SOCK_SEQPACKET ioctl(SIOCOUTQ) 0 unsent bytes"
> >> output: "Unexpected 'SIOCOUTQ' value, expected 0, got 64 (CLIENT)".
> >>
> >> They test that the SIOCOUTQ ioctl reports 0 unsent bytes after the data
> >> have bee
expected 0, got 64 (CLIENT)".
They test that the SIOCOUTQ ioctl reports 0 unsent bytes after the data
have been received by the other side. However, sometimes there is a delay
in updating this "unsent bytes" counter, and the test fails even though
the counter properly goes to 0 se
On Wed, 7 May 2025 at 17:15, Konstantin Shkolnyy wrote:
>
> These tests:
> "SOCK_STREAM ioctl(SIOCOUTQ) 0 unsent bytes"
> "SOCK_SEQPACKET ioctl(SIOCOUTQ) 0 unsent bytes"
> output: "Unexpected 'SIOCOUTQ' value, expected 0, got 64 (CLIENT)
These tests:
"SOCK_STREAM ioctl(SIOCOUTQ) 0 unsent bytes"
"SOCK_SEQPACKET ioctl(SIOCOUTQ) 0 unsent bytes"
output: "Unexpected 'SIOCOUTQ' value, expected 0, got 64 (CLIENT)".
They test that the SIOCOUTQ ioctl reports 0 unsent bytes after the d
On Wed, May 07, 2025 at 06:48:33AM -0500, Konstantin Shkolnyy wrote:
These tests:
"SOCK_STREAM ioctl(SIOCOUTQ) 0 unsent bytes"
"SOCK_SEQPACKET ioctl(SIOCOUTQ) 0 unsent bytes"
output: "Unexpected 'SIOCOUTQ' value, expected 0, got 64 (CLIENT)".
The
These tests:
"SOCK_STREAM ioctl(SIOCOUTQ) 0 unsent bytes"
"SOCK_SEQPACKET ioctl(SIOCOUTQ) 0 unsent bytes"
output: "Unexpected 'SIOCOUTQ' value, expected 0, got 64 (CLIENT)".
They test that the SIOCOUTQ ioctl reports 0 unsent bytes after the d
On Tue, May 6, 2025 at 10:39 PM Andrii Nakryiko
wrote:
> > + raw_data = mmap(NULL, end, PROT_READ, MAP_PRIVATE, fd, 0);
> > + if (!ASSERT_NEQ(raw_data, MAP_FAILED, "mmap_btf"))
>
> ASSERT_OK_PTR()?
Don't think that mmap follows libbpf_get_error conventions? I'd keep
it as it is.
> >
with SO_LINGER: instead of blocking until all queued
> >>> messages for the socket have been successfully sent (or the linger timeout
> >>> has been reached), close() would block until packets were handled by the
> >>> peer.
> >>
> >> This is a
the socket have been successfully sent (or the linger timeout
>>> has been reached), close() would block until packets were handled by the
>>> peer.
>>
>> This is a new behaviour that only new kernels will follow, so I think
>> it is better to add a new
On Mon, May 5, 2025 at 11:39 AM Lorenz Bauer wrote:
>
> Add a basic test for the ability to mmap /sys/kernel/btf/vmlinux. Since
> libbpf doesn't have an API to parse BTF from memory we do some basic
> sanity checks ourselves.
>
> Signed-off-by: Lorenz Bauer
> ---
>
Quoting Richard Fitzgerald (2025-03-27 05:52:14)
> Add a forward-declare of struct of_phandle_args to prevent the compiler
> warning:
>
> ../include/kunit/clk.h:29:63: warning: ‘struct of_phandle_args’ declared
> inside parameter list will not be visible outside of this definition or
> declaration
gt; >has been reached), close() would block until packets were handled by the
> >peer.
>
> This is a new behaviour that only new kernels will follow, so I think
> it is better to add a new test instead of extending a pre-existing test
> that we described as "SOCK_STREAM SO_
is a new behaviour that only new kernels will follow, so I think
it is better to add a new test instead of extending a pre-existing test
that we described as "SOCK_STREAM SO_LINGER null-ptr-deref".
The old test should continue to check the null-ptr-deref also for old
kernels, while th
On Thu, 17 Apr 2025 00:32:49 +0100, Mark Brown wrote:
> This test program, originally written by Mark Rutland and lightly modified
> by me for upstream, verifies that we do not have the issues with host SVE
> state being discarded which were fixed in
>
>fbc7e61195
On Tue, 6 May 2025 at 03:34, Boqun Feng wrote:
>
> On Mon, May 05, 2025 at 02:02:09PM +0800, David Gow wrote:
> > On Sat, 3 May 2025 at 05:51, Miguel Ojeda wrote:
> > >
> > > Currently, return values of KUnit `#[test]` functions are ignored.
> > >
>
From: Rae Moar
[ Upstream commit 1d4c06d51963f89f67c7b75d5c0c34e9d1bb2ae6 ]
A bug was identified where the KTAP below caused an infinite loop:
TAP version 13
ok 4 test_case
1..4
The infinite loop was caused by the parser not parsing a test plan
if following a test result line.
Fix this
On Mon, May 05, 2025 at 02:02:09PM +0800, David Gow wrote:
> On Sat, 3 May 2025 at 05:51, Miguel Ojeda wrote:
> >
> > Currently, return values of KUnit `#[test]` functions are ignored.
> >
> > Thus introduce support for `-> Result` functions by checking their
>
Add a basic test for the ability to mmap /sys/kernel/btf/vmlinux. Since
libbpf doesn't have an API to parse BTF from memory we do some basic
sanity checks ourselves.
Signed-off-by: Lorenz Bauer
---
tools/testing/selftests/bpf/prog_tests/btf_sysfs.c | 83 ++
1 file ch
On Mon, May 5, 2025 at 6:57 PM Danilo Krummrich wrote:
>
> With that, do we still expose `alloc` primitives to userspace tests?
I considered removing a bunch of stuff (even the build support for
non-`macros` `rusttest`, to be honest) -- you are referring to the
`any(test, testlib)` bits,
On Fri, May 02, 2025 at 11:51:25PM +0200, Miguel Ojeda wrote:
> Improvements that build on top of the very basic `#[test]` support merged in
> v6.15.
>
> They are fairly minimal changes, but they allow us to map `assert*!`s back to
> KUnit, plus to add support for test functi
To get rid of setjmp()/longjmp(), the variant and self need to be usable
from __bail().
Make them available from the test metadata.
Signed-off-by: Thomas Weißschuh
---
tools/testing/selftests/kselftest_harness.h | 4
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests
To get rid of setjmp()/longjmp(), the teardown logic needs to be usable
from __bail(). To access the atomic teardown conditional from there,
move it into the test metadata.
This also allows the removal of "setup_completed".
Signed-off-by: Thomas Weißschuh
Acked-by: Shuah Khan
---
too
object->teardown_fn =
&wrapper_##fixture_name##_##test_name##_teardown; \
object->termsig = signal; \
object->timeout = tmout; \
_##fixture_name##_##test_name##_object = object; \
@@ -912,6 +917,8 @@ struct __test_metadata
timeout;/* seconds to wait for test timeout */
- bool timed_out; /* did this test timeout instead of exiting? */
bool aborted; /* stopped test due to failed ASSERT */
bool setup_completed; /* did setup finish? */
jmp_buf env;/* for exiting out of test early
gt; > undefined!
> > >
> > > Reported-by: Stephen Rothwell
> > > Closes:
> > > https://lore.kernel.org/linux-next/20250429155404.2b6fe...@canb.auug.org.au/
> > > Reported-by: kernel test robot
> > > Closes:
> > > https://lore.ke
implemented on architecture
The SKIP line should start with "ok 1" as the plan only contains one test.
Fixes: 3b5992eaf730 ("selftests: vDSO: unconditionally build chacha test")
Reviewed-by: Muhammad Usama Anjum
Signed-off-by: Thomas Weißschuh
---
I'm not sure if thi
`.unwrap()`s etc. everywhere.
>
> Having said that, C KUnit uses the macros for things that require
> stopping the test, even if "unrelated" to the actual test, and it does
> not look like normal code, of course. They do have `->init()` which
> can return a failure,
On Mon, 5 May 2025 at 02:00, Miguel Ojeda
wrote:
>
> On Sun, May 4, 2025 at 7:34 PM Tamir Duberstein wrote:
> >
> > Why not restrict this to Result<(), E>?
>
> I guess it is an option -- not sure if there may be a use case.
>
> > Is it possible to include the error in the output?
>
> I thought ab
On Sat, 3 May 2025 at 05:52, Miguel Ojeda wrote:
>
> There was no documentation yet on the KUnit-based `#[test]`s.
>
> Thus add it now.
>
> It includes an explanation about the `assert*!` macros being mapped to
> KUnit and the support for `-> Result` introduced in these s
On Sat, 3 May 2025 at 05:52, Miguel Ojeda wrote:
>
> Now that `rusttest`s are not really used much, clarify the section of
> the documentation that describes them.
>
> In addition, free the section name for the KUnit-based `#[test]`s that
> will be added afterwards. To do so,
> -
> macro_rules! format {
> ($($f:tt)*) => ({
> -&*String::from_fmt(kernel::fmt!($($f)*))
> +CString::try_from_fmt(kernel::fmt!($($f)*))?.to_str()?
> })
> }
>
> @@ -613,66 +597,72 @@ macro_rules! format {
>
On Sat, 3 May 2025 at 05:51, Miguel Ojeda wrote:
>
> Currently, return values of KUnit `#[test]` functions are ignored.
>
> Thus introduce support for `-> Result` functions by checking their
> returned values.
>
> At the same time, require that test functions return `(
On Sat, 3 May 2025 at 05:51, Miguel Ojeda wrote:
>
> The KUnit `#[test]` support that landed recently is very basic and does
> not map the `assert*!` macros into KUnit like the doctests do, so they
> panic at the moment.
>
> Thus implement the custom mapping in a similar way to
de, instead of, say, `.unwrap()`ing or `assert!`ing everywhere.
So easier to read, easier to copy-paste from normal code, and people
(especially those learning) wouldn't get accustomed to seeing
`.unwrap()`s etc. everywhere.
Having said that, C KUnit uses the macros for things that require
st
> the error occurred is no longer contained in the test output. I'm 👎
> > on this change for that reason.
>
> We could perhaps customize `?` to help here, e.g. printing a trace or
> panic, with the `Try` trait or similar.
>
> Related to this: I thought about saying in t
On Sun, May 4, 2025 at 7:30 PM Tamir Duberstein wrote:
>
> Alice pointed this out in another thread but: one of the downsides of
> returning Result is that in the event of failure the line number where
> the error occurred is no longer contained in the test output. I'm 👎
>
On Sun, May 4, 2025 at 7:34 PM Tamir Duberstein wrote:
>
> Why not restrict this to Result<(), E>?
I guess it is an option -- not sure if there may be a use case.
> Is it possible to include the error in the output?
I thought about giving some more context somehow and perhaps printing
it "manua
On Fri, May 2, 2025 at 5:53 PM Miguel Ojeda wrote:
>
> The KUnit `#[test]` support that landed recently is very basic and does
> not map the `assert*!` macros into KUnit like the doctests do, so they
> panic at the moment.
>
> Thus implement the custom mapping in a simil
On Fri, May 2, 2025 at 5:53 PM Miguel Ojeda wrote:
>
> Currently, return values of KUnit `#[test]` functions are ignored.
>
> Thus introduce support for `-> Result` functions by checking their
> returned values.
>
> At the same time, require that test functions return `(
.
>
> We keep the actual assertions we want to make as explicit ones with
> `assert*!`s.
>
> Signed-off-by: Miguel Ojeda
Alice pointed this out in another thread but: one of the downsides of
returning Result is that in the event of failure the line number where
the error occurred is
Now that `rusttest`s are not really used much, clarify the section of
the documentation that describes them.
In addition, free the section name for the KUnit-based `#[test]`s that
will be added afterwards. To do so, rename the section into `rusttest`
host tests.
Signed-off-by: Miguel Ojeda
There was no documentation yet on the KUnit-based `#[test]`s.
Thus add it now.
It includes an explanation about the `assert*!` macros being mapped to
KUnit and the support for `-> Result` introduced in these series.
Signed-off-by: Miguel Ojeda
---
Documentation/rust/testing.rst |
m_fmt(kernel::fmt!($($f)*))?.to_str()?
})
}
@@ -613,66 +597,72 @@ macro_rules! format {
\\xf0\\xf1\\xf2\\xf3\\xf4\\xf5\\xf6\\xf7\\xf8\\xf9\\xfa\\xfb\\xfc\\xfd\\xfe\\xff";
#[test]
-fn test_cstr_to_str() {
+fn test_cstr_to_str() -> Result {
let good_bytes = b&quo
Currently, return values of KUnit `#[test]` functions are ignored.
Thus introduce support for `-> Result` functions by checking their
returned values.
At the same time, require that test functions return `()` or `Result`, which should avoid mistakes, especially with non-`#[must_use]`
ty
The KUnit `#[test]` support that landed recently is very basic and does
not map the `assert*!` macros into KUnit like the doctests do, so they
panic at the moment.
Thus implement the custom mapping in a similar way to doctests, reusing
the infrastructure there.
In Rust 1.88.0, the `file
Improvements that build on top of the very basic `#[test]` support merged in
v6.15.
They are fairly minimal changes, but they allow us to map `assert*!`s back to
KUnit, plus to add support for test functions that return `Result`s.
In essence, they get our `#[test]`s essentially on par with the
ether memory_recursiveprot is enabled or not.
>
> The test_memcontrol selftest consistently fails its test_memcg_low
> sub-test (with memory_recursiveprot enabled) and sporadically fails
> its test_memcg_min sub-test. This patchset fixes the test_memcg_min
> and test_memcg_low failures by
alid when skipping:
>
> TAP version 13
> 1..1
> ok 2 # SKIP Not implemented on architecture
>
> The SKIP line should start with "ok 1" as the plan only contains one test.
>
> Fixes: 3b5992eaf730 ("selftests: vDSO: unconditionally build cha
implemented on architecture
The SKIP line should start with "ok 1" as the plan only contains one test.
Fixes: 3b5992eaf730 ("selftests: vDSO: unconditionally build chacha test")
Signed-off-by: Thomas Weißschuh
---
I'm not sure if this is not a general bug in ksft_exit_sk
Add a basic test for the ability to mmap /sys/kernel/btf/vmlinux. Since
libbpf doesn't have an API to parse BTF from memory we do some basic
sanity checks ourselves.
Signed-off-by: Lorenz Bauer
---
tools/testing/selftests/bpf/prog_tests/btf_sysfs.c | 82 ++
1 file ch
memory_recursiveprot
mount option which is enabled by default in systemd cgroup v2 setting.
So adopt Michal's suggestion to adjust the low event checking
according to whether memory_recursiveprot is enabled or not.
The test_memcontrol selftest consistently fails its test_memcg_low
sub-test
We use the refactored uffd_global_test_opts instead of global variables
for uffd-wp-mremap tests.
Signed-off-by: Ujwal Kundur
---
tools/testing/selftests/mm/uffd-wp-mremap.c | 23 +
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/tools/testing/selftests/mm/uffd
function initializes the global variables. TODO: remove global
- * vars and then remove this.
- */
-static int
-uffd_setup_environment(uffd_test_args_t *args, uffd_test_case_t *test,
- mem_type_t *mem_type, const char **errmsg)
-{
- map_shared = mem_type->sha
gt;nr_pages_per_cpu;
+ end_nr = (cpu+1) * gopts->nr_pages_per_cpu;
mid_nr = (start_nr + end_nr) / 2;
/* Copy the first half of the pages */
for (page_nr = start_nr; page_nr < mid_nr; page_nr++)
- copy_page_retry(uffd, page_nr * page_size);
+
Add a basic test for the ability to mmap /sys/kernel/btf/vmlinux. Since
libbpf doesn't have an API to parse BTF from memory we do some basic
sanity checks ourselves.
Signed-off-by: Lorenz Bauer
---
tools/testing/selftests/bpf/prog_tests/btf_sysfs.c | 79 ++
1 file ch
There was an issue with SO_LINGER: instead of blocking until all queued
messages for the socket have been successfully sent (or the linger timeout
has been reached), close() would block until packets were handled by the
peer.
Add a check to alert on close() lingering when it should not.
Signed-of
This is based on the gadget from the description of commit 9183671af6db
("bpf: Fix leakage under speculation on mispredicted branches").
Signed-off-by: Luis Gerhorst
---
.../selftests/bpf/progs/verifier_unpriv.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/tools/t
On Sun, 27 Apr 2025 09:40:58 +, Neill Kapron wrote:
> The inconsistencies in the systcall ABI between arm and arm-compat can
> can cause a failure in the syscall_restart test due to the logic
> attempting to work around the differences. The 'machine' field for an
> A
There was an issue with SO_LINGER: instead of blocking until all queued
messages for the socket have been successfully sent (or the linger timeout
has been reached), close() would block until packets were handled by the
peer.
Add a check to alert on close() lingering when it should not.
Signed-of
On Tue, Apr 29, 2025 at 04:27:27PM +0100, Mark Rutland wrote:
> On Thu, Apr 17, 2025 at 12:32:49AM +0100, Mark Brown wrote:
> > Signed-off-by: Mark Brown
> Looks like my Signed-off-by got dropped by accident; it should be above
> yours here.
> Aside from that, and the in
On Thu, Apr 17, 2025 at 12:32:49AM +0100, Mark Brown wrote:
> This test program, originally written by Mark Rutland and lightly modified
> by me for upstream,
For context, I had originally pushed this as a WIP to:
https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/commit/?h
The inconsistencies in the systcall ABI between arm and arm-compat can
can cause a failure in the syscall_restart test due to the logic
attempting to work around the differences. The 'machine' field for an
ARM64 device running in compat mode can report 'armv8l' or 'armv8
From: Neill Kapron
The inconsistencies in the systcall ABI between arm and arm-compat can
can cause a failure in the syscall_restart test due to the logic
attempting to work around the differences. The 'machine' field for an
ARM64 device running in compat mode can report 'arm
Some common KVM test cases are supported on LoongArch now as following:
coalesced_io_test
demand_paging_test
dirty_log_perf_test
dirty_log_test
guest_print_test
hardware_disable_test
kvm_binary_stats_test
kvm_create_max_vcpus
kvm_page_table_test
memslot_modification_stress_test
Add ucall test support for LoongArch, ucall method on LoongArch uses
undefined mmio area. It will cause vCPU exiting to hypervisor so that
hypervisor can communicate with vCPU.
Signed-off-by: Bibo Mao
---
.../selftests/kvm/include/loongarch/ucall.h | 20 ++
.../selftests/kvm/lib
Add a forwarding path test for tc-taprio, based on isochron. This is
specifically intended for NICs with an offloaded data path (switchdev/DSA)
and requires taprio 'flags 2'. Also, $h1 and $h2 must support hardware
timestamping, and $h1 tc-etf offload, for isochron to work.
Packets rec
itchdev) data path when
> the bridge says that ports should have no PVID VLAN, but the 8021q
> module, as the result of a NETDEV_UP event, decides it should add VID 0
> to the RX filter of those bridge ports. Do those bridge ports receive
> packets tagged with VID 0 or not, now? We don't
The selftest can reproduce an issue where we miss the uncharge operation
when freeing msg, which will cause the following warning. We fixed the
issue and added this reproducer to selftest to ensure it will not happen
again.
[ cut here ]
WARNING: CPU: 1 PID: 40 at net/ipv4/a
8021q
module, as the result of a NETDEV_UP event, decides it should add VID 0
to the RX filter of those bridge ports. Do those bridge ports receive
packets tagged with VID 0 or not, now? We don't know, there is no test.
In the veth realm, this passes trivially, because veth is not VLAN
filt
Test that the SO_INCOMING_NAPI_ID of a network file descriptor is
non-zero. This ensures that either the core networking stack or, in some
cases like netdevsim, the driver correctly sets the NAPI ID.
Signed-off-by: Joe Damato
---
.../testing/selftests/drivers/net/.gitignore | 1 +
tools
On Wed, 23 Apr 2025 17:06:05 -0700 Joe Damato wrote:
> # Exception| Traceback (most recent call last):
> # Exception| File
> "/home/jdamato/code/net-next/tools/testing/selftests/net/lib/py/ksft.py",
> line 223, in ksft_run
> # Exception| case(*args)
> # Exception| File
> "/home/jdamato/c
removing the ksft_wait() from the binary work? Or does it
> cause trouble? Don't think we need to wait for anything in this case.
> With the XSK test we had to wait for the test to do the inspection
> before we unbound. Here once we get the connection we can just exit, no?
I agree that
e how I misread v2 but you are running the helper locally.
So you don't have to deploy it to the remote machine :(
BTW does removing the ksft_wait() from the binary work? Or does it
cause trouble? Don't think we need to wait for anything in this case.
With the XSK test we had to wait
Adding verifier test for accessing const void pointer argument in
tracing programs.
The test program loads 1st argument of bpf_fentry_test10 function
which is const void pointer and checks that verifier allows that.
Signed-off-by: KaFai Wan
Acked-by: Jiri Olsa
---
net/bpf/test_run.c
Hi Mark,
Thanks for your patch!
On Tue, 22 Apr 2025 at 17:43, Mark Brown wrote:
> When the select of PRIME_MUMBERS was removed from it's KUnit test
> Kconfig nothing was added to the KUnit configs, meaning that when run
> via the KUnit runner the tests are neither built
Add a testcase to exercise KVM_CAP_X86_VMWARE_HYPERCALL and validate
that KVM exits to userspace on hypercalls and registers are correctly
preserved.
Signed-off-by: Zack Rusin
Cc: Doug Covelli
Cc: Paolo Bonzini
Cc: Shuah Khan
Cc: Sean Christopherson
Cc: Namhyung Kim
Cc: Joel Stanley
Cc: Zac
On Tue, 22 Apr 2025 16:43:29 +0100, Mark Brown wrote:
> When the select of PRIME_MUMBERS was removed from it's KUnit test
> Kconfig nothing was added to the KUnit configs, meaning that when run
> via the KUnit runner the tests are neither built nor run. Add
> PRIME_NUMBERS to al
When the select of PRIME_MUMBERS was removed from it's KUnit test
Kconfig nothing was added to the KUnit configs, meaning that when run
via the KUnit runner the tests are neither built nor run. Add
PRIME_NUMBERS to all_tests.config so they are enabled when the KUnit
runner builds the k
There was an issue with SO_LINGER: instead of blocking until all queued
messages for the socket have been successfully sent (or the linger timeout
has been reached), close() would block until packets were handled by the
peer.
Add a check to alert on close() lingering when it should not.
Signed-of
This is based on the gadget from the description of commit 9183671af6db
("bpf: Fix leakage under speculation on mispredicted branches").
Signed-off-by: Luis Gerhorst
---
.../selftests/bpf/progs/verifier_unpriv.c | 57 +++
1 file changed, 57 insertions(+)
diff --git a/tools/t
Some common KVM test cases are supported on LoongArch now as following:
coalesced_io_test
demand_paging_test
dirty_log_perf_test
dirty_log_test
guest_print_test
hardware_disable_test
kvm_binary_stats_test
kvm_create_max_vcpus
kvm_page_table_test
memslot_modification_stress_test
Add ucall test support for LoongArch, ucall method on LoongArch uses
undefined mmio area. It will cause vCPU exits to hypervisor so that
hypervisor can communicate with vCPU.
Signed-off-by: Bibo Mao
---
.../selftests/kvm/include/loongarch/ucall.h | 20 ++
.../selftests/kvm/lib
On Fri, Apr 18, 2025 at 12:56 PM Lorenzo Stoakes
wrote:
>
> On Fri, Apr 18, 2025 at 12:31:29PM -0700, Suren Baghdasaryan wrote:
> > On Fri, Apr 18, 2025 at 11:30 AM Lorenzo Stoakes
> > wrote:
> > >
> > > On Fri, Apr 18, 2025 at 10:49:54AM -0700, Suren Baghdas
On Fri, Apr 18, 2025 at 12:31:29PM -0700, Suren Baghdasaryan wrote:
> On Fri, Apr 18, 2025 at 11:30 AM Lorenzo Stoakes
> wrote:
> >
> > On Fri, Apr 18, 2025 at 10:49:54AM -0700, Suren Baghdasaryan wrote:
> > > Test that /proc/pid/maps does not report unexpected holes
On Fri, Apr 18, 2025 at 11:30 AM Lorenzo Stoakes
wrote:
>
> On Fri, Apr 18, 2025 at 10:49:54AM -0700, Suren Baghdasaryan wrote:
> > Test that /proc/pid/maps does not report unexpected holes in the address
> > space when we concurrently remap a part of a vma into the middle
On Fri, Apr 18, 2025 at 10:49:54AM -0700, Suren Baghdasaryan wrote:
> Test that /proc/pid/maps does not report unexpected holes in the address
> space when we concurrently remap a part of a vma into the middle of
> another vma. This remapping results in the destination vma being split
>
Extend /proc/pid/maps tearing test to verify PROCMAP_QUERY ioctl operation
correctness while the vma is being concurrently modified.
Signed-off-by: Suren Baghdasaryan
---
tools/testing/selftests/proc/proc-pid-vm.c | 60 ++
1 file changed, 60 insertions(+)
diff --git a/tools
Test that /proc/pid/maps does not report unexpected holes in the address
space when we concurrently remap a part of a vma into the middle of
another vma. This remapping results in the destination vma being split
into three parts and the part in the middle being patched back from,
all done
Test that /proc/pid/maps does not report unexpected holes in the address
space when a vma at the edge of the page is being concurrently remapped.
This remapping results in the vma shrinking and expanding from under the
reader. We should always see either shrunk or expanded (original) version
of
as a result of a vma being
replaced with another one, leaving the space temporarily empty.
Implement a test that reads /proc/pid/maps of a forked child process and
checks data consistency at the edge of two pages. Child process constantly
modifies its address space in a way that affects the vma lo
Test that the SO_INCOMING_NAPI_ID of a network file descriptor is
non-zero. This ensures that either the core networking stack or, in some
cases like netdevsim, the driver correctly sets the NAPI ID.
Signed-off-by: Joe Damato
---
.../testing/selftests/drivers/net/.gitignore | 1 +
tools
On Thu, 17 Apr 2025 01:32:42 + Joe Damato wrote:
> Test that the SO_INCOMING_NAPI_ID of a network file descriptor is
> non-zero. This ensures that either the core networking stack or, in some
> cases like netdevsim, the driver correctly sets the NAPI ID.
>
> Signed-off
Add link update test for cgroup_storage.
'./test_progs -a cgroup_storage_update'
test_cgroup_storage_update:PASS:create cgroup 0 nsec
setup_network:PASS:ip netns add cgroup_storage_ns 0 nsec
setup_network:PASS:open netns 0 nsec
setup_network:PASS:ip link set lo
From: Frederic Weisbecker
The numbers used in rcu_seq_done_exact() lack some explanation behind
their magic. Especially after the commit:
85aad7cc4178 ("rcu: Fix get_state_synchronize_rcu_full() GP-start
detection")
which reported a subtle issue where a new GP sequence snapshot was taken
o
Test that the SO_INCOMING_NAPI_ID of a network file descriptor is
non-zero. This ensures that either the core networking stack or, in some
cases like netdevsim, the driver correctly sets the NAPI ID.
Signed-off-by: Joe Damato
---
.../testing/selftests/drivers/net/.gitignore | 1 +
tools
character. The two are functionally
> equivalent.
OK thanks for the details. Sorry that I am learning Python via
netdev ;)
I did this so it matches the style of the other fstring a few lines
below:
-listen_cmd = f'{bin_remote} {cfg.addr_v['4']} {port}'
+listen_cmd =
On Thu, 17 Apr 2025 09:43:23 -0700 Joe Damato wrote:
> I think the main outstanding thing is Paolo's feedback which maybe
> (?) is due to a Python version difference? If you have any guidance
> on how to proceed on that, I'd appreciate it [1].
yes, it's a Python version, I made the same mistake in
On Thu, Apr 17, 2025 at 06:46:15AM -0700, Jakub Kicinski wrote:
> On Thu, 17 Apr 2025 01:32:42 + Joe Damato wrote:
> > Test that the SO_INCOMING_NAPI_ID of a network file descriptor is
> > non-zero. This ensures that either the core networking stack or, in some
> > case
On Thu, Apr 17, 2025 at 03:45:29PM +0300, Ilpo Järvinen wrote:
> The commit df6f8c4d72ae ("selftests/pcie_bwctrl: Add
> 'set_pcie_speed.sh' to TEST_PROGS") added set_pcie_speed.sh into
> TEST_PROGS but that script is a helper that is only being called by
> set_p
1 - 100 of 4927 matches
Mail list logo
