This series provides a bunch of quick updates which should make the
coverage from pcm-test a bit more useful, it adds some support for
skipping tests when the hardware/driver is unable to support the
requested configuration and then expands the set of cases we cover to
include more sample rates and channel counts. This should exercise
switching between 8kHz and 44.1kHz based rates and ensure that clocking
doesn't get confused by non-stereo channel counts, both of which are I
expect common real world errors, at least for embedded cards.
Mark Brown (6):
kselftest/alsa: Refactor pcm-test to list the tests to run in a struct
kselftest/alsa: Report failures to set the requested sample rate as
skips
kselftest/alsa: Report failures to set the requested channels as skips
kselftest/alsa: Don't any configuration in the sample config
kselftest/alsa: Provide more meaningful names for tests
kselftest/alsa: Add more coverage of sample rates and channel counts
.../alsa/conf.d/Lenovo_ThinkPad_P1_Gen2.conf | 35 ++++----
tools/testing/selftests/alsa/pcm-test.c | 88 +++++++++++++------
2 files changed, 81 insertions(+), 42 deletions(-)
base-commit: 1d8025ec722d5e011f9299c46274eb21fb54a428
--
2.30.2
This series contains a few improvements to fp-stress performance, only
noticable on emulated platforms which both run more slowly and are
stressed far more by fp-stress due to supporting more VLs for SVE and
SME. The bulk of the improvement comes from the first patch which
reduces the amount of time the main fp-stress executable is swamped by
load from the child processes during startup, the other two patches are
much more marginal.
v2:
- Rebase onto arm64/for-next/selftests
Mark Brown (3):
kselftest/arm64: Hold fp-stress children until they're all spawned
kselftest/arm64: Don't drain output while spawning children
kselftest/arm64: Allow epoll_wait() to return more than one result
tools/testing/selftests/arm64/fp/fp-stress.c | 74 +++++++++++++++-----
1 file changed, 57 insertions(+), 17 deletions(-)
base-commit: 642978981ec8a79da00828c696c58b3732b993a6
--
2.30.2
Thanks to the patch 6/11, the MPTCP path manager now sends Netlink events when
MPTCP listening sockets are created and closed. The reason why it is needed is
explained in the linked ticket [1]:
MPTCP for Linux, when not using the in-kernel PM, depends on the userspace PM
to create extra listening sockets before announcing addresses and ports. Let's
call these "PM listeners".
With the existing MPTCP netlink events, a userspace PM can create PM listeners
at startup time, or in response to an incoming connection. Creating sockets in
response to connections is not optimal: ADD_ADDRs can't be sent until the
sockets are created and listen()ed, and if all connections are closed then it
may not be clear to the userspace PM daemon that PM listener sockets should be
cleaned up.
Hence this feature request: to add MPTCP netlink events for listening socket
close & create, so PM listening sockets can be managed based on application
activity.
[1] https://github.com/multipath-tcp/mptcp_net-next/issues/313
Selftests for these new Netlink events have been added in patches 9,11/11.
The remaining patches introduce different cleanups and small improvements in
MPTCP selftests to ease the maintenance and the addition of new tests.
Geliang Tang (6):
mptcp: add pm listener events
selftests: mptcp: enhance userspace pm tests
selftests: mptcp: make evts global in userspace_pm
selftests: mptcp: listener test for userspace PM
selftests: mptcp: make evts global in mptcp_join
selftests: mptcp: listener test for in-kernel PM
Matthieu Baerts (5):
selftests: mptcp: run mptcp_inq from a clean netns
selftests: mptcp: removed defined but unused vars
selftests: mptcp: uniform 'rndh' variable
selftests: mptcp: clearly declare global ns vars
selftests: mptcp: declare var as local
include/uapi/linux/mptcp.h | 9 +
net/mptcp/pm_netlink.c | 57 ++++
net/mptcp/protocol.c | 3 +
net/mptcp/protocol.h | 2 +
tools/testing/selftests/net/mptcp/diag.sh | 1 +
.../selftests/net/mptcp/mptcp_connect.sh | 6 +-
.../testing/selftests/net/mptcp/mptcp_join.sh | 118 +++++--
.../selftests/net/mptcp/mptcp_sockopt.sh | 69 ++--
.../selftests/net/mptcp/simult_flows.sh | 4 +-
.../selftests/net/mptcp/userspace_pm.sh | 298 ++++++++++--------
10 files changed, 375 insertions(+), 192 deletions(-)
base-commit: 91a7de85600d5dfa272cea3cef83052e067dc0ab
--
2.37.2
The 'index' and 'start' pages end with very similar "How Do I Use This"
/ "Next Steps" sections respectively, which link to the other
documentation pages. This wasn't updated when the tips.rst page was
removed.
Remove the reference to tips.rst, as well as tidy up the descriptions on
all of the links (especially given that sphinx gives the page titles
anyway.
Fixes: 4399c737a97d ("Documentation: kunit: Remove redundant 'tips.rst' page")
Signed-off-by: David Gow <davidgow(a)google.com>
---
Documentation/dev-tools/kunit/index.rst | 18 +++++++-----------
Documentation/dev-tools/kunit/start.rst | 16 ++++++----------
2 files changed, 13 insertions(+), 21 deletions(-)
diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst
index d5629817cd72..beec6f847ef4 100644
--- a/Documentation/dev-tools/kunit/index.rst
+++ b/Documentation/dev-tools/kunit/index.rst
@@ -99,14 +99,10 @@ Read also :ref:`kinds-of-tests`.
How do I use it?
================
-* Documentation/dev-tools/kunit/start.rst - for KUnit new users.
-* Documentation/dev-tools/kunit/architecture.rst - KUnit architecture.
-* Documentation/dev-tools/kunit/run_wrapper.rst - run kunit_tool.
-* Documentation/dev-tools/kunit/run_manual.rst - run tests without kunit_tool.
-* Documentation/dev-tools/kunit/usage.rst - write tests.
-* Documentation/dev-tools/kunit/tips.rst - best practices with
- examples.
-* Documentation/dev-tools/kunit/api/index.rst - KUnit APIs
- used for testing.
-* Documentation/dev-tools/kunit/faq.rst - KUnit common questions and
- answers.
+* Documentation/dev-tools/kunit/start.rst - for new KUnit users
+* Documentation/dev-tools/kunit/architecture.rst - how KUnit is put together
+* Documentation/dev-tools/kunit/run_wrapper.rst - run tests via kunit.py
+* Documentation/dev-tools/kunit/run_manual.rst - run tests without kunit.py
+* Documentation/dev-tools/kunit/usage.rst - write tests
+* Documentation/dev-tools/kunit/api/index.rst - API reference
+* Documentation/dev-tools/kunit/faq.rst - common questions and answers
diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst
index f4f504f1fb15..58c176348885 100644
--- a/Documentation/dev-tools/kunit/start.rst
+++ b/Documentation/dev-tools/kunit/start.rst
@@ -294,13 +294,9 @@ Congrats! You just wrote your first KUnit test.
Next Steps
==========
-* Documentation/dev-tools/kunit/architecture.rst - KUnit architecture.
-* Documentation/dev-tools/kunit/run_wrapper.rst - run kunit_tool.
-* Documentation/dev-tools/kunit/run_manual.rst - run tests without kunit_tool.
-* Documentation/dev-tools/kunit/usage.rst - write tests.
-* Documentation/dev-tools/kunit/tips.rst - best practices with
- examples.
-* Documentation/dev-tools/kunit/api/index.rst - KUnit APIs
- used for testing.
-* Documentation/dev-tools/kunit/faq.rst - KUnit common questions and
- answers.
+* Documentation/dev-tools/kunit/architecture.rst - how KUnit is put together
+* Documentation/dev-tools/kunit/run_wrapper.rst - run tests via kunit.py
+* Documentation/dev-tools/kunit/run_manual.rst - run tests without kunit.py
+* Documentation/dev-tools/kunit/usage.rst - write tests
+* Documentation/dev-tools/kunit/api/index.rst - API reference
+* Documentation/dev-tools/kunit/faq.rst - common questions and answers
--
2.38.1.584.g0f3c55d4c2-goog
On 11/28/22 15:53, Maxime Ripard wrote:
> In order to test the current atomic_check hooks we need to have a DRM
> device that has roughly the same capabilities and layout that the actual
> hardware. We'll also need a bunch of functions to create arbitrary
> atomic states.
>
> Let's create some helpers to create a device that behaves like the real
> one, and some helpers to maintain the atomic state we want to check.
>
> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
> ---
[...]
> +
> +config DRM_VC4_KUNIT_TEST
> + bool "KUnit tests for VC4" if !KUNIT_ALL_TESTS
> + depends on DRM_VC4 && KUNIT
shouldn't this depend on DRM_KUNIT_TEST instead ?
[...]
> +static struct vc4_dev *__mock_device(struct kunit *test, bool is_vc5)
> +{
> + struct drm_device *drm;
> + const struct drm_driver *drv = is_vc5 ? &vc5_drm_driver : &vc4_drm_driver;
> + const struct vc4_mock_desc *desc = is_vc5 ? &vc5_mock : &vc4_mock;
> + struct vc4_dev *vc4;
Since it could be vc4 or vc5, maybe can be renamed to just struct vc_dev *vc ?
> +struct vc4_dummy_plane *vc4_dummy_plane(struct kunit *test,
> + struct drm_device *drm,
> + enum drm_plane_type type)
> +{
> + struct vc4_dummy_plane *dummy_plane;
> + struct drm_plane *plane;
> +
> + dummy_plane = drmm_universal_plane_alloc(drm,
> + struct vc4_dummy_plane, plane.base,
> + 0,
> + &vc4_dummy_plane_funcs,
> + vc4_dummy_plane_formats,
> + ARRAY_SIZE(vc4_dummy_plane_formats),
> + NULL,
> + DRM_PLANE_TYPE_PRIMARY,
> + NULL);
> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dummy_plane);
> +
> + plane = &dummy_plane->plane.base;
> + drm_plane_helper_add(plane, &vc4_dummy_plane_helper_funcs);
> +
> + return dummy_plane;
> +}
I guess many of these helpers could grow to be generic, like this one since
most drivers support the DRM_FORMAT_XRGB8888 format for their primary plane.
[...]
>
> +extern const struct vc4_pv_data bcm2835_pv0_data;
> +extern const struct vc4_pv_data bcm2835_pv1_data;
> +extern const struct vc4_pv_data bcm2835_pv2_data;
> +extern const struct vc4_pv_data bcm2711_pv0_data;
> +extern const struct vc4_pv_data bcm2711_pv1_data;
> +extern const struct vc4_pv_data bcm2711_pv2_data;
> +extern const struct vc4_pv_data bcm2711_pv3_data;
> +extern const struct vc4_pv_data bcm2711_pv4_data;
> +
Maybe the driver could expose a helper function to get the pixelvalve data
and avoid having to expose all of these variables? For example you could
define an enum vc4_pixelvalve type and have something like the following:
const struct vc4_pv_data *vc4_crtc_get_pixelvalve_data(enum vc4_pixelvalve pv);
All these are small nits though, the patch looks great to me and I think is
awesome to have this level of testing with KUnit. Hope other drivers follow
your lead.
Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 11/28/22 15:53, Maxime Ripard wrote:
> We'll need to use those helpers from drivers too, so let's move it to a
> more visible location.
>
> Signed-off-by: Maxime Ripard <maxime(a)cerno.tech>
> ---
> drivers/gpu/drm/tests/drm_client_modeset_test.c | 3 +--
> drivers/gpu/drm/tests/drm_kunit_helpers.c | 3 +--
> drivers/gpu/drm/tests/drm_modes_test.c | 3 +--
> drivers/gpu/drm/tests/drm_probe_helper_test.c | 3 +--
> {drivers/gpu/drm/tests => include/drm}/drm_kunit_helpers.h | 0
> 5 files changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/tests/drm_client_modeset_test.c b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> index 52929536a158..ed2f62e92fea 100644
> --- a/drivers/gpu/drm/tests/drm_client_modeset_test.c
> +++ b/drivers/gpu/drm/tests/drm_client_modeset_test.c
> @@ -8,12 +8,11 @@
> #include <drm/drm_connector.h>
> #include <drm/drm_edid.h>
> #include <drm/drm_drv.h>
> +#include <drm/drm_kunit_helpers.h>
I wonder if now that this header was moved outside of the tests directory,
if we should add stub functions in the header file that are just defined
but do nothing if CONFIG_DRM_KUNIT_TEST isn't enabled. So that including
it in drivers will be a no-op.
Or do you plan to conditionally include this header file in drivers? So
that is only included when CONFIG_DRM_KUNIT_TEST is enabled?
Another thing that wondered is if we want a different namespace for this
header, i.e: <drm/testing/drm_kunit_helpers.h>, to make it clear that is
not part of the DRM API but just for testing helpers.
But these are open questions really, and they can be done as follow-up:
Reviewed-by: Javier Martinez Canillas <javierm(a)redhat.com>
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
This patch series adds xfrm metadata helpers using the unstable kfunc
call interface for the TC-BPF hooks.
This allows steering traffic towards different IPsec connections based
on logic implemented in bpf programs.
The helpers are integrated into the xfrm_interface module. For this
purpose the main functionality of this module is moved to
xfrm_interface_core.c.
Eyal Birger (3):
xfrm: interface: rename xfrm_interface.c to xfrm_interface_core.c
xfrm: interface: Add unstable helpers for setting/getting XFRM
metadata from TC-BPF
selftests/bpf: add xfrm_info tests
include/net/dst_metadata.h | 1 +
include/net/xfrm.h | 20 +
net/core/dst.c | 4 +
net/xfrm/Makefile | 8 +
net/xfrm/xfrm_interface_bpf.c | 92 +++++
...xfrm_interface.c => xfrm_interface_core.c} | 15 +
tools/testing/selftests/bpf/config | 2 +
.../selftests/bpf/prog_tests/test_xfrm_info.c | 342 ++++++++++++++++++
.../selftests/bpf/progs/test_xfrm_info_kern.c | 74 ++++
9 files changed, 558 insertions(+)
create mode 100644 net/xfrm/xfrm_interface_bpf.c
rename net/xfrm/{xfrm_interface.c => xfrm_interface_core.c} (98%)
create mode 100644 tools/testing/selftests/bpf/prog_tests/test_xfrm_info.c
create mode 100644 tools/testing/selftests/bpf/progs/test_xfrm_info_kern.c
--
2.34.1
Changes from RFC v1
(https://lore.kernel.org/damon/20221124212114.136863-1-sj@kernel.org/)
- sysfs: Clean up filters directory from scheme directory cleanup path
- sysfs: Link newly created filter to the scheme
- sysfs: Ignore removed memcg when checking path
- sysfs: Guard 'struct mem_cgroup' access with CONFIG_MEMCG
(kernel test robot)
----
DAMOS let users do system operations in a data access pattern oriented
way. The data access pattern, which is extracted by DAMON, is somewhat
accurate more than what user space could know in many cases. However,
in some situation, users could know something more than the kernel about
the pattern or some special requirements for some types of memory or
processes. For example, some users would have slow swap devices and
knows latency-ciritical processes and therefore want to use DAMON-based
proactive reclamation (DAMON_RECLAIM) for only non-anonymous pages of
non-latency-critical processes.
For such restriction, users could exclude the memory regions from the
initial monitoring regions and use non-dynamic monitoring regions update
monitoring operations set including fvaddr and paddr. They could also
adjust the DAMOS target access pattern. For dynamically changing memory
layout and access pattern, those would be not enough.
To help the case, add an interface, namely DAMOS filters, which can be
used to avoid the DAMOS actions be applied to specific types of memory,
to DAMON kernel API (damon.h). At the moment, it supports filtering
anonymous pages and/or specific memory cgroups in or out for each DAMOS
scheme.
This patchset adds the support for all DAMOS actions that 'paddr'
monitoring operations set supports ('pageout', 'lru_prio', and
'lru_deprio'), and the functionality is exposed via DAMON kernel API
(damon.h) the DAMON sysfs interface (/sys/kernel/mm/damon/admins/), and
DAMON_RECLAIM module parameters.
Patches Sequence
----------------
First patch implements DAMOS filter interface to DAMON kernel API.
Second patch makes the physical address space monitoring operations set
to support the filters from all supporting DAMOS actions. Third patch
adds anonymous pages filter support to DAMON_RECLAIM, and the fourth
patch documents the DAMON_RECLAIM's new feature. Fifth to seventh
patches implement DAMON sysfs files for support of the filters, and
eighth patch connects the file to use DAMOS filters feature. Ninth
patch adds simple self test cases for DAMOS filters of the sysfs
interface. Finally, following two patches (tenth and eleventh) document
the new features and interfaces.
SeongJae Park (11):
mm/damon/core: implement damos filter
mm/damon/paddr: support DAMOS filters
mm/damon/reclaim: add a parameter called skip_anon for avoiding
anonymous pages reclamation
Docs/admin-guide/damon/reclaim: document 'skip_anon' parameter
mm/damon/sysfs-schemes: implement filters directory
mm/damon/sysfs-schemes: implement filter directory
mm/damon/sysfs-schemes: connect filter directory and filters directory
mm/damon/sysfs-schemes: implement scheme filters
selftests/damon/sysfs: test filters directory
Docs/admin-guide/mm/damon/usage: document DAMOS filters of sysfs
Docs/ABI/damon: document scheme filters files
.../ABI/testing/sysfs-kernel-mm-damon | 29 ++
.../admin-guide/mm/damon/reclaim.rst | 9 +
Documentation/admin-guide/mm/damon/usage.rst | 48 ++-
include/linux/damon.h | 51 +++
mm/damon/core.c | 39 ++
mm/damon/paddr.c | 71 +++-
mm/damon/reclaim.c | 19 +
mm/damon/sysfs-schemes.c | 370 +++++++++++++++++-
tools/testing/selftests/damon/sysfs.sh | 29 ++
9 files changed, 652 insertions(+), 13 deletions(-)
--
2.25.1