From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,ziy@nvidia.com,vbabka@kernel.org,
surenb@google.com,shuah@kernel.org,rppt@kernel.org,mhocko@suse.com,
ljs@kernel.org,liam@infradead.org,david@kernel.org,azpijr@gmail.com,
odys.yuan@gmail.com,akpm@linux-foundation.org
Subject: + selftests-mm-track-the-modules-run_vmtestssh-loads.patch added to mm-new branch
Date: Thu, 29 Oct 2026 12:08:58 -0700 [thread overview]
Message-ID: <20261029190858.929911F01824@smtp.kernel.org> (raw)
The patch titled
Subject: selftests/mm: track the modules run_vmtests.sh loads
has been added to the -mm mm-new branch. Its filename is
selftests-mm-track-the-modules-run_vmtestssh-loads.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/selftests-mm-track-the-modules-run_vmtestssh-loads.patch
This patch will later appear in the mm-new branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews. Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.
The mm-new branch of mm.git is not included in linux-next
If a few days of testing in mm-new is successful, the patch will me moved
into mm.git's mm-unstable branch, which is included in linux-next
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Qiliang Yuan <odys.yuan@gmail.com>
Subject: selftests/mm: track the modules run_vmtests.sh loads
Date: Thu, 29 Oct 2026 02:24:35 -0400
Patch series "selftests/mm: run the XFS-backed THP tests when xfs is a
module", v3.
run_vmtests.sh only creates the XFS that "khugepaged all:file" and the
pagecache folio split cases of split_huge_page_test need when xfs is
already registered, so with xfs built as a module and not loaded yet
those tests are all skipped.
Patch 1 adds load_module(), which records the modules the script loads
and unloads them again before it exits, and moves hwpoison_inject over
to it. Patch 2 loads xfs through it.
This patch (of 2):
run_vmtests.sh loads hwpoison_inject for the memory-failure test when it
is not there yet, remembers that in a variable local to run_test() and
unloads the module right after the test.
The thp tests need xfs loaded in the same way, and repeating the load,
the bookkeeping and the unload for every module that some test needs
does not scale.
Add load_module(), which loads a module unless it is already present
and records it, and unload every recorded module, in reverse order,
before the script exits. Use it for hwpoison_inject.
Link: https://lore.kernel.org/20261029-bug-selftests-mm-run-vmtests-xfs-modprobe-v3-0-16ad772850ee@gmail.com
Link: https://lore.kernel.org/20261029-bug-selftests-mm-run-vmtests-xfs-modprobe-v3-1-16ad772850ee@gmail.com
Signed-off-by: Qiliang Yuan <odys.yuan@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Tested-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
Reviewed-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
Cc: David Hildenbrand <david@kernel.org>
Cc: Lorenzo Stoakes <ljs@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Shuah Khan <shuah@kernel.org>
Cc: Zi Yan <ziy@nvidia.com>
---
tools/testing/selftests/mm/run_vmtests.sh | 31 ++++++++++++++------
1 file changed, 23 insertions(+), 8 deletions(-)
--- a/tools/testing/selftests/mm/run_vmtests.sh~selftests-mm-track-the-modules-run_vmtestssh-loads
+++ a/tools/testing/selftests/mm/run_vmtests.sh
@@ -171,11 +171,30 @@ pretty_name() {
echo "$*" | sed -e 's/^\(bash \)\?\.\///'
}
+# Modules this script loaded, unloaded again before it exits
+LOADED_MODULES=()
+
+# Usage: load_module [module]
+load_module() {
+ if [ -d "/sys/module/$1" ]; then
+ return 0
+ fi
+ modprobe -q "$1" || return 1
+ LOADED_MODULES+=("$1")
+}
+
+unload_modules() {
+ local i
+
+ for (( i = ${#LOADED_MODULES[@]} - 1; i >= 0; i-- )); do
+ modprobe -r -q "${LOADED_MODULES[i]}"
+ done
+}
+
# Usage: run_test [test binary] [arbitrary test arguments...]
run_test() {
if test_selected ${CATEGORY}; then
local skip=0
- local LOADED_HWPOISON_INJECT_MOD=0
# On memory constrainted systems some tests can fail to allocate hugepages.
# perform some cleanup before the test for a higher success rate.
@@ -201,8 +220,7 @@ run_test() {
| tap_prefix
skip=1
else
- modprobe hwpoison_inject > /dev/null 2>&1
- LOADED_HWPOISON_INJECT_MOD=1
+ load_module hwpoison_inject
if [ ! -d "$HWPOISON_DIR" ]; then
echo "hwpoison debugfs interface not present" \
| tap_prefix
@@ -225,11 +243,6 @@ run_test() {
local ret=${PIPESTATUS[0]}
fi
- # Unload hwpoison_inject if we loaded it
- if [ "${LOADED_HWPOISON_INJECT_MOD}" = "1" ]; then
- modprobe -r hwpoison_inject > /dev/null 2>&1
- fi
-
count_total=$(( count_total + 1 ))
if [ $ret -eq 0 ]; then
count_pass=$(( count_pass + 1 ))
@@ -453,4 +466,6 @@ CATEGORY="memory-failure" run_test ./mem
echo "SUMMARY: PASS=${count_pass} SKIP=${count_skip} FAIL=${count_fail}" | tap_prefix
echo "1..${count_total}" | tap_output
+unload_modules
+
exit $exitcode
_
Patches currently in -mm which might be from odys.yuan@gmail.com are
selftests-mm-track-the-modules-run_vmtestssh-loads.patch
selftests-mm-load-xfs-before-checking-for-it-in-run_vmtestssh.patch
reply other threads:[~2026-10-29 19:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261029190858.929911F01824@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=azpijr@gmail.com \
--cc=david@kernel.org \
--cc=liam@infradead.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=mm-commits@vger.kernel.org \
--cc=odys.yuan@gmail.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.