On Sat, 11 Mar 2023 at 07:34, Stephen Boyd <sboyd(a)kernel.org> wrote:
>
> Quoting David Gow (2023-03-10 00:09:48)
> > On Fri, 10 Mar 2023 at 07:19, Stephen Boyd <sboyd(a)kernel.org> wrote:
> > >
> > >
> > > Hmm. I think you're suggesting that the unit test data be loaded
> > > whenever CONFIG_OF=y and CONFIG_KUNIT=y. Then tests can check for
> > > CONFIG_OF and skip if it isn't enabled?
> > >
> >
> > More of the opposite: that we should have some way of supporting tests
> > which might want to use a DTB other than the built-in one. Mostly for
> > non-UML situations where an actual devicetree is needed to even boot
> > far enough to get test output (so we wouldn't be able to override it
> > with a compiled-in test one).
>
> Ok, got it.
>
> >
> > I think moving to overlays probably will render this idea obsolete:
> > but the thought was to give test code a way to check for the required
> > devicetree nodes at runtime, and skip the test if they weren't found.
> > That way, the failure mode for trying to boot this on something which
> > required another device tree for, e.g., serial, would be "these tests
> > are skipped because the wrong device tree is loaded", not "I get no
> > output because serial isn't working".
> >
> > Again, though, it's only really needed for non-UML, and just loading
> > overlays as needed should be much more sensible anyway.
>
> I still have one niggle here. Loading overlays requires
> CONFIG_OF_OVERLAY, and the overlay loading API returns -ENOTSUPP when
> CONFIG_OF_OVERLAY=n. For now I'm checking for the config being enabled
> in each test, but I'm thinking it may be better to simply call
> kunit_skip() from the overlay loading function if the config is
> disabled. This way tests can simply call the overlay loading function
> and we'll halt the test immediately if the config isn't enabled.
>
That sounds sensible, though there is a potential pitfall. If
kunit_skip() is called directly from overlay code, might introduce a
dependency on kunit.ko from the DT overlay, which we might not want.
The solution there is either to have a kunit wrapper function (so the
call is already in kunit.ko), or to have a hook to skip the current
test (which probably makes sense to do anyway, but I think the wrapper
is the better option).
> >
> > > >
> > > > That being said, I do think that there's probably some sense in
> > > > supporting the compiled-in DTB as well (it's definitely simpler than
> > > > patching kunit.py to always pass the extra command-line option in, for
> > > > example).
> > > > But maybe it'd be nice to have the command-line option override the
> > > > built-in one if present.
> > >
> > > Got it. I need to test loading another DTB on the commandline still, but
> > > I think this won't be a problem. We'll load the unittest-data DTB even
> > > with KUnit on UML, so assuming that works on UML right now it should be
> > > unchanged by this series once I resend.
> >
> > Again, moving to overlays should render this mostly obsolete, no? Or
> > am I misunderstanding how the overlay stuff will work?
>
> Right, overlays make it largely a moot issue. The way the OF unit tests
> work today is by grafting a DTB onto the live tree. I'm reusing that
> logic to graft a container node target for kunit tests to add their
> overlays too. It will be clearer once I post v2.
>
> >
> > One possible future advantage of being able to test with custom DTs at
> > boot time would be for fuzzing (provide random DT properties, see what
> > happens in the test). We've got some vague plans to support a way of
> > passing custom data to tests to support this kind of case (though, if
> > we're using overlays, maybe the test could just patch those if we
> > wanted to do that).
>
> Ah ok. I can see someone making a fuzzer that modifies devicetree
> properties randomly, e.g. using different strings for clock-names.
>
> This reminds me of another issue I ran into. I wanted to test adding the
> same platform device to the platform bus twice to confirm that the
> second device can't be added. That prints a warning, which makes
> kunit.py think that the test has failed because it printed a warning. Is
> there some way to avoid that? I want something like
>
> KUNIT_EXPECT_WARNING(test, <call some function>)
>
> so I can test error cases.
Hmm... I'd've thought that shouldn't be a problem: kunit.py should
ignore most messages during a test, unless it can't find a valid
result line. What does the raw KTAP output look like? (You can get it
from kunit.py by passing the --raw_output option).
That being said, a KUNIT_EXPECT_LOG_MESSAGE() or similar is something
we've wanted for a while. I think that the KASAN folks have been
working on something similar using console tracepoints:
https://lore.kernel.org/all/ebf96ea600050f00ed567e80505ae8f242633640.166611…
Cheers,
-- David
Copy/pasting the code from the kernel-doc here doesn't compile because
kunit_alloc_resource() takes a gfp flags argument. Pass the gfp
argument from the caller to complete the example.
Signed-off-by: Stephen Boyd <sboyd(a)kernel.org>
---
include/kunit/resource.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/kunit/resource.h b/include/kunit/resource.h
index cf6fb8f2ac1b..c0d88b318e90 100644
--- a/include/kunit/resource.h
+++ b/include/kunit/resource.h
@@ -72,7 +72,7 @@ typedef void (*kunit_resource_free_t)(struct kunit_resource *);
* params.gfp = gfp;
*
* return kunit_alloc_resource(test, kunit_kmalloc_init,
- * kunit_kmalloc_free, ¶ms);
+ * kunit_kmalloc_free, gfp, ¶ms);
* }
*
* Resources can also be named, with lookup/removal done on a name
base-commit: fe15c26ee26efa11741a7b632e9f23b01aca4cc6
--
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/https://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi.git
Hi,
This series contains changes for rcutorture and rcu-related tool, which
are targeted for v6.4.
This is my first time helping prepare PRs, so please take a careful look
and yell at me if there is something wrong. Thanks a lot!
You will also be able to find the series at:
https://github/fbq/linux rcu/rcutorture.2023.03.11a
top commit is:
015d88635382
List of changes:
Bhaskar Chowdhury (1):
tools: rcu: Add usage function and check for argument
Paul E. McKenney (5):
rcutorture: Add test_nmis module parameter
rcutorture: Set CONFIG_BOOTPARAM_HOTPLUG_CPU0 to offline CPU 0
rcutorture: Make scenario TREE04 enable lazy call_rcu()
torture: Permit kvm-again.sh --duration to default to previous run
torture: Enable clocksource watchdog with "tsc=watchdog"
Yue Hu (1):
rcutorture: Eliminate variable n_rcu_torture_boost_rterror
Zqiang (1):
rcutorture: Create nocb kthreads only when testing rcu in
CONFIG_RCU_NOCB_CPU=y kernels
kernel/rcu/rcutorture.c | 49 +++++++++++++++----
tools/rcu/extract-stall.sh | 26 +++++++---
.../selftests/rcutorture/bin/kvm-again.sh | 2 +-
.../selftests/rcutorture/bin/torture.sh | 6 +--
.../selftests/rcutorture/configs/rcu/TREE01 | 1 +
.../selftests/rcutorture/configs/rcu/TREE04 | 1 +
6 files changed, 65 insertions(+), 20 deletions(-)
mode change 100644 => 100755 tools/rcu/extract-stall.sh
--
2.39.2
Hi Linus,
Please pull the following Kselftest fixes update for Linux 6.3-rc3.
This kselftest fixes update for Linux 6.3-rc3 consists of a fix to
amd-pstate test Makefile and a fix to LLVM build for i386 and x86_64
in kselftest common lib.mk.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit fe15c26ee26efa11741a7b632e9f23b01aca4cc6:
Linux 6.3-rc1 (2023-03-05 14:52:03 -0800)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-fixes-6.3-rc3
for you to fetch changes up to 624c60f326c6e5a80b008e8a5c7feffe8c27dc72:
selftests: fix LLVM build for i386 and x86_64 (2023-03-10 13:41:10 -0700)
----------------------------------------------------------------
linux-kselftest-fixes-6.3-rc3
This kselftest fixes update for Linux 6.3-rc3 consists of a fix to
amd-pstate test Makefile and a fix to LLVM build for i386 and x86_64
in kselftest common lib.mk.
----------------------------------------------------------------
Guillaume Tucker (2):
selftests: amd-pstate: fix TEST_FILES
selftests: fix LLVM build for i386 and x86_64
tools/testing/selftests/amd-pstate/Makefile | 13 +++++++++----
tools/testing/selftests/lib.mk | 2 ++
2 files changed, 11 insertions(+), 4 deletions(-)
----------------------------------------------------------------
When running the in-kernel Dhrystone benchmark with
CONFIG_DEBUG_PREEMPT=y:
BUG: using smp_processor_id() in preemptible [00000000] code: bash/938
Fix this by not using smp_processor_id() directly, but instead wrapping
the whole benchmark inside a get_cpu()/put_cpu() pair. This makes sure
the whole benchmark is run on the same CPU core, and the reported values
are consistent.
Fixes: d5528cc16893f1f6 ("lib: add Dhrystone benchmark test")
Reported-by: Tobias Klausmann <klausman(a)schwarzvogel.de>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217179
Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be>
---
lib/dhry_run.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/dhry_run.c b/lib/dhry_run.c
index f9d33efa6d090604..f15ac666e9d38bd2 100644
--- a/lib/dhry_run.c
+++ b/lib/dhry_run.c
@@ -31,6 +31,7 @@ MODULE_PARM_DESC(iterations,
static void dhry_benchmark(void)
{
+ unsigned int cpu = get_cpu();
int i, n;
if (iterations > 0) {
@@ -45,9 +46,10 @@ static void dhry_benchmark(void)
}
report:
+ put_cpu();
if (n >= 0)
- pr_info("CPU%u: Dhrystones per Second: %d (%d DMIPS)\n",
- smp_processor_id(), n, n / DHRY_VAX);
+ pr_info("CPU%u: Dhrystones per Second: %d (%d DMIPS)\n", cpu,
+ n, n / DHRY_VAX);
else if (n == -EAGAIN)
pr_err("Please increase the number of iterations\n");
else
--
2.34.1
The `devlink -j port show` command output may not contain the "flavour"
key, an example from s390x LPAR with Ubuntu 22.10 (5.19.0-37-generic),
iproute2-5.15.0:
{"port":{"pci/0001:00:00.0/1":{"type":"eth","netdev":"ens301"},
"pci/0001:00:00.0/2":{"type":"eth","netdev":"ens301d1"},
"pci/0002:00:00.0/1":{"type":"eth","netdev":"ens317"},
"pci/0002:00:00.0/2":{"type":"eth","netdev":"ens317d1"}}}
This will cause a KeyError exception.
Create a validate_devlink_output() to check for this "flavour" from
devlink command output to avoid this KeyError exception. Also let
it handle the check for `devlink -j dev show` output in main().
Apart from this, if the test was not started because of any reason
(e.g. "lanes" does not exist, max lanes is 0 or the flavour of the
designated device is not "physical" and etc.) The script will still
return 0 and thus causing a false-negative test result.
Use a test_ran flag to determine if these tests were skipped and
return KSFT_SKIP to make it more clear.
V2: factor out the skip logic from main(), update commit message and
skip reasons accordingly.
Link: https://bugs.launchpad.net/bugs/1937133
Fixes: f3348a82e727 ("selftests: net: Add port split test")
Signed-off-by: Po-Hsu Lin <po-hsu.lin(a)canonical.com>
---
tools/testing/selftests/net/devlink_port_split.py | 36 +++++++++++++++++++----
1 file changed, 31 insertions(+), 5 deletions(-)
diff --git a/tools/testing/selftests/net/devlink_port_split.py b/tools/testing/selftests/net/devlink_port_split.py
index 2b5d6ff..749606c 100755
--- a/tools/testing/selftests/net/devlink_port_split.py
+++ b/tools/testing/selftests/net/devlink_port_split.py
@@ -59,6 +59,8 @@ class devlink_ports(object):
assert stderr == ""
ports = json.loads(stdout)['port']
+ validate_devlink_output(ports, 'flavour')
+
for port in ports:
if dev in port:
if ports[port]['flavour'] == 'physical':
@@ -220,6 +222,27 @@ def split_splittable_port(port, k, lanes, dev):
unsplit(port.bus_info)
+def validate_devlink_output(devlink_data, target_property=None):
+ """
+ Determine if test should be skipped by checking:
+ 1. devlink_data contains values
+ 2. The target_property exist in devlink_data
+ """
+ skip_reason = None
+ if any(devlink_data.values()):
+ if target_property:
+ skip_reason = "{} not found in devlink output, test skipped".format(target_property)
+ for key in devlink_data:
+ if target_property in devlink_data[key]:
+ skip_reason = None
+ else:
+ skip_reason = 'devlink output is empty, test skipped'
+
+ if skip_reason:
+ print(skip_reason)
+ sys.exit(KSFT_SKIP)
+
+
def make_parser():
parser = argparse.ArgumentParser(description='A test for port splitting.')
parser.add_argument('--dev',
@@ -231,6 +254,7 @@ def make_parser():
def main(cmdline=None):
+ test_ran = False
parser = make_parser()
args = parser.parse_args(cmdline)
@@ -240,12 +264,9 @@ def main(cmdline=None):
stdout, stderr = run_command(cmd)
assert stderr == ""
+ validate_devlink_output(json.loads(stdout))
devs = json.loads(stdout)['dev']
- if devs:
- dev = list(devs.keys())[0]
- else:
- print("no devlink device was found, test skipped")
- sys.exit(KSFT_SKIP)
+ dev = list(devs.keys())[0]
cmd = "devlink dev show %s" % dev
stdout, stderr = run_command(cmd)
@@ -277,6 +298,11 @@ def main(cmdline=None):
split_splittable_port(port, lane, max_lanes, dev)
lane //= 2
+ test_ran = True
+
+ if not test_ran:
+ print("Test not started, no suitable device for the test")
+ sys.exit(KSFT_SKIP)
if __name__ == "__main__":
--
2.7.4
Hi Stephen,
On Thu, Mar 09, 2023 at 03:31:15PM -0800, Stephen Boyd wrote:
> Quoting Maxime Ripard (2023-03-03 06:35:28)
> > On Fri, Mar 03, 2023 at 03:15:31PM +0800, David Gow wrote:
> > >
> > > DRM has a similar thing already (albeit with a root_device, which is
> > > more common with KUnit tests generally):
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/inc…
> > >
> > > But that's reasonably drm-specific, so it makes sense that it lives
> > > with DRM stuff. platform_device is a bit more generic.
> >
> > I'd be very happy to get something from the core to address the same
> > thing.
> >
> > I think the main thing we needed that isn't covered by this patch is we
> > wanted the device to be bound to its driver, so with probe being called
> > before calling the test (see 57a84a97bbda).
>
> Can you clarify? This patch makes a poor attempt at waiting for the
> platform driver to bind, but in reality it may not be bound by the time
> the driver register function returns.
The issue was that devm will only clean up the resources if the device
was bound to a driver so we were exhausting resources when running
dozens of test in a sequence.
The way I solved it for vc4 was to create a dumb platform driver with a
waitqueue, and wait for probe to be called.
I think we could make it more generic by allowing a pointer to a probe
function and calling it into our own probe implementation. What do you
think?
Maxime