Hi Linus,
Please pull the following Kselftest fixes update for Linux 6.6-rc2.
This kselftest fixes update for Linux 6.6-rc2 consists of fixes
-- kselftest runner script to propagate SIGTERM to runner child
to avoid kselftest hang.
-- to install symlinks required for test execution to avoid test
failures.
-- kselftest dependency checker script argument parsing.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 9b1db732866bee060b9bca9493e5ebf5e8874c48:
selftests: cachestat: use proper syscall number macro (2023-08-16 11:12:44 -0600)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-next-6.6-rc2
for you to fetch changes up to 3f3f384139ed147c71e1d770accf610133d5309b:
selftests: Keep symlinks, when possible (2023-09-08 10:06:56 -0600)
----------------------------------------------------------------
linux-kselftest-next-6.6-rc2
This kselftest fixes update for Linux 6.6-rc2 consists of fixes
-- kselftest runner script to propagate SIGTERM to runner child
to avoid kselftest hang.
-- to install symlinks required for test execution to avoid test
failures.
-- kselftest dependency checker script argument parsing.
----------------------------------------------------------------
Björn Töpel (2):
kselftest/runner.sh: Propagate SIGTERM to runner child
selftests: Keep symlinks, when possible
Ricardo B. Marliere (1):
selftests: fix dependency checker script
Zheng Yejian (1):
selftests/ftrace: Correctly enable event in instance-event.tc
.../ftrace/test.d/instances/instance-event.tc | 2 +-
tools/testing/selftests/kselftest/runner.sh | 3 +-
tools/testing/selftests/kselftest_deps.sh | 77 ++++++++++++++++++----
tools/testing/selftests/lib.mk | 4 +-
4 files changed, 70 insertions(+), 16 deletions(-)
----------------------------------------------------------------
Hi Linus,
Please pull the following KUnit fixes update for Linux 6.6-rc2.
This kunit update for Linux 6.6-rc2 consists of important fixes to
possible memory leak, null-ptr-deref, wild-memory-access, and error
path bugs.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit 25e324bc9cf2ee956eec1db384c39c1a17b7c44a:
kunit: fix struct kunit_attr header (2023-08-21 08:07:56 -0600)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest tags/linux-kselftest-kunit-6.6-rc2
for you to fetch changes up to 9076bc476d7ebf0565903c4b048442131825c1c3:
kunit: Fix possible memory leak in kunit_filter_suites() (2023-09-05 12:30:06 -0600)
----------------------------------------------------------------
linux-kselftest-kunit-6.6-rc2
This kunit update for Linux 6.6-rc2 consists of important fixes to
possible memory leak, null-ptr-deref, wild-memory-access, and error
path bugs.
----------------------------------------------------------------
David Gow (1):
kunit: test: Make filter strings in executor_test writable
Jinjie Ruan (4):
kunit: Fix wild-memory-access bug in kunit_free_suite_set()
kunit: Fix the wrong err path and add goto labels in kunit_filter_suites()
kunit: Fix possible null-ptr-deref in kunit_parse_glob_filter()
kunit: Fix possible memory leak in kunit_filter_suites()
lib/kunit/executor.c | 48 ++++++++++++++++++++++++++++++++---------------
lib/kunit/executor_test.c | 13 ++++++++-----
lib/kunit/test.c | 3 ++-
3 files changed, 43 insertions(+), 21 deletions(-)
----------------------------------------------------------------
Hello,
kernel test robot noticed "kernel-selftests.openat2.resolve_test.fail" on:
commit: 58e2847ad2e6322a25dedf8b4549ff924baf8395 ("selftests: line buffer test program's stdout")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
[test failed on linus/master 0bb80ecc33a8fb5a682236443c1e740d5c917d1d]
[test failed on linux-next/master 7bc675554773f09d88101bf1ccfc8537dc7c0be9]
in testcase: kernel-selftests
version: kernel-selftests-x86_64-60acb023-1_20230329
with following parameters:
group: group-02
compiler: gcc-12
test machine: 36 threads 1 sockets Intel(R) Core(TM) i9-10980XE CPU @ 3.00GHz (Cascade Lake) with 32G memory
(please refer to attached dmesg/kmsg for entire log/backtrace)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang(a)intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202309121342.97e2f008-oliver.sang@intel.com
besides kernel-selftests.openat2.resolve_test, we also observed
ea09800bf17561a0 58e2847ad2e6322a25dedf8b454
---------------- ---------------------------
fail:runs %reproduction fail:runs
| | |
:6 100% 6:6 kernel-selftests.openat2.openat2_test.fail
:6 100% 6:6 kernel-selftests.openat2.resolve_test.fail
which pass on parent commit.
however, there are other tests such like below "perf_events: sigtrap_threads"
are not impacted by this commit.
we want to consult with you if there is some special config need to do after
this commit? Thanks a lot!
TAP version 13
1..3
# timeout set to 300
# selftests: openat2: openat2_test
# ==4052==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
not ok 1 selftests: openat2: openat2_test # exit=1
# timeout set to 300
# selftests: openat2: resolve_test
# ==4070==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.
not ok 2 selftests: openat2: resolve_test # exit=1
...
TAP version 13
1..2
# timeout set to 120
# selftests: perf_events: sigtrap_threads
# TAP version 13
# 1..5
# # Starting 5 tests from 1 test cases.
# # RUN sigtrap_threads.remain_disabled ...
# # OK sigtrap_threads.remain_disabled
# ok 1 sigtrap_threads.remain_disabled
...
The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20230912/202309121342.97e2f008-oliv…
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
When dynamically linking, Address Sanitizer requires its library to be
the first one to be loaded; this is apparently to ensure that every call
to malloc is intercepted. If using LD_PRELOAD, those listed libraries
will be loaded before the libraries listed in the program's ELF and will
therefore violate this requirement, leading to the below failure and
output from ASan.
commit 58e2847ad2e6 ("selftests: line buffer test program's stdout")
modified the kselftest runner to force line buffering by forcing the
test programs to run through `stdbuf`. It turns out that stdbuf
implements line buffering by injecting a library via LD_PRELOAD.
Therefore selftests that use ASan started failing.
Fix this by statically linking libasan in the affected test programs,
using the `-static-libasan` option. Note this is already the default for
Clang, but not got GCC.
Test output sample for failing case:
TAP version 13
1..3
# timeout set to 300
# selftests: openat2: openat2_test
# ==4052==ASan runtime does not come first in initial library list;
you should either link runtime to your application or manually preload
it with LD_PRELOAD.
not ok 1 selftests: openat2: openat2_test # exit=1
# timeout set to 300
# selftests: openat2: resolve_test
# ==4070==ASan runtime does not come first in initial library list;
you should either link runtime to your application or manually preload
it with LD_PRELOAD.
not ok 2 selftests: openat2: resolve_test # exit=1
Signed-off-by: Ryan Roberts <ryan.roberts(a)arm.com>
Fixes: 58e2847ad2e6 ("selftests: line buffer test program's stdout")
Reported-by: kernel test robot <oliver.sang(a)intel.com>
Closes: https://lore.kernel.org/oe-lkp/202309121342.97e2f008-oliver.sang@intel.com
---
tools/testing/selftests/fchmodat2/Makefile | 2 +-
tools/testing/selftests/openat2/Makefile | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/fchmodat2/Makefile b/tools/testing/selftests/fchmodat2/Makefile
index 20839f8e43f2..71ec34bf1501 100644
--- a/tools/testing/selftests/fchmodat2/Makefile
+++ b/tools/testing/selftests/fchmodat2/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-or-later
-CFLAGS += -Wall -O2 -g -fsanitize=address -fsanitize=undefined $(KHDR_INCLUDES)
+CFLAGS += -Wall -O2 -g -fsanitize=address -fsanitize=undefined -static-libasan $(KHDR_INCLUDES)
TEST_GEN_PROGS := fchmodat2_test
include ../lib.mk
diff --git a/tools/testing/selftests/openat2/Makefile b/tools/testing/selftests/openat2/Makefile
index 843ba56d8e49..254d676a2689 100644
--- a/tools/testing/selftests/openat2/Makefile
+++ b/tools/testing/selftests/openat2/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0-or-later
-CFLAGS += -Wall -O2 -g -fsanitize=address -fsanitize=undefined
+CFLAGS += -Wall -O2 -g -fsanitize=address -fsanitize=undefined -static-libasan
TEST_GEN_PROGS := openat2_test resolve_test rename_attack_test
include ../lib.mk
--
2.25.1
Hi,
I am experiencing many warnings when trying to build tools/testing/selftests.
Here's one such example from rseq tree:
| param_test.c:1234:10: error: address argument to atomic operation must be a pointer to _Atomic type ('intptr_t *' (aka 'long *') invalid)
| 1234 | while (!atomic_load(&args->percpu_list_ptr)) {}
| | ^ ~~~~~~~~~~~~~~~~~~~~~~
| /usr/local/google/home/justinstitt/repos/tc-build/build/llvm/final/lib/clang/18/include/stdatomic.h:140:29: note: expanded from macro 'atomic_load'
| 140 | #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST)
| | ^ ~~~~~~
I added the _Atomic type in various locations to silence _all_ (10) of these
warnings. I'm wondering, though, perhaps the absence of these _Atomic
types in the first place is on purpose? Am I on the right track to fix
these warnings without damaging the legitimacy of the tests at hand?
I'd like some feedback about where to go from here and if others are
experiencing the same issues. Thanks!
FWIW here's my specific build incantation on Clang-18 (49d41de57896e935cd5726719c5208bce22694ae):
$ make LLVM=1 -j128 ARCH=x86_64 mrproper headers defconfig kselftest-merge
$ make LLVM=1 ARCH=x86_64 -C tools/testing/selftests
Link: https://github.com/ClangBuiltLinux/linux/issues/1698
Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/61
Signed-off-by: Justin Stitt <justinstitt(a)google.com>
---
tools/testing/selftests/rseq/param_test.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/rseq/param_test.c b/tools/testing/selftests/rseq/param_test.c
index bf951a490bb4..94802aeed2c6 100644
--- a/tools/testing/selftests/rseq/param_test.c
+++ b/tools/testing/selftests/rseq/param_test.c
@@ -356,7 +356,7 @@ struct inc_thread_test_data {
};
struct percpu_list_node {
- intptr_t data;
+ _Atomic intptr_t data;
struct percpu_list_node *next;
};
@@ -1212,8 +1212,8 @@ static int set_signal_handler(void)
/* Test MEMBARRIER_CMD_PRIVATE_RESTART_RSEQ_ON_CPU membarrier command. */
#ifdef TEST_MEMBARRIER
struct test_membarrier_thread_args {
- int stop;
- intptr_t percpu_list_ptr;
+ _Atomic int stop;
+ _Atomic intptr_t percpu_list_ptr;
};
/* Worker threads modify data in their "active" percpu lists. */
@@ -1240,7 +1240,7 @@ void *test_membarrier_worker_thread(void *arg)
int cpu = get_current_cpu_id();
ret = rseq_offset_deref_addv(RSEQ_MO_RELAXED, RSEQ_PERCPU,
- &args->percpu_list_ptr,
+ (intptr_t*)&args->percpu_list_ptr,
sizeof(struct percpu_list_entry) * cpu, 1, cpu);
} while (rseq_unlikely(ret));
}
---
base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
change-id: 20230908-kselftest-param_test-c-1763b62e762f
Best regards,
--
Justin Stitt <justinstitt(a)google.com>
From: Masami Hiramatsu (Google) <mhiramat(a)kernel.org>
Fix to unmount the tracefs if the ftracetest mounted it for recovering
system environment. If the tracefs is already mounted, this does nothing.
Suggested-by: Mark Brown <broonie(a)kernel.org>
Link: https://lore.kernel.org/all/29fce076-746c-4650-8358-b4e0fa215cf7@sirena.org…
Fixes: cbd965bde74c ("ftrace/selftests: Return the skip code when tracing directory not configured in kernel")
Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org>
---
tools/testing/selftests/ftrace/ftracetest | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/tools/testing/selftests/ftrace/ftracetest b/tools/testing/selftests/ftrace/ftracetest
index cb5f18c06593..89c212d82256 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -31,6 +31,9 @@ err_ret=1
# kselftest skip code is 4
err_skip=4
+# umount required
+UMOUNT_DIR=""
+
# cgroup RT scheduling prevents chrt commands from succeeding, which
# induces failures in test wakeup tests. Disable for the duration of
# the tests.
@@ -45,6 +48,9 @@ setup() {
cleanup() {
echo $sched_rt_runtime_orig > $sched_rt_runtime
+ if [ "${UMOUNT_DIR}" ]; then
+ umount ${UMOUNT_DIR} ||:
+ fi
}
errexit() { # message
@@ -160,11 +166,13 @@ if [ -z "$TRACING_DIR" ]; then
mount -t tracefs nodev /sys/kernel/tracing ||
errexit "Failed to mount /sys/kernel/tracing"
TRACING_DIR="/sys/kernel/tracing"
+ UMOUNT_DIR=${TRACING_DIR}
# If debugfs exists, then so does /sys/kernel/debug
elif [ -d "/sys/kernel/debug" ]; then
mount -t debugfs nodev /sys/kernel/debug ||
errexit "Failed to mount /sys/kernel/debug"
TRACING_DIR="/sys/kernel/debug/tracing"
+ UMOUNT_DIR=${TRACING_DIR}
else
err_ret=$err_skip
errexit "debugfs and tracefs are not configured in this kernel"
Dear
My name is Mohamed Abdul I have the capacity to inject a considerable
amount of capital in any viable project
1,cell phone number what-sap
2,full name
yours truly
Mohamed Abdul Ahmed
From: Steven Rostedt (Google) <rostedt(a)goodmis.org>
When I'm debugging something with the ftrace selftests and need to look at
the logs, it becomes tedious that I need to do the following:
ls -ltr logs
[ copy the last directory ]
ls logs/<paste-last-dir>
to see where the logs are.
Instead, do the common practice of having a "latest" softlink to the last
run selftest. This way after running the selftest I only need to do:
ls logs/latest/
and it will always give me the directory of the last run selftest logs!
Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org>
---
diff --git a/tools/testing/selftests/ftrace/ftracetest b/tools/testing/selftests/ftrace/ftracetest
index cb5f18c06593..7df8baa0f98f 100755
--- a/tools/testing/selftests/ftrace/ftracetest
+++ b/tools/testing/selftests/ftrace/ftracetest
@@ -124,6 +124,7 @@ parse_opts() { # opts
;;
--logdir|-l)
LOG_DIR=$2
+ LINK_PTR=
shift 2
;;
*.tc)
@@ -181,7 +182,10 @@ fi
TOP_DIR=`absdir $0`
TEST_DIR=$TOP_DIR/test.d
TEST_CASES=`find_testcases $TEST_DIR`
-LOG_DIR=$TOP_DIR/logs/`date +%Y%m%d-%H%M%S`/
+LOG_TOP_DIR=$TOP_DIR/logs
+LOG_DATE=`date +%Y%m%d-%H%M%S`
+LOG_DIR=$LOG_TOP_DIR/$LOG_DATE/
+LINK_PTR=$LOG_TOP_DIR/latest
KEEP_LOG=0
KTAP=0
DEBUG=0
@@ -207,6 +211,10 @@ else
LOG_FILE=$LOG_DIR/ftracetest.log
mkdir -p $LOG_DIR || errexit "Failed to make a log directory: $LOG_DIR"
date > $LOG_FILE
+ if [ "x-$LINK_PTR" != "x-" ]; then
+ unlink $LINK_PTR
+ ln -fs $LOG_DATE $LINK_PTR
+ fi
fi
# Define text colors
Dear
My name is Mohamed Abdul I have the capacity to inject a considerable
amount of capital in any viable project
1,cell phone number what-sap
2,full name
yours truly
Mohamed Abdul Ahmed
Hi all:
The core frequency is subjected to the process variation in semiconductors.
Not all cores are able to reach the maximum frequency respecting the
infrastructure limits. Consequently, AMD has redefined the concept of
maximum frequency of a part. This means that a fraction of cores can reach
maximum frequency. To find the best process scheduling policy for a given
scenario, OS needs to know the core ordering informed by the platform through
highest performance capability register of the CPPC interface.
Earlier implementations of amd-pstate preferred core only support a static
core ranking and targeted performance. Now it has the ability to dynamically
change the preferred core based on the workload and platform conditions and
accounting for thermals and aging.
Amd-pstate driver utilizes the functions and data structures provided by
the ITMT architecture to enable the scheduler to favor scheduling on cores
which can be get a higher frequency with lower voltage.
We call it amd-pstate preferred core.
Here sched_set_itmt_core_prio() is called to set priorities and
sched_set_itmt_support() is called to enable ITMT feature.
Amd-pstate driver uses the highest performance value to indicate
the priority of CPU. The higher value has a higher priority.
Amd-pstate driver will provide an initial core ordering at boot time.
It relies on the CPPC interface to communicate the core ranking to the
operating system and scheduler to make sure that OS is choosing the cores
with highest performance firstly for scheduling the process. When amd-pstate
driver receives a message with the highest performance change, it will
update the core ranking.
Changes form V4->V5:
- cpufreq: amd-pstate:
- - modify sysfs attribute for CPPC highest perf.
- - modify warning about comments
- - rebase linux-next
- cpufreq:
- - Moidfy warning about function declarations.
- Documentation: amd-pstate:
- - align with ``amd-pstat``
Changes form V3->V4:
- Documentation: amd-pstate:
- - Modify inappropriate descriptions.
Changes form V2->V3:
- x86:
- - Modify kconfig and description.
- cpufreq: amd-pstate:
- - Add Co-developed-by tag in commit message.
- cpufreq:
- - Modify commit message.
- Documentation: amd-pstate:
- - Modify inappropriate descriptions.
Changes form V1->V2:
- acpi: cppc:
- - Add reference link.
- cpufreq:
- - Moidfy link error.
- cpufreq: amd-pstate:
- - Init the priorities of all online CPUs
- - Use a single variable to represent the status of preferred core.
- Documentation:
- - Default enabled preferred core.
- Documentation: amd-pstate:
- - Modify inappropriate descriptions.
- - Default enabled preferred core.
- - Use a single variable to represent the status of preferred core.
Meng Li (7):
x86: Drop CPU_SUP_INTEL from SCHED_MC_PRIO for the expansion.
acpi: cppc: Add get the highest performance cppc control
cpufreq: amd-pstate: Enable amd-pstate preferred core supporting.
cpufreq: Add a notification message that the highest perf has changed
cpufreq: amd-pstate: Update amd-pstate preferred core ranking
dynamically
Documentation: amd-pstate: introduce amd-pstate preferred core
Documentation: introduce amd-pstate preferrd core mode kernel command
line options
.../admin-guide/kernel-parameters.txt | 5 +
Documentation/admin-guide/pm/amd-pstate.rst | 68 ++++++-
arch/x86/Kconfig | 5 +-
drivers/acpi/cppc_acpi.c | 13 ++
drivers/acpi/processor_driver.c | 6 +
drivers/cpufreq/amd-pstate.c | 167 ++++++++++++++++--
drivers/cpufreq/cpufreq.c | 13 ++
include/acpi/cppc_acpi.h | 5 +
include/linux/amd-pstate.h | 11 ++
include/linux/cpufreq.h | 5 +
10 files changed, 277 insertions(+), 21 deletions(-)
--
2.34.1
Starting with v197, systemd uses predictable interface network names,
the traditional interface naming scheme (eth0) is deprecated, therefore
it cannot be assumed that the eth0 interface exists on the host.
This modification makes the bind_bhash test program run in a separate
network namespace and no longer needs to consider the name of the
network interface on the host.
Signed-off-by: Juntong Deng <juntong.deng(a)outlook.com>
---
tools/testing/selftests/net/bind_bhash.sh | 26 ++++++++++++-----------
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/tools/testing/selftests/net/bind_bhash.sh b/tools/testing/selftests/net/bind_bhash.sh
index ca0292d4b441..a28563bdaae0 100755
--- a/tools/testing/selftests/net/bind_bhash.sh
+++ b/tools/testing/selftests/net/bind_bhash.sh
@@ -2,7 +2,7 @@
# SPDX-License-Identifier: GPL-2.0
NR_FILES=32768
-SAVED_NR_FILES=$(ulimit -n)
+readonly NETNS="ns-$(mktemp -u XXXXXX)"
# default values
port=443
@@ -36,21 +36,21 @@ while getopts "ha:p:64" opt; do
done
setup() {
+ ip netns add "${NETNS}"
+ ip -netns "${NETNS}" link add veth0 type veth peer name veth1
+ ip -netns "${NETNS}" link set lo up
+ ip -netns "${NETNS}" link set veth0 up
+ ip -netns "${NETNS}" link set veth1 up
+
if [[ "$use_v6" == true ]]; then
- ip addr add $addr_v6 nodad dev eth0
+ ip -netns "${NETNS}" addr add $addr_v6 nodad dev veth0
else
- ip addr add $addr_v4 dev lo
+ ip -netns "${NETNS}" addr add $addr_v4 dev lo
fi
- ulimit -n $NR_FILES
}
cleanup() {
- if [[ "$use_v6" == true ]]; then
- ip addr del $addr_v6 dev eth0
- else
- ip addr del $addr_v4/32 dev lo
- fi
- ulimit -n $SAVED_NR_FILES
+ ip netns del "${NETNS}"
}
if [[ "$addr" != "" ]]; then
@@ -59,8 +59,10 @@ if [[ "$addr" != "" ]]; then
fi
setup
if [[ "$use_v6" == true ]] ; then
- ./bind_bhash $port "ipv6" $addr_v6
+ ip netns exec "${NETNS}" sh -c \
+ "ulimit -n ${NR_FILES};./bind_bhash ${port} ipv6 ${addr_v6}"
else
- ./bind_bhash $port "ipv4" $addr_v4
+ ip netns exec "${NETNS}" sh -c \
+ "ulimit -n ${NR_FILES};./bind_bhash ${port} ipv4 ${addr_v4}"
fi
cleanup
--
2.39.2
Hi Jens, Christoph, Al,
Here are two patches to add some kunit tests for the iov_iter stuff and a
patch to fix a couple of bugs found by these tests.
It's by no means comprehensive, but it does at least test the basic
copy_to_iter(), copy_from_iter() and iov_iter_extract_pages() for
ITER_KVEC, ITER_BVEC and ITER_XARRAY.
I've left ITER_UBUF and ITER_IOVEC untested for now as they require
userspace VM interaction and I'm not sure if that's possible under kunit
tests. I've also left ITER_DISCARD for the moment as that does nothing and
can't be extracted.
The kunit tests should also perhaps be using folios rather than pages, but
for the moment I'm using pages because I'm using vmap() and also
iov_iter_extract_pages() doesn't yet have a folio equivalent.
I've pushed the patches here also:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?…
David
David Howells (3):
iov_iter: Fix iov_iter_extract_pages()
iov_iter: Kunit tests for copying to/from an iterator
iov_iter: Kunit tests for page extraction
lib/Kconfig.debug | 11 +
lib/Makefile | 1 +
lib/iov_iter.c | 30 +-
lib/kunit_iov_iter.c | 777 +++++++++++++++++++++++++++++++++++++++++++
4 files changed, 804 insertions(+), 15 deletions(-)
create mode 100644 lib/kunit_iov_iter.c
DAMON checks the access to each region for every sampling interval, increase
the counter of the region, namely nr_accesses if the access was made, and reset
the counter for every aggregation interval. The counter is exposed to users to
be used as a metric showing the access rate (frequency) of each region. In
other words, DAMON provides access rate of each region in every aggregation
interval. The aggregation avoids temporal access pattern changes make things
confusing. However, this also makes many DAMON-based operations to need to be
aligned to the aggregation interval. This can restrict the flexibility and
speed of DAMON applications, especially when the aggregation interval is huge.
To provide the monitoring results in finer-grained timing with handling of
temporal access pattern change, this patchset implements a pseudo-moving sum
based access rate metric. It is pseudo-moving sum because strict moving sum
implementation would need to keep every last time window values, and that could
incur high overhead. Especially in case of the nr_accesses, since the sampling
interval and aggregation interval can arbitrarily set and the past values
should be maintained for every region, it could be risky. The pseudo-moving
sum assumes there were no temporal access pattern change in last discrete time
window to remove the needs for keeping the list of the last time window values.
As a result, it beocmes not strict moving sum implementation, but provides a
reasonable accuracy.
Also, it keeps a property of the moving sum. That is, the moving sum becomes
same to discrete-window based sum at the time that aligns to the time window.
Hence, using the pseudo moving sum based nr_accesses makes no change to users
who collect the value for every aggregation interval.
SeongJae Park (8):
mm/damon/core: define and use a dedicated function for region access
rate update
mm/damon/vaddr: call damon_update_region_access_rate() always
mm/damon/core: implement a pseudo-moving sum function
mm/damon/core-test: add a unit test for damon_moving_sum()
mm/damon/core: introduce nr_accesses_bp
mm/damon/core: use pseudo-moving sum for nr_accesses_bp
mm/damon/core: skip updating nr_accesses_bp for each aggregation
interval
mm/damon/core: mark damon_moving_sum() as a static function
include/linux/damon.h | 16 +++++++++-
mm/damon/core-test.h | 21 ++++++++++++
mm/damon/core.c | 74 +++++++++++++++++++++++++++++++++++++++++++
mm/damon/paddr.c | 11 +++----
mm/damon/vaddr.c | 22 +++++++------
5 files changed, 128 insertions(+), 16 deletions(-)
base-commit: 85bb49ddd3983b85ab98ad50a69ca1c7380fc63a
--
2.25.1
From: Rong Tao <rongtao(a)cestc.cn>
We need to optimize the kallsyms cache, including optimizations for the
number of symbols limit, and, some test cases add new kernel symbols
(such as testmods) and we need to refresh kallsyms (reload or refresh).
Rong Tao (2):
selftests/bpf: trace_helpers.c: optimize kallsyms cache
selftests/bpf: trace_helpers.c: Add a global ksyms initialization
mutex
samples/bpf/Makefile | 4 +
.../selftests/bpf/prog_tests/fill_link_info.c | 2 +-
.../prog_tests/kprobe_multi_testmod_test.c | 20 ++-
tools/testing/selftests/bpf/trace_helpers.c | 134 +++++++++++++-----
tools/testing/selftests/bpf/trace_helpers.h | 8 +-
5 files changed, 122 insertions(+), 46 deletions(-)
--
2.41.0
This change introduces a way to check if an fd points to a memfd's
original open fd (the one created by memfd_create).
We encountered an issue with migrating memfds in CRIU (checkpoint
restore in userspace - it migrates running processes between
machines). Imagine a scenario:
1. Create a memfd. By default it's open with O_RDWR and yet one can
exec() to it (unlike with regular files, where one would get ETXTBSY).
2. Reopen that memfd with O_RDWR via /proc/self/fd/<fd>.
Now those 2 fds are indistinguishable from userspace. You can't exec()
to either of them (since the reopen incremented inode->i_writecount)
and their /proc/self/fdinfo/ are exactly the same. Unfortunately they
are not the same. If you close the second one, the first one becomes
exec()able again. If you close the first one, the other doesn't become
exec()able. Therefore during migration it does matter which is recreated
first and which is reopened but there is no way for CRIU to tell which
was first.
---
Changes since v1 at [1]:
- Rewrote it from fcntl to ioctl. This was requested by filesystems
maintainer.
Links:
[1] https://lore.kernel.org/all/20230831203647.558079-1-mclapinski@google.com/
Michal Clapinski (2):
mm/memfd: add ioctl(MEMFD_CHECK_IF_ORIGINAL)
selftests: test ioctl(MEMFD_CHECK_IF_ORIGINAL)
.../userspace-api/ioctl/ioctl-number.rst | 1 +
fs/hugetlbfs/inode.c | 9 ++++++
include/linux/memfd.h | 12 +++++++
mm/memfd.c | 9 ++++++
mm/shmem.c | 9 ++++++
tools/testing/selftests/memfd/memfd_test.c | 32 +++++++++++++++++++
6 files changed, 72 insertions(+)
--
2.42.0.283.g2d96d420d3-goog
From: Zhangjin Wu <falcon(a)tinylab.org>
[ Upstream commit c388c9920da2679f62bec48d00ca9e80e9d0a364 ]
kernel parameters allow pass two types of strings, one type is like
'noapic', another type is like 'panic=5', the first type is passed as
arguments of the init program, the second type is passed as environment
variables of the init program.
when users pass kernel parameters like this:
noapic NOLIBC_TEST=syscall
our nolibc-test program will use the test setting from argv[1] and
ignore the one from NOLIBC_TEST environment variable, and at last, it
will print the following line and ignore the whole test setting.
Ignoring unknown test name 'noapic'
reversing the parsing order does solve the above issue:
test = getenv("NOLIBC_TEST");
if (test)
test = argv[1];
but it still doesn't work with such kernel parameters (without
NOLIBC_TEST environment variable):
noapic FOO=bar
To support all of the potential kernel parameters, let's verify the test
setting from both of argv[1] and NOLIBC_TEST environment variable.
Reviewed-by: Thomas Weißschuh <linux(a)weissschuh.net>
Signed-off-by: Zhangjin Wu <falcon(a)tinylab.org>
Signed-off-by: Willy Tarreau <w(a)1wt.eu>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/nolibc/nolibc-test.c | 33 ++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index 78bced95ac630..f8e8e8d2a5e18 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -630,6 +630,35 @@ static struct test test_names[] = {
{ 0 }
};
+int is_setting_valid(char *test)
+{
+ int idx, len, test_len, valid = 0;
+ char delimiter;
+
+ if (!test)
+ return valid;
+
+ test_len = strlen(test);
+
+ for (idx = 0; test_names[idx].name; idx++) {
+ len = strlen(test_names[idx].name);
+ if (test_len < len)
+ continue;
+
+ if (strncmp(test, test_names[idx].name, len) != 0)
+ continue;
+
+ delimiter = test[len];
+ if (delimiter != ':' && delimiter != ',' && delimiter != '\0')
+ continue;
+
+ valid = 1;
+ break;
+ }
+
+ return valid;
+}
+
int main(int argc, char **argv, char **envp)
{
int min = 0;
@@ -655,10 +684,10 @@ int main(int argc, char **argv, char **envp)
* syscall:5-15[:.*],stdlib:8-10
*/
test = argv[1];
- if (!test)
+ if (!is_setting_valid(test))
test = getenv("NOLIBC_TEST");
- if (test) {
+ if (is_setting_valid(test)) {
char *comma, *colon, *dash, *value;
do {
--
2.40.1
From: Zhangjin Wu <falcon(a)tinylab.org>
[ Upstream commit c388c9920da2679f62bec48d00ca9e80e9d0a364 ]
kernel parameters allow pass two types of strings, one type is like
'noapic', another type is like 'panic=5', the first type is passed as
arguments of the init program, the second type is passed as environment
variables of the init program.
when users pass kernel parameters like this:
noapic NOLIBC_TEST=syscall
our nolibc-test program will use the test setting from argv[1] and
ignore the one from NOLIBC_TEST environment variable, and at last, it
will print the following line and ignore the whole test setting.
Ignoring unknown test name 'noapic'
reversing the parsing order does solve the above issue:
test = getenv("NOLIBC_TEST");
if (test)
test = argv[1];
but it still doesn't work with such kernel parameters (without
NOLIBC_TEST environment variable):
noapic FOO=bar
To support all of the potential kernel parameters, let's verify the test
setting from both of argv[1] and NOLIBC_TEST environment variable.
Reviewed-by: Thomas Weißschuh <linux(a)weissschuh.net>
Signed-off-by: Zhangjin Wu <falcon(a)tinylab.org>
Signed-off-by: Willy Tarreau <w(a)1wt.eu>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/nolibc/nolibc-test.c | 33 ++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index d37d036876ea9..041f5d16a9d87 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -782,6 +782,35 @@ static const struct test test_names[] = {
{ 0 }
};
+int is_setting_valid(char *test)
+{
+ int idx, len, test_len, valid = 0;
+ char delimiter;
+
+ if (!test)
+ return valid;
+
+ test_len = strlen(test);
+
+ for (idx = 0; test_names[idx].name; idx++) {
+ len = strlen(test_names[idx].name);
+ if (test_len < len)
+ continue;
+
+ if (strncmp(test, test_names[idx].name, len) != 0)
+ continue;
+
+ delimiter = test[len];
+ if (delimiter != ':' && delimiter != ',' && delimiter != '\0')
+ continue;
+
+ valid = 1;
+ break;
+ }
+
+ return valid;
+}
+
int main(int argc, char **argv, char **envp)
{
int min = 0;
@@ -807,10 +836,10 @@ int main(int argc, char **argv, char **envp)
* syscall:5-15[:.*],stdlib:8-10
*/
test = argv[1];
- if (!test)
+ if (!is_setting_valid(test))
test = getenv("NOLIBC_TEST");
- if (test) {
+ if (is_setting_valid(test)) {
char *comma, *colon, *dash, *value;
do {
--
2.40.1
From: Zhangjin Wu <falcon(a)tinylab.org>
[ Upstream commit c388c9920da2679f62bec48d00ca9e80e9d0a364 ]
kernel parameters allow pass two types of strings, one type is like
'noapic', another type is like 'panic=5', the first type is passed as
arguments of the init program, the second type is passed as environment
variables of the init program.
when users pass kernel parameters like this:
noapic NOLIBC_TEST=syscall
our nolibc-test program will use the test setting from argv[1] and
ignore the one from NOLIBC_TEST environment variable, and at last, it
will print the following line and ignore the whole test setting.
Ignoring unknown test name 'noapic'
reversing the parsing order does solve the above issue:
test = getenv("NOLIBC_TEST");
if (test)
test = argv[1];
but it still doesn't work with such kernel parameters (without
NOLIBC_TEST environment variable):
noapic FOO=bar
To support all of the potential kernel parameters, let's verify the test
setting from both of argv[1] and NOLIBC_TEST environment variable.
Reviewed-by: Thomas Weißschuh <linux(a)weissschuh.net>
Signed-off-by: Zhangjin Wu <falcon(a)tinylab.org>
Signed-off-by: Willy Tarreau <w(a)1wt.eu>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/nolibc/nolibc-test.c | 33 ++++++++++++++++++--
1 file changed, 31 insertions(+), 2 deletions(-)
diff --git a/tools/testing/selftests/nolibc/nolibc-test.c b/tools/testing/selftests/nolibc/nolibc-test.c
index 486334981e601..55628a25df0a3 100644
--- a/tools/testing/selftests/nolibc/nolibc-test.c
+++ b/tools/testing/selftests/nolibc/nolibc-test.c
@@ -939,6 +939,35 @@ static const struct test test_names[] = {
{ 0 }
};
+int is_setting_valid(char *test)
+{
+ int idx, len, test_len, valid = 0;
+ char delimiter;
+
+ if (!test)
+ return valid;
+
+ test_len = strlen(test);
+
+ for (idx = 0; test_names[idx].name; idx++) {
+ len = strlen(test_names[idx].name);
+ if (test_len < len)
+ continue;
+
+ if (strncmp(test, test_names[idx].name, len) != 0)
+ continue;
+
+ delimiter = test[len];
+ if (delimiter != ':' && delimiter != ',' && delimiter != '\0')
+ continue;
+
+ valid = 1;
+ break;
+ }
+
+ return valid;
+}
+
int main(int argc, char **argv, char **envp)
{
int min = 0;
@@ -964,10 +993,10 @@ int main(int argc, char **argv, char **envp)
* syscall:5-15[:.*],stdlib:8-10
*/
test = argv[1];
- if (!test)
+ if (!is_setting_valid(test))
test = getenv("NOLIBC_TEST");
- if (test) {
+ if (is_setting_valid(test)) {
char *comma, *colon, *dash, *value;
do {
--
2.40.1
Currently console.log.diags contains an output like follows:
[ 2457.293734] WARNING: CPU: 2 PID: 13 at kernel/rcu/tasks.h:1061 rcu_tasks_trace_pregp_step+0x4a/0x50
[ 2457.542385] Call Trace:
This is not very useful and easier access to the call trace is desired.
Improve the script by extracting more lines after each grep match.
Provide a summary in the beginning like before, but also include details
below. Limit the total number of issues to a maximum of 10. And limit
the lines included after each issue to a maximum of 20.
With these changes the output becomes:
Issues found:
Line 6228: [ 2457.293734] WARNING: CPU: 2 PID: 13 at kernel/rcu/tasks.h:1061 rcu_tasks_trace_pregp_step+0x4a/0x50
Line 6245: [ 2457.542385] Call Trace:
Details of each issue:
Issue 1 (line 6228):
[ 2457.293734] WARNING: CPU: 2 PID: 13 at kernel/rcu/tasks.h:1061 rcu_tasks_trace_pregp_step+0x4a/0x50
[ 2457.326661] Modules linked in:
[ 2457.334818] CPU: 2 PID: 13 Comm: rcu_tasks_trace Not tainted 5.15.128+ #381
[ 2457.349782] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
[ 2457.373309] RIP: 0010:rcu_tasks_trace_pregp_step+0x4a/0x50
[...]
[ 2457.421803] RSP: 0018:ffffa80fc0073e40 EFLAGS: 00010202
[ 2457.431940] RAX: ffff8db91f580000 RBX: 000000000001b900 RCX: 0000000000000003
[ 2457.443206] RDX: 0000000000000008 RSI: ffffffffac6bebd8 RDI: 0000000000000003
[ 2457.454428] RBP: 0000000000000004 R08: 0000000000000001 R09: 0000000000000001
[ 2457.465668] R10: 0000000000000000 R11: 00000000ffffffff R12: ffff8db902d87f40
[ 2457.476971] R13: ffffffffac556620 R14: ffffffffac556630 R15: ffff8db9011a3200
[ 2457.488251] FS: 0000000000000000(0000) GS:ffff8db91f500000(0000) knlGS:0000000000000000
[ 2457.500834] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2457.509602] CR2: 0000000000000000 CR3: 0000000002cbc000 CR4: 00000000000006e0
[ 2457.520378] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2457.531440] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2457.542385] Call Trace:
[ 2457.546756] <TASK>
[ 2457.550349] ? __warn+0x7b/0x100
[ 2457.567214] ? rcu_tasks_trace_pregp_step+0x4a/0x50
-------------------------------------
Issue 2 (line 6245):
[ 2457.542385] Call Trace:
[ 2457.546756] <TASK>
[ 2457.550349] ? __warn+0x7b/0x100
[ 2457.567214] ? rcu_tasks_trace_pregp_step+0x4a/0x50
[ 2457.574948] ? report_bug+0x99/0xc0
[ 2457.593824] ? handle_bug+0x3c/0x70
[ 2457.599534] ? exc_invalid_op+0x13/0x60
[ 2457.625729] ? asm_exc_invalid_op+0x16/0x20
[ 2457.632249] ? rcu_tasks_trace_pregp_step+0x4a/0x50
[ 2457.660010] rcu_tasks_wait_gp+0x54/0x360
[ 2457.677761] ? _raw_spin_unlock_irqrestore+0x2b/0x60
[ 2457.705658] rcu_tasks_kthread+0x114/0x200
[ 2457.712450] ? wait_woken+0x70/0x70
[ 2457.727283] ? synchronize_rcu_tasks_rude+0x10/0x10
[ 2457.746221] kthread+0x130/0x160
[ 2457.751487] ? set_kthread_struct+0x40/0x40
[ 2457.758178] ret_from_fork+0x22/0x30
[ 2457.763909] </TASK>
[ 2457.767546] irq event stamp: 29544441
[ 2457.773344] hardirqs last enabled at (29544451): [<ffffffffaace6cbd>] __up_console_sem+0x4d/0x60
[ 2457.786967] hardirqs last disabled at (29544460): [<ffffffffaace6ca2>] __up_console_sem+0x32/0x60
Signed-off-by: Joel Fernandes (Google) <joel(a)joelfernandes.org>
---
v1->v2: Limit number of issues reported and include summary on the top.
.../rcutorture/bin/console-badness.sh | 42 ++++++++++++++++++-
1 file changed, 41 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rcutorture/bin/console-badness.sh b/tools/testing/selftests/rcutorture/bin/console-badness.sh
index aad51e7c0183..2612a4931723 100755
--- a/tools/testing/selftests/rcutorture/bin/console-badness.sh
+++ b/tools/testing/selftests/rcutorture/bin/console-badness.sh
@@ -9,10 +9,50 @@
# Copyright (C) 2020 Facebook, Inc.
#
# Authors: Paul E. McKenney <paulmck(a)kernel.org>
+INPUT_DATA=$(< /dev/stdin)
+MAX_NR_ISSUES=10
-grep -E 'Badness|WARNING:|Warn|BUG|===========|BUG: KCSAN:|Call Trace:|Oops:|detected stalls on CPUs/tasks:|self-detected stall on CPU|Stall ended before state dump start|\?\?\? Writer stall state|rcu_.*kthread starved for|!!!' |
+# Get the line numbers for all the grep matches
+GREP_LINES="$(echo "$INPUT_DATA" |
+grep -n -E 'Badness|WARNING:|Warn|BUG|===========|BUG: KCSAN:|Call Trace:|Oops:|detected stalls on CPUs/tasks:|self-detected stall on CPU|Stall ended before state dump start|\?\?\? Writer stall state|rcu_.*kthread starved for|!!!' |
grep -v 'ODEBUG: ' |
grep -v 'This means that this is a DEBUG kernel and it is' |
grep -v 'Warning: unable to open an initial console' |
grep -v 'Warning: Failed to add ttynull console. No stdin, stdout, and stderr.*the init process!' |
grep -v 'NOHZ tick-stop error: Non-RCU local softirq work is pending, handler'
+)"
+
+# Exit if no grep matches
+if [ ! -n "$GREP_LINES" ]; then exit 0; fi
+
+# Print first MAX_NR_ISSUES grepped lines
+echo "Issues found:"
+issue_num=1
+while IFS= read -r line; do
+ # Extract the line number from the line
+ num=$(echo "$line" | awk -F: '{print $1}')
+ # Extract the rest of the line
+ line_rest=$(echo "$line" | cut -d: -f2-)
+ echo "Line $num: $line_rest"
+ if [ "$issue_num" -eq "$MAX_NR_ISSUES" ]; then break; fi
+ issue_num="$(($issue_num + 1))"
+done <<< "$GREP_LINES"
+echo ""
+
+# Print details of each issue
+#
+# Go through each line of GREP_LINES, extract the line number and then
+# print from that line and 20 lines after that line. Do that for each
+# grep match upto MAX_NR_ISSUES of them.
+echo "Details of each issue:"
+issue_num=1
+while IFS= read -r line; do
+ # Extract the line number from the line
+ num=$(echo "$line" | awk -F: '{print $1}')
+ # Print 20 lines after the matched line
+ echo "Issue $issue_num (line $num):"
+ echo "$INPUT_DATA" | sed -n "${num},$(($num + 20))p"
+ echo "-------------------------------------"
+ if [ "$issue_num" -eq "$MAX_NR_ISSUES" ]; then break; fi
+ issue_num="$(($issue_num + 1))"
+done <<< "$GREP_LINES"
--
2.42.0.283.g2d96d420d3-goog
Events Tracing infrastructure contains lot of files, directories
(internally in terms of inodes, dentries). And ends up by consuming
memory in MBs. We can have multiple events of Events Tracing, which
further requires more memory.
Instead of creating inodes/dentries, eventfs could keep meta-data and
skip the creation of inodes/dentries. As and when require, eventfs will
create the inodes/dentries only for required files/directories.
Also eventfs would delete the inodes/dentries once no more requires
but preserve the meta data.
Tracing events took ~9MB, with this approach it took ~4.5MB
for ~10K files/dir.
v3:
Patch 3,4,5,7,9:
removed all the eventfs_rwsem code and replaced it with an srcu
lock for the readers, and a mutex to synchronize the writers of
the list.
Patch 2: moved 'tracefs_inode' and 'get_tracefs()' to v4 03/10
Patch 3: moved the struct eventfs_file and eventfs_inode into event_inode.c
as it really should not be exposed to all users.
Patch 5: added a recursion check to eventfs_remove_rec() as it is really
dangerous to have unchecked recursion in the kernel (we do have
a fixed size stack).
have the free use srcu callbacks. After the srcu grace periods
are done, it adds the eventfs_file onto a llist (lockless link
list) and wakes up a work queue. Then the work queue does the
freeing (this needs to be done in task/workqueue context, as
srcu callbacks are done in softirq context).
Patch 6: renamed:
eventfs_create_file() -> create_file()
eventfs_create_dir() -> create_dir()
v2:
Patch 01: new patch:'Require all trace events to have a TRACE_SYSTEM'
Patch 02: moved from v1 1/9
Patch 03: moved from v1 2/9
As suggested by Zheng Yejian, introduced eventfs_prepare_ef()
helper function to add files or directories to eventfs
fix WARNING reported by kernel test robot in v1 8/9
Patch 04: moved from v1 3/9
used eventfs_prepare_ef() to add files
fix WARNING reported by kernel test robot in v1 8/9
Patch 05: moved from v1 4/9
fix compiling warning reported by kernel test robot in v1 4/9
Patch 06: moved from v1 5/9
Patch 07: moved from v1 6/9
Patch 08: moved from v1 7/9
Patch 09: moved from v1 8/9
rebased because of v3 01/10
Patch 10: moved from v1 9/9
v1:
Patch 1: add header file
Patch 2: resolved kernel test robot issues
protecting eventfs lists using nested eventfs_rwsem
Patch 3: protecting eventfs lists using nested eventfs_rwsem
Patch 4: improve events cleanup code to fix crashes
Patch 5: resolved kernel test robot issues
removed d_instantiate_anon() calls
Patch 6: resolved kernel test robot issues
fix kprobe test in eventfs_root_lookup()
protecting eventfs lists using nested eventfs_rwsem
Patch 7: remove header file
Patch 8: pass eventfs_rwsem as argument to eventfs functions
called eventfs_remove_events_dir() instead of tracefs_remove()
from event_trace_del_tracer()
Patch 9: new patch to fix kprobe test case
Ajay Kaher (9):
tracefs: Rename some tracefs function
eventfs: Implement eventfs dir creation functions
eventfs: Implement eventfs file add functions
eventfs: Implement eventfs file, directory remove function
eventfs: Implement functions to create eventfs files and directories
eventfs: Implement eventfs lookup, read, open functions
eventfs: Implement tracefs_inode_cache
eventfs: Move tracing/events to eventfs
test: ftrace: Fix kprobe test for eventfs
Steven Rostedt (Google) (1):
tracing: Require all trace events to have a TRACE_SYSTEM
fs/tracefs/Makefile | 1 +
fs/tracefs/event_inode.c | 711 ++++++++++++++++++
fs/tracefs/inode.c | 124 ++-
fs/tracefs/internal.h | 25 +
include/linux/trace_events.h | 1 +
include/linux/tracefs.h | 32 +
kernel/trace/trace.h | 2 +-
kernel/trace/trace_events.c | 78 +-
.../ftrace/test.d/kprobe/kprobe_args_char.tc | 4 +-
.../test.d/kprobe/kprobe_args_string.tc | 4 +-
10 files changed, 930 insertions(+), 52 deletions(-)
create mode 100644 fs/tracefs/event_inode.c
create mode 100644 fs/tracefs/internal.h
--
2.39.0
'available_events' is actually not required by
'test.d/event/toplevel-enable.tc' and its Existence has been tested in
'test.d/00basic/basic4.tc'.
So the require of 'available_events' can be dropped and then we can add
'instance' flag to test 'test.d/event/toplevel-enable.tc' for instance.
Test result show as below:
# ./ftracetest test.d/event/toplevel-enable.tc
=== Ftrace unit tests ===
[1] event tracing - enable/disable with top level files [PASS]
[2] (instance) event tracing - enable/disable with top level files [PASS]
# of passed: 2
# of failed: 0
# of unresolved: 0
# of untested: 0
# of unsupported: 0
# of xfailed: 0
# of undefined(test bug): 0
Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com>
---
tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc b/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
index 93c10ea42a68..8b8e1aea985b 100644
--- a/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
+++ b/tools/testing/selftests/ftrace/test.d/event/toplevel-enable.tc
@@ -1,7 +1,8 @@
#!/bin/sh
# SPDX-License-Identifier: GPL-2.0
# description: event tracing - enable/disable with top level files
-# requires: available_events set_event events/enable
+# requires: set_event events/enable
+# flags: instance
do_reset() {
echo > set_event
--
2.25.1
Create the config file in user_events directory of testcase which
need more kernel configuration than the default defconfig. User
could use these configs with merge_config.sh script:
The Kconfig CONFIG_USER_EVENTS=y is needed for the test to read
data from the following files,
- "/sys/kernel/tracing/user_events_data"
- "/sys/kernel/tracing/user_events_status"
- "/sys/kernel/tracing/events/user_events/*"
Enable config for specific testcase:
(export ARCH=xxx #for cross compiling)
./scripts/kconfig/merge_config.sh .config \
tools/testing/selftests/user_events/config
Enable configs for all testcases:
(export ARCH=xxx #for cross compiling)
./scripts/kconfig/merge_config.sh .config \
tools/testing/selftests/*/config
Cc: Beau Belgrave <beaub(a)linux.microsoft.com>
Cc: Shuah Khan <skhan(a)linuxfoundation.org>
Cc: linux-kselftest(a)vger.kernel.org
Signed-off-by: Naresh Kamboju <naresh.kamboju(a)linaro.org>
---
tools/testing/selftests/user_events/config | 1 +
1 file changed, 1 insertion(+)
create mode 100644 tools/testing/selftests/user_events/config
diff --git a/tools/testing/selftests/user_events/config b/tools/testing/selftests/user_events/config
new file mode 100644
index 0000000000000..64f7a9a90cec4
--- /dev/null
+++ b/tools/testing/selftests/user_events/config
@@ -0,0 +1 @@
+CONFIG_USER_EVENTS=y
--
2.30.2
Function instance_set() expects to enable event 'sched_switch', so we
should set 1 to its 'enable' file.
Testcase passed after this patch:
# ./ftracetest test.d/instances/instance-event.tc
=== Ftrace unit tests ===
[1] Test creation and deletion of trace instances while setting an event
[PASS]
# of passed: 1
# of failed: 0
# of unresolved: 0
# of untested: 0
# of unsupported: 0
# of xfailed: 0
# of undefined(test bug): 0
Signed-off-by: Zheng Yejian <zhengyejian1(a)huawei.com>
---
.../testing/selftests/ftrace/test.d/instances/instance-event.tc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/ftrace/test.d/instances/instance-event.tc b/tools/testing/selftests/ftrace/test.d/instances/instance-event.tc
index 0eb47fbb3f44..42422e425107 100644
--- a/tools/testing/selftests/ftrace/test.d/instances/instance-event.tc
+++ b/tools/testing/selftests/ftrace/test.d/instances/instance-event.tc
@@ -39,7 +39,7 @@ instance_read() {
instance_set() {
while :; do
- echo 1 > foo/events/sched/sched_switch
+ echo 1 > foo/events/sched/sched_switch/enable
done 2> /dev/null
}
--
2.25.1
Hi Rae,
Em Thu, 13 Jul 2023 17:31:19 -0400
Rae Moar <rmoar(a)google.com> escreveu:
> On Wed, Jul 12, 2023 at 10:29 AM Mauro Carvalho Chehab <mchehab(a)kernel.org>
> wrote:
>
> > As an example for the new documentation tool, add a documentation
> > for drm_buddy_test.
> >
> > I opted to place this on a completely different directory, in order
> > to make easier to test the feature with:
> >
> > $ make SPHINXDIRS="tests" htmldocs
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org>
> > ---
> >
> > To avoid mailbombing on a large number of people, only mailing lists were
> > C/C on the cover.
> > See [PATCH RFC 0/2] at:
> > https://lore.kernel.org/all/cover.1689171160.git.mchehab@kernel.org/
> >
> > Documentation/index.rst | 2 +-
> > Documentation/tests/index.rst | 6 ++++++
> > Documentation/tests/kunit.rst | 5 +++++
> > drivers/gpu/drm/tests/drm_buddy_test.c | 12 ++++++++++++
> > 4 files changed, 24 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/tests/index.rst
> > create mode 100644 Documentation/tests/kunit.rst
> >
> > diff --git a/Documentation/index.rst b/Documentation/index.rst
> > index 9dfdc826618c..80a6ce14a61a 100644
> > --- a/Documentation/index.rst
> > +++ b/Documentation/index.rst
> > @@ -60,7 +60,7 @@ Various other manuals with useful information for all
> > kernel developers.
> > fault-injection/index
> > livepatch/index
> > rust/index
> > -
> > + test/index
> >
> > User-oriented documentation
> > ===========================
> > diff --git a/Documentation/tests/index.rst b/Documentation/tests/index.rst
> > new file mode 100644
> > index 000000000000..bfc39eb5c0aa
> > --- /dev/null
> > +++ b/Documentation/tests/index.rst
> > @@ -0,0 +1,6 @@
> > +========================
> > +Kunit documentation test
> > +========================
> > +
> > +.. toctree::
> > + kunit
> > diff --git a/Documentation/tests/kunit.rst b/Documentation/tests/kunit.rst
> > new file mode 100644
> > index 000000000000..6ffc151988a0
> > --- /dev/null
> > +++ b/Documentation/tests/kunit.rst
> > @@ -0,0 +1,5 @@
> > +Kunit tests
> > +-----------
> > +
> > +.. include-test:: drivers/gpu/drm/tests/drm_buddy_test.c
> > +
> > diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
> > b/drivers/gpu/drm/tests/drm_buddy_test.c
> > index 09ee6f6af896..dd6c5afd6cd6 100644
> > --- a/drivers/gpu/drm/tests/drm_buddy_test.c
> > +++ b/drivers/gpu/drm/tests/drm_buddy_test.c
> > @@ -737,6 +737,18 @@ static int drm_buddy_suite_init(struct kunit_suite
> > *suite)
> > return 0;
> > }
> >
> > +/**
> > + * KTEST_SUITE: set of tests for drm buddy alloc
> > + * Scope: drm subsystem
> > + * Mega feature: drm
> > + * Feature: buddy_alloc
> > + *
> > + * KTEST_TEST: drm_test_buddy_alloc_%s
> > + * Description: Run DRM buddy allocation %arg[1] test
> > + *
> > + * arg[1].values: limit, range, optimistic, smoke, pathological
> > + */
>
>
> Hi!
>
> This is such a cool patch series. I just have a few comments related to the
> output.
Thank you for your comments! Sorry for not answering earlier. I took some
vacations and this series ended sleeping over other tasks on my
todo list.
Also, before sending another version, I wanted to have the test_list.py
changes to make it generic enough to be merged on IGT, to avoid having
a fork of it. Those got merged today.
> In the html output the tests are listed as:
> ktest@drm_buddy_test@…
>
> I wonder if instead of using the file name of “drm_buddy_test” this could
> possibly be the suite name, “drm_buddy”, as this is what users will call
> when using kunit.py to run the tests. Although "drm_buddy_test" is also the
> module name so I don't mind it too much. But in the future the file name
> and module name are not guaranteed to be the same for other tests.
>
> Most preferably, there would be a reference to the kunit suite name, file
> name, and the module name.
I guess it shouldn't be hard to do such change in a way that it won't
affect its usage on IGT. We need to define what would be the best
pattern. As this can be used for both kunit and selftests, I would
place kunit at the beginning.
Currently, we're using:
kunit@<base file name without .c>@<test_name>
Some possible patterns would be:
kunit@<base file name without .c>@<suite name>@<test_name>
kunit@<subsystem>@<base file name without .c>@<suite name>@<test_name>
kunit@<subsystem>@<suite name>@<test_name>
Would do you think it would work best?
> This may be difficult to implement as these can all differ. I am currently
> working on the KUnit Attribute framework which saves the module name and I
> am thinking about also saving the file path as a future attribute. This
> could be a helpful framework for the KUnit tests specifically.
>
> I am not sure how easy it would be to access c objects/functions using this
> system.
I would prefer not. C language allows lots of flexibility with macros,
making it hard to write a parser to read those C objects from the source.
We have this at kernel-doc. As one of the people that did some work there,
I can say that that several tricks are needed to keep this working.
On the other hand, it should be easy to use the TestList class from
test_list.py at kunit.py.
So, kunit.py could use the data that came from the documentation
directly.
> Finally, I was wondering if it is the intention to put a list of all kunit
> tests that use this new feature into tests/kunit.rst or would this be
> broken up in some way
IMO, it makes sense to break this per subsystem, and have an auto-generated
index.rst pointing to the entire set of documents.
We're already storing the subsystem at the documentation macros, so, IMO,
it should shouldn't be hard to implement it.
Regards,
Mauro
On Wed, Sep 06, 2023 at 08:39:22AM -0700, Beau Belgrave wrote:
> What is the expected behavior of self tests if run without their
> feature enabled? Is it expected these should skip vs fail in that case?
Yes, tests should skip if preconditions for running them aren't met.
On Tue, Sep 05, 2023 at 03:42:58PM +0200, Thomas Hellström wrote:
> Hi, Maxime
>
> On 9/5/23 15:16, Maxime Ripard wrote:
> > On Tue, Sep 05, 2023 at 02:32:38PM +0200, Thomas Hellström wrote:
> > > Hi,
> > >
> > > On 9/5/23 14:05, Maxime Ripard wrote:
> > > > Hi,
> > > >
> > > > On Tue, Sep 05, 2023 at 10:58:31AM +0200, Thomas Hellström wrote:
> > > > > Check that object freeing from within drm_exec_fini() works as expected
> > > > > and doesn't generate any warnings.
> > > > >
> > > > > Cc: Christian König <christian.koenig(a)amd.com>
> > > > > Cc: dri-devel(a)lists.freedesktop.org
> > > > > Signed-off-by: Thomas Hellström <thomas.hellstrom(a)linux.intel.com>
> > > > > ---
> > > > > drivers/gpu/drm/tests/drm_exec_test.c | 47 +++++++++++++++++++++++++++
> > > > > 1 file changed, 47 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/tests/drm_exec_test.c b/drivers/gpu/drm/tests/drm_exec_test.c
> > > > > index 563949d777dd..294c25f49cc7 100644
> > > > > --- a/drivers/gpu/drm/tests/drm_exec_test.c
> > > > > +++ b/drivers/gpu/drm/tests/drm_exec_test.c
> > > > > @@ -170,6 +170,52 @@ static void test_prepare_array(struct kunit *test)
> > > > > drm_gem_private_object_fini(&gobj2);
> > > > > }
> > > > > +static const struct drm_gem_object_funcs put_funcs = {
> > > > > + .free = (void *)kfree,
> > > > > +};
> > > > > +
> > > > > +/*
> > > > > + * Check that freeing objects from within drm_exec_fini()
> > > > > + * behaves as expected.
> > > > > + */
> > > > > +static void test_early_put(struct kunit *test)
> > > > > +{
> > > > > + struct drm_exec_priv *priv = test->priv;
> > > > > + struct drm_gem_object *gobj1;
> > > > > + struct drm_gem_object *gobj2;
> > > > > + struct drm_gem_object *array[2];
> > > > > + struct drm_exec exec;
> > > > > + int ret;
> > > > > +
> > > > > + gobj1 = kzalloc(sizeof(*gobj1), GFP_KERNEL);
> > > > > + KUNIT_EXPECT_NOT_ERR_OR_NULL(test, gobj1);
> > > > > + if (!gobj1)
> > > > > + return;
> > > > > +
> > > > > + gobj2 = kzalloc(sizeof(*gobj2), GFP_KERNEL);
> > > > > + KUNIT_EXPECT_NOT_ERR_OR_NULL(test, gobj2);
> > > > > + if (!gobj2) {
> > > > > + kfree(gobj1);
> > > > > + return;
> > > > > + }
> > > > > +
> > > > > + gobj1->funcs = &put_funcs;
> > > > > + gobj2->funcs = &put_funcs;
> > > > > + array[0] = gobj1;
> > > > > + array[1] = gobj2;
> > > > > + drm_gem_private_object_init(priv->drm, gobj1, PAGE_SIZE);
> > > > > + drm_gem_private_object_init(priv->drm, gobj2, PAGE_SIZE);
> > > > > +
> > > > > + drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
> > > > > + drm_exec_until_all_locked(&exec)
> > > > > + ret = drm_exec_prepare_array(&exec, array, ARRAY_SIZE(array),
> > > > > + 1);
> > > > > + KUNIT_EXPECT_EQ(test, ret, 0);
> > > > > + drm_gem_object_put(gobj1);
> > > > > + drm_gem_object_put(gobj2);
> > > > > + drm_exec_fini(&exec);
> > > > It doesn't look like you actually check that "freeing objects from
> > > > within drm_exec_fini() behaves as expected." What is the expectation
> > > > here, and how is it checked?
> > > Hm. Good question, I've been manually checking dmesg for lockdep splats. Is
> > > there a way to automate that?
> > I'm not familiar with the drm_exec API, but judging by the code I'd
> > assume you want to check that gobj1 and gobj2 are actually freed using
> > kfree?
>
> Actually not. What's important here is that the call to drm_exec_fini(),
> which puts the last references to gobj1 and gobj2 doesn't trigger any
> lockdep splats, like the one in the commit message of patch 3/3. So to make
> more sense, the test could perhaps be conditioned on
> CONFIG_DEBUG_LOCK_ALLOC. Still it would require manual checking of dmesg()
> after being run.
I'm not aware of something to check on lockdep's status when running a
kunit test, but I'm not sure anyone is expected to look at the dmesg
trace when running kunit to find out whether the test succeeded or not.
It looks like there was an attempt at some point to fail the test if
there was a lockdep error:
https://lore.kernel.org/all/20200814205527.1833459-1-urielguajardojr@gmail.…
It doesn't look like it's been merged though. David, Brendan, do you
know why it wasn't merged or if there is a good option for us there?
At the very least, I think a comment after the call to drm_exec_fini to
make it clear that the error would be in the kernel logs, and a better
one on the test definition to explicitly say what you want to make sure
of, and how one can check it's been done would be great.
Maxime