On 3/25/24 18:09, Maíra Canal wrote:
On 3/25/24 16:24, Guenter Roeck wrote:
Hi,
On Mon, Mar 25, 2024 at 04:05:06PM -0300, Maíra Canal wrote:
Hi Guenter,
On 3/25/24 14:52, Guenter Roeck wrote:
The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
intentionally trigger
Add the invalid filter test which sets the filter beyond the event
space and sets the invalid action to double check if the
KVM_ARM_VCPU_PMU_V3_FILTER will return the expected error.
Reviewed-by: Eric Auger
Signed-off-by: Shaoqin Huang
---
.../kvm/aarch64/pmu_event_filter_test.c | 38
Introduce pmu_event_filter_test for arm64 platforms. The test configures
PMUv3 for a vCPU, and sets different pmu event filters for the vCPU, and
check if the guest can see those events which user allow and can't use
those events which use deny.
This test refactor the create_vpmu_vm() and make it
Create a vcpu with vpmu would be a common requirement for the vpmu test,
so add the helper function for the vpmu vcpu creation. And use those
helper function in the vpmu_counter_access.c test.
Use this chance to delete the meaningless ASSERT about the pmuver,
because KVM does not advertise an
The test is inspired by the pmu_event_filter_test which implemented by x86. On
the arm64 platform, there is the same ability to set the pmu_event_filter
through the KVM_ARM_VCPU_PMU_V3_FILTER attribute. So add the test for arm64.
The series first create the helper function which can be used
for
Hi Eric,
Thanks for your review.
On 3/20/24 04:58, Eric Auger wrote:
Hi Shaoqin,
On 2/29/24 07:56, Shaoqin Huang wrote:
Introduce pmu_event_filter_test for arm64 platforms. The test configures
PMUv3 for a vCPU, and sets different pmu event filters for the vCPU, and
check if the guest can see
On Mon, 25 Mar 2024 19:25:43 +0100 Richard Gobert wrote:
> + const u32 id = ntohl(*(__be32 *)>id);
> + const u32 id2 = ntohl(*(__be32 *)>id);
> + const int flush_id = ntohs(id >> 16) - ntohs(id2 >> 16);
The endian conversions don't match types here. sparse is unhappy.
If id is in host
On Mon, 25 Mar 2024 15:21:33 + Mark Brown wrote:
> Hi,
>
> Commit 28b3df1fe6ba2cb4 ("kunit: add wireless unit tests") which I can't
> seem to find on lore breaks full kunit runs on non-UML builds and is now
> present in mainline. If I run:
>
>./tools/testing/kunit/kunit.py run
On 3/25/24 16:24, Guenter Roeck wrote:
Hi,
On Mon, Mar 25, 2024 at 04:05:06PM -0300, Maíra Canal wrote:
Hi Guenter,
On 3/25/24 14:52, Guenter Roeck wrote:
The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
intentionally trigger warning backtraces by providing bad
On Mon, 25 Mar 2024 18:29:07 +0100 Petr Machata wrote:
> As discussed on the bi-weekly call on Jan 30, and in mailing around
> kernel CI effort, some changes are desirable in the suite of forwarding
> selftests the better to work with the CI tooling.
Excellent.
Did you skip CCing netdev@ on
On Mon, 25 Mar 2024 18:29:16 +0100 Petr Machata wrote:
> +set_ret()
> +{
> + local nret=$1; shift
May be worth throwing in a comment that $1 must be a legal ksft ret
code, not any exit code from random commands.
On Mon, 25 Mar 2024 18:29:10 +0100 Petr Machata wrote:
> +The forwarding selftests framework uses a number of variables that
> +influence its behavior and tools it invokes, and how it invokes them, in
> +various ways. A number of these variables can be overridden. The way these
> +overridable
On Tue, Mar 5, 2024 at 11:38 AM Mina Almasry wrote:
>
> On Tue, Mar 5, 2024 at 4:54 AM Yunsheng Lin wrote:
> >
> > On 2024/3/5 10:01, Mina Almasry wrote:
> >
> > ...
> >
> > >
> > > Perf - page-pool benchmark:
> > > ---
> > >
> > > bench_page_pool_simple.ko tests with and
Some unit tests intentionally trigger warning backtraces by passing
bad parameters to API functions. Such unit tests typically check the
return value from those calls, not the existence of the warning backtrace.
Such intentionally generated warning backtraces are neither desirable
nor useful for
Hi Guenter,
On 3/25/24 14:52, Guenter Roeck wrote:
The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
intentionally trigger warning backtraces by providing bad parameters to
the tested functions. What is tested is the return value, not the existence
of a warning backtrace.
On Mon, 2024-03-25 at 16:23 +, Mark Brown wrote:
> On Mon, Mar 25, 2024 at 05:16:35PM +0100, Johannes Berg wrote:
>
> > Anyway, does it fix it for you as well? if yes, where/how should we get
> > that in?
>
> Seems to. Given the breakage I'd expect it to go to Linus urgently, I
> don't know
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
kselftest/next kselftest-livepatch: 1 runs, 1 regressions (v6.9-rc1)
Regressions Summary
---
platform| arch | lab | compiler | defconfig
| regressions
kselftest/next build: 2 builds: 0 failed, 2 passed (v6.9-rc1)
Full Build Summary:
https://kernelci.org/build/kselftest/branch/next/kernel/v6.9-rc1/
Tree: kselftest
Branch: next
Git Describe: v6.9-rc1
Git Commit: 4cece764965020c22cff7665b18a012006359095
Git URL:
kselftest/fixes build: 2 builds: 0 failed, 2 passed, 1 warning (v6.9-rc1)
Full Build Summary:
https://kernelci.org/build/kselftest/branch/fixes/kernel/v6.9-rc1/
Tree: kselftest
Branch: fixes
Git Describe: v6.9-rc1
Git Commit: 4cece764965020c22cff7665b18a012006359095
Git URL:
On Mon, 25 Mar 2024 19:40:52 + Edward Liaw wrote:
> Following issue was observed while running the uffd-unit-tests selftest
> on ARM devices. On x86_64 no issues were detected:
>
> pthread_create followed by fork caused deadlock in certain cases
> wherein fork required some work to be
Following issue was observed while running the uffd-unit-tests selftest
on ARM devices. On x86_64 no issues were detected:
pthread_create followed by fork caused deadlock in certain cases
wherein fork required some work to be completed by the created thread.
Used synchronization to ensure that
Hi,
On Mon, Mar 25, 2024 at 04:05:06PM -0300, Maíra Canal wrote:
> Hi Guenter,
>
> On 3/25/24 14:52, Guenter Roeck wrote:
> > The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
> > intentionally trigger warning backtraces by providing bad parameters to
> > the tested
Richard Gobert wrote:
> {inet,ipv6}_gro_receive functions perform flush checks (ttl, flags,
> iph->id, ...) against all packets in a loop. These flush checks are used
> currently only in tcp flows in GRO.
>
> These checks need to be done only once in tcp_gro_receive and only against
> the found p
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
Add name of functions triggering warning backtraces to the __bug_table
object section to enable support for suppressing WARNING backtraces.
To limit image size impact, the pointer to the function name is only added
to the __bug_table section if both CONFIG_KUNIT_SUPPRESS_BACKTRACE and
dev_addr_lists_test generates lock warning noise at the end of tests
if lock debugging is enabled. There are two sets of warnings.
WARNING: CPU: 0 PID: 689 at kernel/locking/mutex.c:923
__mutex_unlock_slowpath.constprop.0+0x13c/0x368
DEBUG_LOCKS_WARN_ON(__owner_task(owner) != __get_current())
The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
intentionally trigger warning backtraces by providing bad parameters to
the tested functions. What is tested is the return value, not the existence
of a warning backtrace. Suppress the backtraces to avoid clogging the
kernel
Document API functions for suppressing warning backtraces.
Tested-by: Linux Kernel Functional Testing
Acked-by: Dan Carpenter
Reviewed-by: Kees Cook
Signed-off-by: Guenter Roeck
---
- Rebased to v6.9-rc1
- Added Tested-by:, Acked-by:, and Reviewed-by: tags
Add unit tests to verify that warning backtrace suppression works.
If backtrace suppression does _not_ work, the unit tests will likely
trigger unsuppressed backtraces, which should actually help to get
the affected architectures / platforms fixed.
Tested-by: Linux Kernel Functional Testing
Count suppressed warning backtraces to enable code which suppresses
warning backtraces to check if the expected backtrace(s) have been
observed.
Using atomics for the backtrace count resulted in build errors on some
architectures due to include file recursion, so use a plain integer
for now.
Some unit tests intentionally trigger warning backtraces by passing bad
parameters to kernel API functions. Such unit tests typically check the
return value from such calls, not the existence of the warning backtrace.
Such intentionally generated warning backtraces are neither desirable
nor
In a previous patch, the interpretation of RET value was changed to mean
the kselftest framework constant with the test outcome: $ksft_pass,
$ksft_xfail, etc.
Update log_test() to recognize the various possible RET values.
Then have EXIT_STATUS track the RET value of the current test. This
Rerunning various scenarios to make sure lib.sh changes do not impact the
observable behavior is no fun. Add a selftest at least for the bare basics
-- the mechanics of setting RET, retmsg, and EXIT_STATUS.
Since the selftest itself uses lib.sh, it would be possible to break lib.sh
in such a way
Several tests in the suite use large amounts of traffic to e.g. cause
congestion and evaluate RED or shaper performance. These tests will not run
well on a slow machine, be it one with heavy debug kernel, or a VM, or e.g.
a single-board computer. Allow users to specify an environment variable,
When the NH group stats tests are currently run on a veth topology, the
HW-stats leg of each test is SKIP'ped. But kernel networking CI interprets
skips as a sign that tooling is missing, and prompts maintainer
investigation. Lack of capability to pass a test should be expressed as
XFAIL.
When run on a slow machine, the scheduler traffic tests can be expected to
fail, and should be reported as XFAIL in that case. Therefore run these
tests through the perf_sensitive wrapper.
Signed-off-by: Petr Machata
---
.../selftests/net/forwarding/sch_ets_tests.sh | 19 +++
The tests in net/forwarding are generally expected to be HW-independent.
There are however several tests that, while not depending on any HW in
particular, nevertheless depend on being used on HW interfaces. Placing
these selftests to net/forwarding is confusing, because the selftest will
just
Since the selftests that are not supposed to run on veth pairs are now in
their own dedicated directory, the skip_on_veth logic can go away. Drop it
from the selftests, and from lib.sh.
Cc: Danielle Ratson
Signed-off-by: Petr Machata
---
.../testing/selftests/drivers/net/hw/ethtool.sh | 2 --
The SKIP return should be used for cases where tooling of the machine under
test is lacking. For cases where HW is lacking, the appropriate outcome is
XFAIL.
This is the case with ethtool_rmon and mlxsw_lib. For these, introduce a
new helper, log_test_xfail().
Do the same for
The variable RET keeps track of whether the test under execution has so far
failed or not. Currently it works in binary fashion: zero means everything
is fine, non-zero means something failed. log_test() then uses the value to
given a human-readable message.
In order to allow log_test() to report
The following patches will operate with more exit codes besides
ksft_skip. Add them here.
Additionally, move a duplicated skip exit code definition from
forwarding/tc_tunnel_key.sh. Keep a similar duplicate in
forwarding/devlink_lib.sh, because even though lib.sh will have
been sourced in all
This library is always sourced in the context where lib.sh has already been
sourced as well. Therefore drop the explicit sourcing and expect the client
to already have done it. This will simplify moving some of the clients to a
different directory.
Signed-off-by: Petr Machata
---
That any sort of customization is possible at all, let alone how it should
be done, is currently not at all clear. Document the whats and hows in
README.
Signed-off-by: Petr Machata
Reviewed-by: Benjamin Poirier
---
tools/testing/selftests/net/forwarding/README | 33 +++
1 file
As discussed on the bi-weekly call on Jan 30, and in mailing around
kernel CI effort, some changes are desirable in the suite of forwarding
selftests the better to work with the CI tooling. Namely:
- The forwarding selftests use a configuration file where names of
interfaces are defined and
The current syntax of X=${X:=X} first evaluates the ${X:=Y} expression,
which either uses the existing value of $X if there is one, or uses the
value of "Y" as a fallback, and assigns it to X. The expression is then
replaced with the now-current value of $X. Assigning that value to X once
more is
forwarding.config.sample, net/lib.sh and net/forwarding/lib.sh contain
definitions and redefinitions of some of the same variables. The overlap
between net/forwarding/lib.sh and forwarding.config.sample is especially
large. This duplication is a potential source of confusion and problems.
It
The seccomp benchmark runs five scenarios, one calibration run with no
seccomp filters enabled then four further runs each adding a filter. The
calibration run times itself for 15s and then each additional run executes
for the same number of times.
Currently the seccomp tests, including the
On Thu, Mar 7, 2024 at 1:49 PM Colin Ian King wrote:
>
> There are spelling mistakes in __GUEST_ASSERT messages. Fix them.
>
> Signed-off-by: Colin Ian King
Queued this patch for Linux-6.9 fixes.
Thanks,
Anup
> ---
> tools/testing/selftests/kvm/aarch64/arch_timer.c | 2 +-
>
On Mon, Mar 25, 2024 at 05:16:35PM +0100, Johannes Berg wrote:
> Anyway, does it fix it for you as well? if yes, where/how should we get
> that in?
Seems to. Given the breakage I'd expect it to go to Linus urgently, I
don't know that it super matters exactly how but I guess net will be
sending
In order to facilitate debugging of issues from automated runs of the ftrace
selftests turn on verbose logging by default when run from the kselftest
runner. This is primarily used by automated systems where developers may
not have direct access to the system so defaulting to providing diagnostic
When -v is specified ftracetest will dump logs of test execution to the
console which if -K is also specified for KTAP output will result in
output that is not properly KTAP formatted. All that's required for KTAP
formatting is that anything we log have a '#' at the start of the line so
we can
This series aims to improve the usability of the ftrace selftests when
running as part of the kselftest runner, mainly for use with automated
systems. It fixes the output of verbose mode when run in KTAP output
mode and then enables verbose mode by default when invoked from the
kselftest runner
On Mon, 2024-03-25 at 15:55 +, Mark Brown wrote:
> On Mon, Mar 25, 2024 at 04:29:53PM +0100, Johannes Berg wrote:
>
> > But I'm not sure why ARCH=um is different?
>
> It's probably something to do with it lacking a bunch of features of
> normal architectures, especially around hardware
On 3/22/24 16:31, Marcos Paulo de Souza wrote:
> On Thu, 2024-03-21 at 10:08 -0400, Joe Lawrence wrote:
>> On 3/12/24 08:12, Marcos Paulo de Souza wrote:
>>> This new test checks if a livepatch with replace attribute set
>>> replaces
>>> all previously applied livepatches.
>>>
>>> Signed-off-by:
Make sure that we don't return more bytes than we actually received if
the userspace buffer was bogus. We expect to receive at least the rest
of rec1, and possibly some of rec2 (currently, we don't, but that
would be ok).
Signed-off-by: Sabrina Dubroca
---
tools/testing/selftests/net/tls.c | 34
The longest running netdevsim test, nexthop.sh, currently takes
5 min to finish. Around 260s to be exact, and 310s on a debug kernel.
The default timeout in selftest is 45sec, so we need an explicit
config. Give ourselves some headroom and use 10min.
Commit under Fixes isn't really to "blame" but
On Mon, Mar 25, 2024 at 04:29:53PM +0100, Johannes Berg wrote:
> But I'm not sure why ARCH=um is different?
It's probably something to do with it lacking a bunch of features of
normal architectures, especially around hardware support.
signature.asc
Description: PGP signature
On Mon, 2024-03-25 at 15:21 +, Mark Brown wrote:
> Hi,
>
> Commit 28b3df1fe6ba2cb4 ("kunit: add wireless unit tests") which I can't
> seem to find on lore breaks full kunit runs on non-UML builds and is now
> present in mainline. If I run:
>
>./tools/testing/kunit/kunit.py run
Hi,
Commit 28b3df1fe6ba2cb4 ("kunit: add wireless unit tests") which I can't
seem to find on lore breaks full kunit runs on non-UML builds and is now
present in mainline. If I run:
./tools/testing/kunit/kunit.py run --alltests --cross_compile
x86_64-linux-gnu- --arch x86_64
on a clean tree
The test results reported for the clone3_set_tid tests interact poorly with
automation for running kselftest since the reported test names include TIDs
dynamically allocated at runtime. A lot of automation for running kselftest
will compare runs by looking at the test name to identify if the same
On Mon, Mar 25, 2024 at 12:17:28PM +, Joao Martins wrote:
> > However, I am not smart enough to figure out why ...
> >
> > Apparently, from the source, mmap() fails to allocate pages on the desired
> > address:
> >
> > 1746 assert((uintptr_t)self->buffer % HUGEPAGE_SIZE == 0);
> >
On Fri, 22 Mar 2024, Reinette Chatre wrote:
> On 3/22/2024 5:30 AM, Ilpo Järvinen wrote:
> > On Wed, 20 Mar 2024, Reinette Chatre wrote:
> >> On 3/11/2024 6:52 AM, Ilpo Järvinen wrote:
> >>> The struct resctrl_val_param has control and monitor groups as char
> >>> arrays but they are not supposed
On Fri, 22 Mar 2024, Reinette Chatre wrote:
> On 3/22/2024 5:11 AM, Ilpo Järvinen wrote:
> > On Tue, 19 Mar 2024, Reinette Chatre wrote:
> >> On 3/11/2024 6:52 AM, Ilpo Järvinen wrote:
> >>> + * Return: = 0 on success. < 0 on failure.
> >>> + */
> >>> +static int get_mem_bw_imc(char *bw_report,
On 23/03/2024 20:13, Mirsad Todorovac wrote:
>
>
> On 3/19/24 14:58, Jason Gunthorpe wrote:
>> On Tue, Mar 12, 2024 at 07:35:40AM +0100, Mirsad Todorovac wrote:
>>> Hi,
>>>
>>> (This is verified on the second test box.)
>>>
>>> In the most recent 6.8.0 release of torvalds tree kernel with
Soft reminder
On 3/7/24 11:37 PM, Muhammad Usama Anjum wrote:
> Conform the layout, informational and status messages to TAP. No
> functional change is intended other than the layout of output messages.
>
> Signed-off-by: Muhammad Usama Anjum
> ---
> tools/testing/selftests/x86/vdso_restorer.c
On 3/25/24 2:00 PM, Muhammad Usama Anjum wrote:
> Add FAULT_INJECTION_DEBUG_FS and FAILSLAB configurations which are
> needed by iommufd_fail_nth test.
>
> Signed-off-by: Muhammad Usama Anjum
> ---
> While building and running these tests on x86, defconfig had these
> configs enabled. But
On Mar 24 2024, Alexei Starovoitov wrote:
> On Sat, Mar 23, 2024 at 9:57 PM Kumar Kartikeya Dwivedi
> wrote:
>
> > > > >
> > > > > Observation is correct. The patch is buggy,
> > > > > but the suggestion to follow process_dynptr_func() will lead
> > > > > to unnecessary complexity.
> > > > >
Add FAULT_INJECTION_DEBUG_FS and FAILSLAB configurations which are
needed by iommufd_fail_nth test.
Signed-off-by: Muhammad Usama Anjum
---
While building and running these tests on x86, defconfig had these
configs enabled. But ARM64's defconfig doesn't enable these configs.
Hence the config
Soft Reminder
On 3/14/24 3:32 PM, Muhammad Usama Anjum wrote:
> Conform the layout, informational and status messages to TAP. No
> functional change is intended other than the layout of output messages.
> Without using TAP messages, the passed/failed/skip test names cannot be
> found.
>
>
Soft reminder
On 3/5/24 11:08 AM, Muhammad Usama Anjum wrote:
> Conform the layout, informational and status messages to TAP. No
> functional change is intended other than the layout of output messages.
>
> Reviewed-by: T.J. Mercier
> Signed-off-by: Muhammad Usama Anjum
> ---
> Changes since
Currently, VA exhaustion is being checked by passing a hint to mmap() and
expecting it to fail. This patch makes a stricter test by successful
write() calls from /proc/self/maps to a dump file, confirming that a
free chunk is indeed not available.
Changes in v2:
- Replace SZ_1GB with
On Fri, Mar 22, 2024 at 7:56 AM Benjamin Tissoires wrote:
>
> They are implemented as a workqueue, which means that there are no
> guarantees of timing nor ordering.
>
> Signed-off-by: Benjamin Tissoires
>
> ---
>
> no changes in v5
>
> changes in v4:
> - dropped __bpf_timer_compute_key()
> -
On Fri, Mar 22, 2024 at 10:40:26AM -0700, Mina Almasry wrote:
> Hi Christoph,
>
> Sorry for the late reply, I've been out for a few days.
>
> On Mon, Mar 18, 2024 at 4:22 PM Christoph Hellwig wrote:
> >
> > On Sun, Mar 17, 2024 at 07:49:43PM -0700, David Wei wrote:
> > > I'm working on a
On Fri, Mar 22, 2024 at 10:54:54AM -0700, Mina Almasry wrote:
> Sorry I don't mean to argue but as David mentioned, there are some
> plans in the works and ones not in the works to extend this to other
> memory types. David mentioned io_uring & Jakub's huge page use cases
> which may want to
On Fri, Mar 22, 2024 at 04:19:44PM -0700, Jakub Kicinski wrote:
> On Fri, 22 Mar 2024 10:40:26 -0700 Mina Almasry wrote:
> > Other designs for this hugepage use case are possible, I'm just
> > describing Jakub's idea for it as a potential use-case for these
> > hooks.
>
> I made it ops because I
81 matches
Mail list logo
