* [PATCH v7 3/5] kunit: Add backtrace suppression self-tests
From: Albert Esteve @ 2026-04-20 12:28 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter,
Alessandro Carminati, Albert Esteve, Kees Cook
In-Reply-To: <20260420-kunit_add_support-v7-0-e8bc6e0f70de@redhat.com>
From: Guenter Roeck <linux@roeck-us.net>
Add unit tests to verify that warning backtrace suppression works,
covering WARN() and WARN_ON() with direct calls, indirect calls
through helper functions, and multiple warnings in a single window.
If backtrace suppression does _not_ work, the unit tests will likely
trigger unsuppressed backtraces, which should actually help to get
the affected architectures / platforms fixed.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
lib/kunit/Makefile | 3 ++
lib/kunit/backtrace-suppression-test.c | 90 ++++++++++++++++++++++++++++++++++
2 files changed, 93 insertions(+)
diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
index fe177ff3ebdef..b2f2b8ada7b71 100644
--- a/lib/kunit/Makefile
+++ b/lib/kunit/Makefile
@@ -23,6 +23,9 @@ obj-$(if $(CONFIG_KUNIT),y) += hooks.o \
obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
obj-$(CONFIG_KUNIT_TEST) += platform-test.o
+ifeq ($(CONFIG_KUNIT_SUPPRESS_BACKTRACE),y)
+obj-$(CONFIG_KUNIT_TEST) += backtrace-suppression-test.o
+endif
# string-stream-test compiles built-in only.
ifeq ($(CONFIG_KUNIT_TEST),y)
diff --git a/lib/kunit/backtrace-suppression-test.c b/lib/kunit/backtrace-suppression-test.c
new file mode 100644
index 0000000000000..2ba5dcb5fef35
--- /dev/null
+++ b/lib/kunit/backtrace-suppression-test.c
@@ -0,0 +1,90 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for suppressing warning tracebacks.
+ *
+ * Copyright (C) 2024, Guenter Roeck
+ * Author: Guenter Roeck <linux@roeck-us.net>
+ */
+
+#include <kunit/test.h>
+#include <linux/bug.h>
+
+static void backtrace_suppression_test_warn_direct(struct kunit *test)
+{
+ KUNIT_START_SUPPRESSED_WARNING(test);
+ WARN(1, "This backtrace should be suppressed");
+ KUNIT_END_SUPPRESSED_WARNING(test);
+
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
+}
+
+static void trigger_backtrace_warn(void)
+{
+ WARN(1, "This backtrace should be suppressed");
+}
+
+static void backtrace_suppression_test_warn_indirect(struct kunit *test)
+{
+ KUNIT_START_SUPPRESSED_WARNING(test);
+ trigger_backtrace_warn();
+ KUNIT_END_SUPPRESSED_WARNING(test);
+
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
+}
+
+static void backtrace_suppression_test_warn_multi(struct kunit *test)
+{
+ KUNIT_START_SUPPRESSED_WARNING(test);
+ WARN(1, "This backtrace should be suppressed");
+ trigger_backtrace_warn();
+ KUNIT_END_SUPPRESSED_WARNING(test);
+
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 2);
+}
+
+static void backtrace_suppression_test_warn_on_direct(struct kunit *test)
+{
+ if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE) && !IS_ENABLED(CONFIG_KALLSYMS))
+ kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE or CONFIG_KALLSYMS");
+
+ KUNIT_START_SUPPRESSED_WARNING(test);
+ WARN_ON(1);
+ KUNIT_END_SUPPRESSED_WARNING(test);
+
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
+}
+
+static void trigger_backtrace_warn_on(void)
+{
+ WARN_ON(1);
+}
+
+static void backtrace_suppression_test_warn_on_indirect(struct kunit *test)
+{
+ if (!IS_ENABLED(CONFIG_DEBUG_BUGVERBOSE))
+ kunit_skip(test, "requires CONFIG_DEBUG_BUGVERBOSE");
+
+ KUNIT_START_SUPPRESSED_WARNING(test);
+ trigger_backtrace_warn_on();
+ KUNIT_END_SUPPRESSED_WARNING(test);
+
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
+}
+
+static struct kunit_case backtrace_suppression_test_cases[] = {
+ KUNIT_CASE(backtrace_suppression_test_warn_direct),
+ KUNIT_CASE(backtrace_suppression_test_warn_indirect),
+ KUNIT_CASE(backtrace_suppression_test_warn_multi),
+ KUNIT_CASE(backtrace_suppression_test_warn_on_direct),
+ KUNIT_CASE(backtrace_suppression_test_warn_on_indirect),
+ {}
+};
+
+static struct kunit_suite backtrace_suppression_test_suite = {
+ .name = "backtrace-suppression-test",
+ .test_cases = backtrace_suppression_test_cases,
+};
+kunit_test_suites(&backtrace_suppression_test_suite);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("KUnit test to verify warning backtrace suppression");
--
2.52.0
^ permalink raw reply related
* [PATCH v7 4/5] drm: Suppress intentional warning backtraces in scaling unit tests
From: Albert Esteve @ 2026-04-20 12:28 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter, Maíra Canal,
Alessandro Carminati, Albert Esteve, Simona Vetter
In-Reply-To: <20260420-kunit_add_support-v7-0-e8bc6e0f70de@redhat.com>
From: Guenter Roeck <linux@roeck-us.net>
The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
intentionally trigger warning backtraces by providing bad parameters to
the tested functions. What is tested is the return value, not the existence
of a warning backtrace. Suppress the backtraces to avoid clogging the
kernel log and distraction from real problems.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
Acked-by: Maíra Canal <mcanal@igalia.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: David Airlie <airlied@gmail.com>
Cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
drivers/gpu/drm/tests/drm_rect_test.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c
index 17e1f34b76101..1dd7d819165e7 100644
--- a/drivers/gpu/drm/tests/drm_rect_test.c
+++ b/drivers/gpu/drm/tests/drm_rect_test.c
@@ -409,8 +409,15 @@ static void drm_test_rect_calc_hscale(struct kunit *test)
const struct drm_rect_scale_case *params = test->param_value;
int scaling_factor;
+ /*
+ * drm_rect_calc_hscale() generates a warning backtrace whenever bad
+ * parameters are passed to it. This affects all unit tests with an
+ * error code in expected_scaling_factor.
+ */
+ KUNIT_START_SUPPRESSED_WARNING(test);
scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
params->min_range, params->max_range);
+ KUNIT_END_SUPPRESSED_WARNING(test);
KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
}
@@ -420,8 +427,15 @@ static void drm_test_rect_calc_vscale(struct kunit *test)
const struct drm_rect_scale_case *params = test->param_value;
int scaling_factor;
+ /*
+ * drm_rect_calc_vscale() generates a warning backtrace whenever bad
+ * parameters are passed to it. This affects all unit tests with an
+ * error code in expected_scaling_factor.
+ */
+ KUNIT_START_SUPPRESSED_WARNING(test);
scaling_factor = drm_rect_calc_vscale(¶ms->src, ¶ms->dst,
params->min_range, params->max_range);
+ KUNIT_END_SUPPRESSED_WARNING(test);
KUNIT_EXPECT_EQ(test, scaling_factor, params->expected_scaling_factor);
}
--
2.52.0
^ permalink raw reply related
* [PATCH v7 5/5] kunit: Add documentation for warning backtrace suppression API
From: Albert Esteve @ 2026-04-20 12:28 UTC (permalink / raw)
To: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton
Cc: linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, peterz, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter,
Alessandro Carminati, Albert Esteve, Kees Cook, David Gow
In-Reply-To: <20260420-kunit_add_support-v7-0-e8bc6e0f70de@redhat.com>
From: Guenter Roeck <linux@roeck-us.net>
Document API functions for suppressing warning backtraces.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
Signed-off-by: Albert Esteve <aesteve@redhat.com>
---
Documentation/dev-tools/kunit/usage.rst | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst
index ebd06f5ea4550..76e85412f240e 100644
--- a/Documentation/dev-tools/kunit/usage.rst
+++ b/Documentation/dev-tools/kunit/usage.rst
@@ -157,6 +157,34 @@ Alternatively, one can take full control over the error message by using
if (some_setup_function())
KUNIT_FAIL(test, "Failed to setup thing for testing");
+Suppressing warning backtraces
+------------------------------
+
+Some unit tests trigger warning backtraces either intentionally or as side
+effect. Such backtraces are normally undesirable since they distract from
+the actual test and may result in the impression that there is a problem.
+
+Such backtraces can be suppressed with **task scope suppression**: while
+``START`` / ``END`` is active on the current task, the backtrace and stack
+dump from warnings on that task are suppressed. Wrap the call from your test
+in that window, like shown in the following code.
+
+.. code-block:: c
+
+ static void some_test(struct kunit *test)
+ {
+ KUNIT_START_SUPPRESSED_WARNING(test);
+ trigger_backtrace();
+ KUNIT_END_SUPPRESSED_WARNING(test);
+ }
+
+``KUNIT_SUPPRESSED_WARNING_COUNT()`` returns the number of suppressed backtraces.
+If the suppressed backtrace was triggered on purpose, this can be used to check
+if the backtrace was actually triggered.
+
+.. code-block:: c
+
+ KUNIT_EXPECT_EQ(test, KUNIT_SUPPRESSED_WARNING_COUNT(), 1);
Test Suites
~~~~~~~~~~~
@@ -1211,4 +1239,4 @@ For example:
dev_managed_string = devm_kstrdup(fake_device, "Hello, World!");
// Everything is cleaned up automatically when the test ends.
- }
\ No newline at end of file
+ }
--
2.52.0
^ permalink raw reply related
* Re: [PATCH 7.2 v16 01/13] mm/khugepaged: generalize hugepage_vma_revalidate for mTHP support
From: Usama Arif @ 2026-04-20 12:59 UTC (permalink / raw)
To: Nico Pache
Cc: Usama Arif, linux-doc, linux-kernel, linux-mm, linux-trace-kernel,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, ljs, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260419185750.260784-2-npache@redhat.com>
On Sun, 19 Apr 2026 12:57:38 -0600 Nico Pache <npache@redhat.com> wrote:
> For khugepaged to support different mTHP orders, we must generalize this
> to check if the PMD is not shared by another VMA and that the order is
> enabled.
>
> No functional change in this patch. Also correct a comment about the
> functionality of the revalidation and fix a double space issues.
>
> Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Co-developed-by: Dev Jain <dev.jain@arm.com>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> mm/khugepaged.c | 20 ++++++++++++--------
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
Acked-by: Usama Arif <usama.arif@linux.dev>
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: arm: Add zx297520v3 board binding
From: Krzysztof Kozlowski @ 2026-04-20 13:00 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Rob Herring (Arm), linux-kernel, Conor Dooley, Jonathan Corbet,
Alexandre Belloni, Greg Kroah-Hartman, linux-doc, devicetree,
Drew Fustini, Linus Walleij, Jiri Slaby, Russell King, soc,
Arnd Bergmann, Krzysztof Kozlowski, linux-arm-kernel,
linux-serial, Shuah Khan
In-Reply-To: <6264667.lOV4Wx5bFT@strix>
On Sun, Apr 19, 2026 at 11:30:04AM +0300, Stefan Dösinger wrote:
> Hi Rob,
>
> Am Samstag, 18. April 2026, 00:08:44 Ostafrikanische Zeit schrieben Sie:
>
> > If you already ran 'make dt_binding_check' and didn't see the above
> > error(s), then make sure 'yamllint' is installed and dt-schema is up to
> > date:
>
> Here is a new PEBKAC issue for your mail template: I ran dt_binding_check, it
> wrote the warning you pointed out, but I only checked the return value - which
> indicated success. Which I guess makes sense for a warning, since there seem
> to be a few preexisting ones. The warning itself was somewhere in the
> scrollback because I let dt_binding_check check all the files.
>
> So I learned I have to actually look at the output to see if there are any
> warnings.
Same with every other tool warnings, like compiler warnings...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 7.2 v16 02/13] mm/khugepaged: generalize alloc_charge_folio()
From: Usama Arif @ 2026-04-20 13:05 UTC (permalink / raw)
To: Nico Pache
Cc: Usama Arif, linux-doc, linux-kernel, linux-mm, linux-trace-kernel,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, ljs, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260419185750.260784-3-npache@redhat.com>
On Sun, 19 Apr 2026 12:57:39 -0600 Nico Pache <npache@redhat.com> wrote:
> From: Dev Jain <dev.jain@arm.com>
>
> Pass order to alloc_charge_folio() and update mTHP statistics.
>
> Reviewed-by: Wei Yang <richard.weiyang@gmail.com>
> Reviewed-by: Lance Yang <lance.yang@linux.dev>
> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
> Reviewed-by: Zi Yan <ziy@nvidia.com>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Co-developed-by: Nico Pache <npache@redhat.com>
> Signed-off-by: Nico Pache <npache@redhat.com>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> ---
> Documentation/admin-guide/mm/transhuge.rst | 8 ++++++++
> include/linux/huge_mm.h | 2 ++
> mm/huge_memory.c | 4 ++++
> mm/khugepaged.c | 17 +++++++++++------
> 4 files changed, 25 insertions(+), 6 deletions(-)
>
Acked-by: Usama Arif <usama.arif@linux.dev>
^ permalink raw reply
* Re: [PATCH] cpufreq: CPPC: add autonomous mode boot parameter support
From: Sumit Gupta @ 2026-04-20 13:07 UTC (permalink / raw)
To: Pierre Gondois
Cc: linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, zhenglifeng1@huawei.com,
Thierry Reding, viresh.kumar@linaro.org, Jon Hunter, Vikram Sethi,
ionela.voinescu@arm.com, Krishna Sitaraman, Sanjay Chandrashekara,
zhanjie9@hisilicon.com, corbet@lwn.net, Matt Ochs,
skhan@linuxfoundation.org, Bibek Basu, rdunlap@infradead.org,
linux-pm@vger.kernel.org, mario.limonciello@amd.com,
rafael@kernel.org, sumitg
In-Reply-To: <208360b1-36a5-419d-80f4-431914407f61@arm.com>
>>> On 3/17/26 16:10, Sumit Gupta wrote:
>>>> Add kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable CPPC
>>>> autonomous performance selection on all CPUs at system startup without
>>>> requiring runtime sysfs manipulation. When autonomous mode is enabled,
>>>> the hardware automatically adjusts CPU performance based on workload
>>>> demands using Energy Performance Preference (EPP) hints.
>>>>
>>>> When auto_sel_mode=1:
>>>> - Configure all CPUs for autonomous operation on first init
>>>> - Set EPP to performance preference (0x0)
>>>> - Use HW min/max when set; otherwise program from policy limits (caps)
>>>> - Clamp desired_perf to bounds before enabling autonomous mode
>>>> - Hardware controls frequency instead of the OS governor
>>>>
>>>> The boot parameter is applied only during first policy initialization.
>>>> On hotplug, skip applying it so that the user's runtime sysfs
>>>> configuration is preserved.
>>>>
>>>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> (Documentation)
>>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>>> ---
>>>> Part 1 [1] of this series was applied for 7.1 and present in next.
>>>> Sending this patch as reworked version of 'patch 11' from [2] based
>>>> on next.
>>>>
>>>> [1]
>>>> https://lore.kernel.org/lkml/20260206142658.72583-1-sumitg@nvidia.com/
>>>> [2]
>>>> https://lore.kernel.org/lkml/20251223121307.711773-1-sumitg@nvidia.com/
>>>> ---
>>>> .../admin-guide/kernel-parameters.txt | 13 +++
>>>> drivers/cpufreq/cppc_cpufreq.c | 84
>>>> +++++++++++++++++--
>>>> 2 files changed, 92 insertions(+), 5 deletions(-)
>>>>
>>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>>> b/Documentation/admin-guide/kernel-parameters.txt
>>>> index fa6171b5fdd5..de4b4c89edfe 100644
>>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>>> @@ -1060,6 +1060,19 @@ Kernel parameters
>>>> policy to use. This governor must be
>>>> registered in the
>>>> kernel before the cpufreq driver probes.
>>>>
>>>> + cppc_cpufreq.auto_sel_mode=
>>>> + [CPU_FREQ] Enable ACPI CPPC autonomous
>>>> performance
>>>> + selection. When enabled, hardware
>>>> automatically adjusts
>>>> + CPU frequency on all CPUs based on workload
>>>> demands.
>>>> + In Autonomous mode, Energy Performance
>>>> Preference (EPP)
>>>> + hints guide hardware toward performance (0x0)
>>>> or energy
>>>> + efficiency (0xff).
>>>> + Requires ACPI CPPC autonomous selection
>>>> register support.
>>>> + Format: <bool>
>>>> + Default: 0 (disabled)
>>>> + 0: use cpufreq governors
>>>> + 1: enable if supported by hardware
>>>> +
>>>> cpu_init_udelay=N
>>>> [X86,EARLY] Delay for N microsec between
>>>> assert and de-assert
>>>> of APIC INIT to start processors. This delay
>>>> occurs
>>>> diff --git a/drivers/cpufreq/cppc_cpufreq.c
>>>> b/drivers/cpufreq/cppc_cpufreq.c
>>>> index 5dfb109cf1f4..49c148b2a0a4 100644
>>>> --- a/drivers/cpufreq/cppc_cpufreq.c
>>>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>>>> @@ -28,6 +28,9 @@
>>>>
>>>> static struct cpufreq_driver cppc_cpufreq_driver;
>>>>
>>>> +/* Autonomous Selection boot parameter */
>>>> +static bool auto_sel_mode;
>>>> +
>>>> #ifdef CONFIG_ACPI_CPPC_CPUFREQ_FIE
>>>> static enum {
>>>> FIE_UNSET = -1,
>>>> @@ -708,11 +711,74 @@ static int cppc_cpufreq_cpu_init(struct
>>>> cpufreq_policy *policy)
>>>> policy->cur = cppc_perf_to_khz(caps, caps->highest_perf);
>>>> cpu_data->perf_ctrls.desired_perf = caps->highest_perf;
>>>>
>>>> - ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>>>> - if (ret) {
>>>> - pr_debug("Err setting perf value:%d on CPU:%d. ret:%d\n",
>>>> - caps->highest_perf, cpu, ret);
>>>> - goto out;
>>>> + /*
>>>> + * Enable autonomous mode on first init if boot param is set.
>>>> + * Check last_governor to detect first init and skip if auto_sel
>>>> + * is already enabled.
>>>> + */
>>> If the goal is to set autosel only once at the driver init,
>>> shouldn't this be done in cppc_cpufreq_init() ?
>>> I understand that cpu_data doesn't exist yet in
>>> cppc_cpufreq_init(), but this seems more appropriate to do
>>> it there IMO.
>>>
>>> This means the cpudata should be updated accordingly
>>> in this cppc_cpufreq_cpu_init() function.
>> In an earlier version [1], the setup was in cppc_cpufreq_init() but
>> was moved to cppc_cpufreq_cpu_init() to improve per-CPU error handling.
>> Keeping the setup in cppc_cpufreq_init() helps to avoid the last_governor
>> check. We can warn for a CPU failing to enable and continue so other
>> CPUs keep autonomous mode.
>> cppc_cpufreq_cpu_init() would then just check the auto_sel state
>> from register and sync policy limits from min/max_perf registers when
>> autonomous mode is active.
>> Please let me know your thoughts.
> FWIU the auto_sel_mode module parameter allows to
> configure the default auto_sel_mode when the driver is
> first loaded, so there should not need to check that again
> whenever cppc_cpufreq_cpu_init() is called.
> Maybe Ionela saw something we didn't see ?
AFAIU, the concern in that review [1] was about error handling as the
earlier version disabled auto_sel on all CPUs if any single CPU failed.
Per-CPU error handling in cppc_cpufreq_init() (warn and continue)
addresses that. Can't think of more reason.
Do you have anything in mind?
>
> Also just to be sure, should it still be possible to change
> the auto_sel_mode through the sysfs if the driver was
> loaded with auto_sel_mode=1 ?
>
Yes, the per-CPU auto_select sysfs attribute works independently of the
boot param. Users can enable or disable auto_sel on any CPU at runtime
via sysfs, regardless of how the driver was loaded. The boot param only
sets the initial state.
>> [1]
>> https://lore.kernel.org/lkml/5593d364-ca37-41c5-b33f-f7e245d6d626@nvidia.com/
>>
>>
>>>> + if (auto_sel_mode && policy->last_governor[0] == '\0' &&
>>>> + !cpu_data->perf_ctrls.auto_sel) {
>>>> + /* Enable CPPC - optional register, some platforms
>>>> need it */
>>> The documentation of the CPPC Enable Register is subject to
>>> interpretation, but IIUC the field should be set to use the CPPC
>>> controls, so I assume this should be set in cppc_cpufreq_init()
>>> instead ?
>> Agree that the CPPC Enable is about using the CPPC control path
>> in general and not only for autonomous selection.
>> Will move cppc_set_enable() into cppc_cpufreq_init() or outside the
>> autonomous mode block in cppc_cpufreq_cpu_init() as per conclusion
>> of previous comment.
>>
>>>> + ret = cppc_set_enable(cpu, true);
>>>> + if (ret && ret != -EOPNOTSUPP)
>>>> + pr_warn("Failed to enable CPPC for CPU%d
>>>> (%d)\n", cpu, ret);
>>>> +
>>>> + /*
>>>> + * Prefer HW min/max_perf when set; otherwise program
>>>> from
>>>> + * policy limits derived earlier from caps.
>>>> + * Clamp desired_perf to bounds and sync policy->cur.
>>>> + */
>>>> + if (!cpu_data->perf_ctrls.min_perf ||
>>>> !cpu_data->perf_ctrls.max_perf)
>>> The function doesn't seem to exist.
>> It is newly added in [2].
>> Don't need to call it if we move the setup to cppc_cpufreq_init().
> Ah ok right thanks.
>
>
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ea3db45ae476889a1ba0ab3617e6afdeeefbda3d
>>
>>
>>
>>>> + cppc_cpufreq_update_perf_limits(cpu_data, policy);
>>>> +
>>>> + cpu_data->perf_ctrls.desired_perf =
>>>> + clamp_t(u32, cpu_data->perf_ctrls.desired_perf,
>>>> + cpu_data->perf_ctrls.min_perf,
>>>> + cpu_data->perf_ctrls.max_perf);
>>>> +
>>>> + policy->cur = cppc_perf_to_khz(caps,
>>>> + cpu_data->perf_ctrls.desired_perf);
>>>> +
>>> Maybe this should also be done in cppc_cpufreq_init()
>>> if the auto_sel_mode parameter is set ?
>> Yes.
>>
>>>> + /* EPP is optional - some platforms may not support it */
>>>> + ret = cppc_set_epp(cpu, CPPC_EPP_PERFORMANCE_PREF);
>>>> + if (ret && ret != -EOPNOTSUPP)
>>>> + pr_warn("Failed to set EPP for CPU%d (%d)\n",
>>>> cpu, ret);
>>>> + else if (!ret)
>>>> + cpu_data->perf_ctrls.energy_perf =
>>>> CPPC_EPP_PERFORMANCE_PREF;
>>>> +
>>>> + ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>>>> + if (ret) {
>>>> + pr_debug("Err setting perf for autonomous mode
>>>> CPU:%d ret:%d\n",
>>>> + cpu, ret);
>>>> + goto out;
>>>> + }
>>>> +
>>>> + ret = cppc_set_auto_sel(cpu, true);
>>>> + if (ret && ret != -EOPNOTSUPP) {
>>>> + pr_warn("Failed autonomous config for CPU%d
>>>> (%d)\n",
>>>> + cpu, ret);
>>>> + goto out;
>>>> + }
>>>> + if (!ret)
>>>> + cpu_data->perf_ctrls.auto_sel = true;
>>>> + }
>>>> +
>>>> + if (cpu_data->perf_ctrls.auto_sel) {
>>> There is a patchset ongoing which tries to remove
>>> setting policy->min/max from driver initialization.
>>> Indeed, these values are only temporarily valid,
>>> until the governor override them.
>>> It is not sure yet the patch will be accepted though.
>>>
>>> https://lore.kernel.org/lkml/20260317101753.2284763-4-pierre.gondois@arm.com/
>>>
>>
>> You are right that policy->min/max from .init() are temporary today
>> as cpufreq_set_policy() overwrites them before the governor starts.
>>
>> On my test platform (highest == nominal, lowest_nonlinear == lowest),
>> this had no visible effect because the BIOS bounds and cpuinfo range
>> end up identical. But on platforms where they differ, the governor
>> would widen the range to full cpuinfo limits.
>>
>> I think your patch [3] fixes this by giving these the right semantic as
>> initial QoS requests. With it, cpufreq_set_policy() preserves the policy
>> limits set from min/max_perf registers in .init(), which can either be
>> BIOS values on first boot or last user configured values before hotplug.
>>
>> I will update the comment in v2 to reflect QoS seeding intent.
>>
>> I see that the first two patches of your series [3] is applied for 7.1.
>> Do you plan to send the pending patch (3/4) from [3]?
>>
> I need to ping Viresh to check if this is still relevant.
>
>
>> [3]
>> https://lore.kernel.org/lkml/20260317101753.2284763-4-pierre.gondois@arm.com/
>>
>>
>>>
>>>> + /* Sync policy limits from HW when autonomous mode is
>>>> active */
>>>> + policy->min = cppc_perf_to_khz(caps,
>>>> + cpu_data->perf_ctrls.min_perf ?:
>>>> + caps->lowest_nonlinear_perf);
>>>> + policy->max = cppc_perf_to_khz(caps,
>>>> + cpu_data->perf_ctrls.max_perf ?:
>>>> + caps->nominal_perf);
>>>> + } else {
>>>> + /* Normal mode: governors control frequency */
>>>> + ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>>>> + if (ret) {
>>>> + pr_debug("Err setting perf value:%d on CPU:%d.
>>>> ret:%d\n",
>>>> + caps->highest_perf, cpu, ret);
>>>> + goto out;
>>>> + }
>>>> }
>>>>
>>>> cppc_cpufreq_cpu_fie_init(policy);
>>>> @@ -1038,10 +1104,18 @@ static int __init cppc_cpufreq_init(void)
>>>>
>>>> static void __exit cppc_cpufreq_exit(void)
>>>> {
>>>> + unsigned int cpu;
>>>> +
>>>> + for_each_present_cpu(cpu)
>>>> + cppc_set_auto_sel(cpu, false);
>>> If the firmware has a default EPP value, it means that loading
>>> and the unloading the driver will reset this default EPP value.
>>> Maybe the initial EPP value and/or the auto_sel value should be
>>> cached somewhere and restored on exit ?
>>> I don't know if this is actually an issue, this is just to signal it.
>> The auto_sel_mode boot path programs EPP to performance preference(0),
>> not the firmware’s previous value. On unload we only call
>> cppc_set_auto_sel(false); we do not restore EPP, min/max perf,
>> or other CPPC fields to firmware defaults.
> Yes right, so loading/unloading the driver might change the
> default EPP value.
Acknowledged.
With auto_sel_mode, load/unload can leave EPP and other CPPC fields
different from the firmware defaults at boot.
We can add explicit cache-and-restore on exit in a follow-up
if that is desired.
Thank you,
Sumit Gupta
^ permalink raw reply
* Re: [PATCH] cpufreq: CPPC: add autonomous mode boot parameter support
From: Sumit Gupta @ 2026-04-20 13:13 UTC (permalink / raw)
To: Viresh Kumar, Pierre Gondois
Cc: linux-tegra, linux-kernel, linux-doc, zhenglifeng1, treding,
jonathanh, vsethi, ionela.voinescu, ksitaraman, sanjayc, zhanjie9,
corbet, mochs, skhan, bbasu, rdunlap, linux-pm, mario.limonciello,
rafael, sumitg
In-Reply-To: <zfoorh6tza4taswyr5zhxqn4rhcqzq4rtvz46eigoy25muxfls@tlbuypuwocvm>
On 13/04/26 11:21, Viresh Kumar wrote:
> External email: Use caution opening links or attachments
>
>
> On 10-04-26, 15:47, Pierre Gondois wrote:
>> I need to ping Viresh to check if this is still relevant.
> I think its okay to clear the min/max state in the kernel once and for all if
> you think it is not done nicely. As discussed earlier, try that in a fresh
> series which only does that part.
>
> --
> viresh
Thanks Pierre and Viresh.
In autonomous mode, the min/max_perf HW registers directly control the
frequency range the hardware operates in, so the values programmed in
.init() need to survive through the governor.
I verified this on a platform where lowest_nonlinear_perf != lowest_perf,
the min_perf register ends up at lowest_perf instead of the intended
lowest_nonlinear_perf.
Pierre's QoS seeding patch would fix this.
Happy to test once it's sent.
Thank you,
Sumit Gupta
^ permalink raw reply
* Re: [PATCH 7.2 v16 03/13] mm/khugepaged: rework max_ptes_* handling with helper functions
From: Usama Arif @ 2026-04-20 13:15 UTC (permalink / raw)
To: Nico Pache
Cc: Usama Arif, linux-doc, linux-kernel, linux-mm, linux-trace-kernel,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, ljs, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260419185750.260784-4-npache@redhat.com>
On Sun, 19 Apr 2026 12:57:40 -0600 Nico Pache <npache@redhat.com> wrote:
> The following cleanup reworks all the max_ptes_* handling into helper
> functions. This increases the code readability and will later be used to
> implement the mTHP handling of these variables.
>
> With these changes we abstract all the madvise_collapse() special casing
> (dont respect the sysctls) away from the functions that utilize them. And
> will later in this series to cleanly restrict mTHP collapses behaviors.
>
> Suggested-by: David Hildenbrand <david@kernel.org>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> mm/khugepaged.c | 114 +++++++++++++++++++++++++++++++++---------------
> 1 file changed, 78 insertions(+), 36 deletions(-)
>
The old code re-read khugepaged_max_ptes_* on every loop iteration; the new
code snapshots them once per scan call. If userspace writes the sysctl
mid-scan, old behavior reacted within the scan, new behavior uses the value
sampled at entry. This is completely ok IMO, but might be good to call out.
Also might be good to write no functional change intended apart from
above in the commit message?
Acked-by: Usama Arif <usama.arif@linux.dev>
^ permalink raw reply
* [PATCH AUTOSEL 7.0-6.18] hwmon: (pmbus/isl68137) Add support for Renesas RAA228942 and RAA228943
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Dawei Liu, Guenter Roeck, Sasha Levin, jdelvare, corbet,
linux-hwmon, linux-doc, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Dawei Liu <dawei.liu.jy@renesas.com>
[ Upstream commit 7c760db74c9f30da7281c7f450d0676ec78ec3e6 ]
Add I2C device IDs for Renesas RAA228942 and RAA228943.
At the Linux PMBus hwmon interface level currently supported by this
driver, these devices are compatible with the existing 2-rail non-TC
controllers, so devicetree will use fallback compatibles and no
dedicated OF match entries are needed.
Signed-off-by: Dawei Liu <dawei.liu.jy@renesas.com>
Link: https://lore.kernel.org/r/20260325090208.857-3-dawei.liu.jy@renesas.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a complete analysis. Let me
compile the findings.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem: `hwmon: (pmbus/isl68137)`
- Action verb: "Add support"
- Summary: Add I2C device IDs for two new Renesas voltage regulators
(RAA228942 and RAA228943)
- Record: This is a device ID addition, not a bug fix.
**Step 1.2: Tags**
- Signed-off-by: Dawei Liu <dawei.liu.jy@renesas.com> (author, Renesas
employee)
- Link: lore.kernel.org mail link
- Signed-off-by: Guenter Roeck <linux@roeck-us.net> (hwmon subsystem
maintainer - accepted the patch)
- No Fixes: tag (expected for candidates)
- No Cc: stable (expected for candidates)
- No Reported-by, Tested-by, or Reviewed-by
**Step 1.3: Commit Body**
- States that these devices "are compatible with the existing 2-rail
non-TC controllers"
- Explicitly says "devicetree will use fallback compatibles and no
dedicated OF match entries are needed"
- This is a pure hardware enablement addition
**Step 1.4: Hidden Bug Fix?**
- No. This is not a hidden bug fix. It is straightforward device ID
addition.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- `Documentation/hwmon/isl68137.rst`: +20 lines (documentation for two
new devices)
- `drivers/hwmon/pmbus/isl68137.c`: +2 lines (two I2C device ID table
entries)
- Total: +22 lines, 0 removed
- Scope: Trivially small, single-file code change + docs
**Step 2.2: Code Flow**
- Two entries added to the `raa_dmpvr_id[]` I2C device ID table:
- `{"raa228942", raa_dmpvr2_2rail_nontc}`
- `{"raa228943", raa_dmpvr2_2rail_nontc}`
- These use the existing `raa_dmpvr2_2rail_nontc` variant, which was
introduced in commit 51fb91ed5a6fa (v5.10 era). The variant disables
`TEMP3` and configures 2-page mode.
- No new code paths, no new functions, no logic changes
**Step 2.3: Bug Mechanism**
- Category: Hardware device ID addition (exception category h)
- Without these IDs, the kernel cannot bind the existing ISL68137 PMBus
driver to these Renesas parts
**Step 2.4: Fix Quality**
- Obviously correct: merely adding two string/enum pairs to an existing
table
- Minimal and surgical
- Zero regression risk: only affects systems with these specific I2C
devices
- No new code paths, APIs, or behavioral changes
## PHASE 3: GIT HISTORY
**Step 3.1: Blame**
- The `raa_dmpvr_id[]` table has been present since commit f621d61fd59f4
(2020). The `raa_dmpvr2_2rail_nontc` variant was added in commit
51fb91ed5a6fa (2020, v5.10 era).
- Both are present in all active stable trees (5.10+, 5.15+, 6.1+, 6.6+)
**Step 3.2: Fixes Tag**
- No Fixes: tag (not applicable - this is a device ID addition, not a
bug fix)
**Step 3.3: File History**
- Prior identical-pattern commit: 2190ad55a601d added RAA228244 and
RAA228246 in the same manner. This was a v6.18/6.19 timeframe commit.
- The pattern of adding new Renesas device IDs to this driver is well
established.
**Step 3.4: Author**
- Dawei Liu is a Renesas employee (dawei.liu.jy@renesas.com),
appropriate for submitting Renesas device support.
**Step 3.5: Dependencies**
- No dependencies. The `raa_dmpvr2_2rail_nontc` enum value and its case
statement already exist in stable trees back to 5.10.
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1-4.5:** Lore is behind bot protection and cannot be fetched.
However, the Link: tag confirms the patch was submitted via the standard
process and accepted by hwmon maintainer Guenter Roeck. The `b4 dig` of
the prior similar commit (2190ad55a601d) confirmed it was part of a
normal patch series accepted through the standard hwmon tree.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1-5.5:**
- The only code change is adding entries to a static `struct
i2c_device_id` table.
- When the I2C subsystem finds a device matching `"raa228942"` or
`"raa228943"`, it will call `isl68137_probe()` with the
`raa_dmpvr2_2rail_nontc` variant.
- The `raa_dmpvr2_2rail_nontc` case (lines 413-416) simply disables
TEMP3, falls through to the 2-rail handler. This is well-tested code
used by RAA228228, RAA228244, and RAA228246.
- No new code paths are created.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1:** The driver exists in all active stable trees (5.10+). The
`raa_dmpvr2_2rail_nontc` variant exists since 5.10.
**Step 6.2:** The patch adds 2 lines to the I2C ID table and
documentation. It will apply cleanly or with trivial context adjustments
(the table is in alphabetical order).
**Step 6.3:** No related fixes already in stable for these specific
devices.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1:** `drivers/hwmon/pmbus` - hardware monitoring for PMBus
voltage regulators. Criticality: PERIPHERAL (specific hardware).
However, PMBus voltage regulators are used in servers and embedded
systems where stable kernels are common.
**Step 7.2:** Actively maintained by Guenter Roeck, with regular device
ID additions.
## PHASE 8: IMPACT AND RISK
**Step 8.1:** Affects users of Renesas RAA228942/RAA228943 hardware
specifically.
**Step 8.2:** Without these IDs, the driver cannot bind to the hardware
at all. Users with this hardware have no workaround on stable kernels.
**Step 8.3:** Failure mode without fix: hardware is completely
inaccessible. Severity: MEDIUM (functional but not crash/corruption).
**Step 8.4:**
- Benefit: Enables hardware monitoring for users with these specific
Renesas voltage regulators on stable kernels.
- Risk: Essentially zero. Two table entries using an existing, well-
tested variant.
- Ratio: Very favorable benefit/risk.
## PHASE 9: FINAL SYNTHESIS
**Evidence FOR backporting:**
- Device ID addition to existing driver - explicitly allowed exception
category
- Trivially small (2 lines of code)
- Uses existing, well-tested variant (`raa_dmpvr2_2rail_nontc`) present
since v5.10
- Zero regression risk
- Accepted by subsystem maintainer (Guenter Roeck)
- Author is from the chip vendor (Renesas)
- Enables real hardware for real users
**Evidence AGAINST backporting:**
- Not a bug fix - purely hardware enablement
- Affects only users with these specific Renesas parts (narrow audience)
**Stable Rules Checklist:**
1. Obviously correct? **YES** - trivial table addition
2. Fixes a real bug? **No** - but device ID additions are an explicit
exception
3. Important? Moderately - enables hardware for users who have it
4. Small and contained? **YES** - 2 lines of code + docs
5. No new features/APIs? **YES** - no new features, just ID binding
6. Can apply to stable? **YES** - clean apply expected
**Exception Category:** Device ID addition to existing driver - this is
one of the explicitly listed categories that ARE allowed in stable
despite being "additions."
## Verification
- [Phase 1] Parsed tags: Signed-off-by from Renesas author + hwmon
maintainer Guenter Roeck; Link to lore
- [Phase 2] Diff analysis: +2 lines in I2C ID table (raa228942/raa228943
as raa_dmpvr2_2rail_nontc), +20 lines docs
- [Phase 3] git blame: ID table present since f621d61fd59f4 (2020);
nontc variant since 51fb91ed5a6fa (2020, v5.10 era)
- [Phase 3] git tag --contains 51fb91ed5a6fa: present in p-5.10, p-5.15,
all active stable trees
- [Phase 3] git log: prior identical-pattern commit 2190ad55a601d
(RAA228244/RAA228246) confirmed
- [Phase 3] git log --author: author is Renesas employee
- [Phase 4] b4 dig: lore blocked by bot protection; confirmed standard
hwmon maintainer acceptance via prior similar commit
- [Phase 5] Code reading: raa_dmpvr2_2rail_nontc case at line 413
disables TEMP3, falls through to 2-rail; well-tested
- [Phase 6] Verified existing variant in tree at lines 76, 413, 498-500,
549-551
- [Phase 6] No raa228942/raa228943 references found anywhere in current
tree (grep confirmed)
- [Phase 8] Risk: zero regression potential from static table entry
addition
- UNVERIFIED: Could not read lore discussion due to bot protection
This is a textbook device ID addition - the simplest and safest type of
stable backport. Two lines adding I2C device IDs to an existing driver
using an existing, well-tested variant. Zero regression risk, enables
hardware for real users.
**YES**
Documentation/hwmon/isl68137.rst | 20 ++++++++++++++++++++
drivers/hwmon/pmbus/isl68137.c | 2 ++
2 files changed, 22 insertions(+)
diff --git a/Documentation/hwmon/isl68137.rst b/Documentation/hwmon/isl68137.rst
index e77f582c28505..0ce20d09164fc 100644
--- a/Documentation/hwmon/isl68137.rst
+++ b/Documentation/hwmon/isl68137.rst
@@ -394,6 +394,26 @@ Supported chips:
Provided by Renesas upon request and NDA
+ * Renesas RAA228942
+
+ Prefix: 'raa228942'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ Provided by Renesas upon request and NDA
+
+ * Renesas RAA228943
+
+ Prefix: 'raa228943'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ Provided by Renesas upon request and NDA
+
* Renesas RAA229001
Prefix: 'raa229001'
diff --git a/drivers/hwmon/pmbus/isl68137.c b/drivers/hwmon/pmbus/isl68137.c
index 3e3a887aad050..c8930f2d54237 100644
--- a/drivers/hwmon/pmbus/isl68137.c
+++ b/drivers/hwmon/pmbus/isl68137.c
@@ -498,6 +498,8 @@ static const struct i2c_device_id raa_dmpvr_id[] = {
{"raa228228", raa_dmpvr2_2rail_nontc},
{"raa228244", raa_dmpvr2_2rail_nontc},
{"raa228246", raa_dmpvr2_2rail_nontc},
+ {"raa228942", raa_dmpvr2_2rail_nontc},
+ {"raa228943", raa_dmpvr2_2rail_nontc},
{"raa229001", raa_dmpvr2_2rail},
{"raa229004", raa_dmpvr2_2rail},
{"raa229141", raa_dmpvr2_2rail_pmbus},
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] hwmon: (asus-ec-sensors )add ROG CROSSHAIR X670E EXTREME
From: Sasha Levin @ 2026-04-20 13:18 UTC (permalink / raw)
To: patches, stable
Cc: Timothy C. Sweeney-Fanelli, Eugene Shalygin, Guenter Roeck,
Sasha Levin, corbet, linux-hwmon, linux-doc, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: "Timothy C. Sweeney-Fanelli" <tim@zerobytellc.com>
[ Upstream commit ab4b7071ae0a831e4c2fd45c626c3b1d66cc1201 ]
Add support for ROG CROSSHAIR X670E EXTREME
Signed-off-by: Timothy C. Sweeney-Fanelli <tim@zerobytellc.com>
Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>
Link: https://lore.kernel.org/r/20260215151743.20138-3-eugene.shalygin@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a complete analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem: `hwmon: (asus-ec-sensors)`
- Action verb: `add`
- Summary: Add board support for ROG CROSSHAIR X670E EXTREME motherboard
Record: [hwmon/asus-ec-sensors] [add] [New motherboard board definition
for ROG CROSSHAIR X670E EXTREME]
**Step 1.2: Tags**
- `Signed-off-by: Timothy C. Sweeney-Fanelli <tim@zerobytellc.com>` —
original contributor/tester of the board info
- `Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com>` — driver
maintainer who curates submissions
- `Link: https://lore.kernel.org/r/20260215151743.20138-3-
eugene.shalygin@gmail.com` — patch 3 of a series
- `Signed-off-by: Guenter Roeck <linux@roeck-us.net>` — hwmon subsystem
maintainer who merged it
Record: No Fixes tag (expected for a board addition). No Reported-by,
Cc: stable, or syzbot. The patch went through the driver author
(Shalygin) and hwmon maintainer (Roeck). This is patch 3 of a series.
**Step 1.3: Commit Body**
The body simply says "Add support for ROG CROSSHAIR X670E EXTREME." No
bug description, stack traces, or failure modes — this is a hardware
enablement commit.
Record: No bug is described; this is a hardware support addition for a
specific ASUS motherboard model.
**Step 1.4: Hidden Bug Fix Detection**
This is not a hidden bug fix. It's a straightforward board ID / sensor
configuration addition to enable hwmon sensor monitoring on a new
motherboard.
Record: Not a hidden bug fix. Pure hardware enablement.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- `Documentation/hwmon/asus_ec_sensors.rst`: +1 line (adds board name to
supported list)
- `drivers/hwmon/asus-ec-sensors.c`: +11 lines (9-line board_info struct
+ 2-line DMI table entry)
- Total: ~12 lines added, 0 removed
- Functions modified: None. Only static const data structures added.
Record: 2 files, +12 lines, 0 lines removed. Only adds static const data
(board_info struct and DMI match entry). Scope: single-file surgical
addition.
**Step 2.2: Code Flow**
- Hunk 1 (board_info): Adds `board_info_crosshair_x670e_extreme` struct
with temperature sensors (CPU, CPU Package, MB, VRM, T_Sensor,
Water_In, Water_Out), mutex path
`ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0`, and
`family_amd_600_series`.
- Hunk 2 (DMI table): Adds a `DMI_EXACT_MATCH_ASUS_BOARD_NAME` entry
linking the board name to the new struct.
- Before: The board was not recognized; driver wouldn't probe on this
motherboard.
- After: The board is recognized and the defined sensors are exposed via
hwmon.
**Step 2.3: Bug Mechanism**
Category: Hardware workaround / device ID addition. No bug fix. The new
struct uses existing sensor macros, an existing mutex path (verified at
7 other locations), and an existing family (`family_amd_600_series`).
The sensor table `sensors_family_amd_600[]` (line 275) includes all the
sensors referenced: `ec_sensor_temp_cpu`, `ec_sensor_temp_cpu_package`,
`ec_sensor_temp_mb`, `ec_sensor_temp_vrm`, `ec_sensor_temp_t_sensor`,
`ec_sensor_temp_water_in`, `ec_sensor_temp_water_out`.
Record: This is a hardware enablement (new board ID) addition. All
referenced sensors, mutex path, and family exist in the codebase.
**Step 2.4: Fix Quality**
- Obviously correct: Yes — follows the exact same pattern as dozens of
other board entries
- Minimal/surgical: Yes — 12 lines of purely static data
- Regression risk: Essentially zero — the new DMI match only triggers on
the exact board name "ROG CROSSHAIR X670E EXTREME". Cannot affect any
other board.
## PHASE 3: GIT HISTORY
**Step 3.1: Blame**
The code this is inserted adjacent to
(`board_info_crosshair_viii_impact` and
`board_info_crosshair_x670e_gene`) has been present since 2022-2023. The
AMD 600 series family support was introduced in commit 790dec13c0128
(April 2023), and is present in all stable trees since ~v6.5+.
**Step 3.2: Fixes Tag**
No Fixes: tag present (expected — this is not a bug fix, it's a new
board addition).
**Step 3.3: File History**
The file has 65+ commits since the driver was introduced (d0ddfd241e571,
Jan 2022). The vast majority are board additions just like this one.
Eugene Shalygin is the driver author/maintainer and has authored nearly
all of them.
**Step 3.4: Author**
Eugene Shalygin is the original author and maintainer of the asus-ec-
sensors driver (copyright 2021, authored 40+ commits). Timothy Sweeney-
Fanelli is the board owner who contributed the sensor data.
**Step 3.5: Dependencies**
No dependencies. All referenced constants (`SENSOR_TEMP_CPU`,
`SENSOR_TEMP_WATER_IN`, `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0`,
`family_amd_600_series`) already exist in the 7.0 stable tree. This is a
standalone addition.
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1-4.5:**
The Link: tag indicates this is patch 3 of a series
(20260215151743.20138-3). Lore.kernel.org is behind Anubis protection
and cannot be fetched. However, b4 dig confirmed similar patches from
the same author are findable. The patch was accepted by hwmon maintainer
Guenter Roeck, the standard pathway for all asus-ec-sensors changes.
Record: Could not access lore due to Anubis bot protection. The patch
followed the standard hwmon submission path (contributor -> driver
author -> Guenter Roeck).
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1-5.5:**
No functions are modified. The change adds only static const data
structures. The DMI matching framework (`dmi_table[]`) is used during
module probe. When the DMI system matches the board name, the driver
reads sensors from EC registers at the offsets defined in
`sensors_family_amd_600[]`. This is a purely data-driven mechanism — no
code path changes.
Record: No code flow changes. Only static data additions. The DMI match
→ board_info → sensor table pipeline is well-established and works
identically for all 40+ supported boards.
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1:**
The driver exists since v5.18 (d0ddfd241e571, Jan 2022). AMD 600 series
support exists since v6.5 (790dec13c0128, Apr 2023). The
`ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0` mutex path and all sensor
macros exist in 7.0.
**Step 6.2:**
The patch should apply cleanly. It's a pure addition between existing
entries in two sorted lists (board_info structs and DMI table). No
conflicts expected.
**Step 6.3:**
No related fix needed — this board has never been supported before.
## PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1:**
Subsystem: hwmon (hardware monitoring). Criticality: PERIPHERAL —
affects only users of this specific ASUS motherboard. However, hwmon
sensor monitoring is important for users who rely on temperature/fan
monitoring for system health.
**Step 7.2:**
The driver is actively maintained with 65+ commits, mostly board
additions from the original author.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1:** Affected users: only owners of the ROG CROSSHAIR X670E
EXTREME motherboard.
**Step 8.2:** Trigger: automatic during driver probe if the DMI board
name matches.
**Step 8.3:** Failure mode without fix: no hwmon sensor data available
for this board. Users cannot monitor CPU/VRM temperatures, water cooling
temps, etc. through the standard hwmon interface.
**Step 8.4:**
- Benefit: LOW-MEDIUM — enables hardware monitoring for a specific
popular enthusiast motherboard
- Risk: VERY LOW — 12 lines of static const data, cannot affect any
other board
- Ratio: Favorable
## PHASE 9: FINAL SYNTHESIS
**Evidence FOR backporting:**
- Falls squarely into the "new device ID / board addition" exception
category
- Trivially small (12 lines of static const data)
- Zero regression risk (only triggers on exact DMI board name match)
- All infrastructure (AMD 600 series sensors, mutex path) already exists
in stable
- Authored by the driver maintainer, accepted by the hwmon subsystem
maintainer
- Follows identical pattern to dozens of prior board additions
**Evidence AGAINST backporting:**
- This is not a bug fix — it's hardware enablement
- Affects only one specific motherboard model
- No Cc: stable tag (but this is expected for board additions needing
manual review)
**Stable rules checklist:**
1. Obviously correct? YES — identical pattern to 40+ other entries
2. Fixes a real bug? NO — but falls into the device ID exception
3. Important issue? NO — but enables real hardware for real users
4. Small and contained? YES — 12 lines, static data only
5. No new features/APIs? YES — no new interfaces, just enables existing
driver on new hardware
6. Can apply to stable? YES — clean apply expected
**Verification:**
- [Phase 1] Parsed tags: SOBs from Timothy Sweeney-Fanelli
(contributor), Eugene Shalygin (driver author), Guenter Roeck (hwmon
maintainer). Link to lore present.
- [Phase 2] Diff: +12 lines across 2 files. Only static const board_info
struct and DMI table entry added. No code logic changes.
- [Phase 3] git log: Eugene Shalygin authored 40+ commits to this file,
is the original driver author (copyright 2021).
- [Phase 3] git log: AMD 600 series support introduced in 790dec13c0128
(April 2023), present in 7.0 tree.
- [Phase 3] Verified `ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0` used
by 7 other boards (lines 567, 673, 687, 694, 702, 710, 777).
- [Phase 3] Verified all sensor macros used (`SENSOR_TEMP_CPU`,
`SENSOR_TEMP_CPU_PACKAGE`, `SENSOR_TEMP_MB`, `SENSOR_TEMP_VRM`,
`SENSOR_TEMP_T_SENSOR`, `SENSOR_TEMP_WATER_IN`,
`SENSOR_TEMP_WATER_OUT`) exist in `sensors_family_amd_600[]` (lines
275-293).
- [Phase 4] Lore inaccessible due to Anubis protection; b4 dig could not
find the commit directly (likely not yet in tree). The submission path
(contributor -> driver author -> Guenter Roeck) is standard.
- [Phase 5] No functions modified. Only static const data. Zero code
path impact.
- [Phase 6] Driver and AMD 600 series support exist in 7.0 tree. Clean
apply expected.
- [Phase 8] Risk: VERY LOW (static data only, DMI-scoped). Benefit:
enables hwmon on a specific board.
This is a textbook new board ID addition to an existing driver — one of
the explicitly allowed exception categories for stable backporting. It's
trivially small, uses only existing infrastructure, and cannot regress
any other system.
**YES**
Documentation/hwmon/asus_ec_sensors.rst | 1 +
drivers/hwmon/asus-ec-sensors.c | 11 +++++++++++
2 files changed, 12 insertions(+)
diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst
index 58986546c7233..8a080a786abd2 100644
--- a/Documentation/hwmon/asus_ec_sensors.rst
+++ b/Documentation/hwmon/asus_ec_sensors.rst
@@ -22,6 +22,7 @@ Supported boards:
* ROG CROSSHAIR VIII FORMULA
* ROG CROSSHAIR VIII HERO
* ROG CROSSHAIR VIII IMPACT
+ * ROG CROSSHAIR X670E EXTREME
* ROG CROSSHAIR X670E HERO
* ROG CROSSHAIR X670E GENE
* ROG MAXIMUS X HERO
diff --git a/drivers/hwmon/asus-ec-sensors.c b/drivers/hwmon/asus-ec-sensors.c
index adedaf0db10e6..934e37738a516 100644
--- a/drivers/hwmon/asus-ec-sensors.c
+++ b/drivers/hwmon/asus-ec-sensors.c
@@ -456,6 +456,15 @@ static const struct ec_board_info board_info_crosshair_viii_impact = {
.family = family_amd_500_series,
};
+static const struct ec_board_info board_info_crosshair_x670e_extreme = {
+ .sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
+ SENSOR_TEMP_MB | SENSOR_TEMP_VRM |
+ SENSOR_TEMP_T_SENSOR | SENSOR_TEMP_WATER_IN |
+ SENSOR_TEMP_WATER_OUT,
+ .mutex_path = ASUS_HW_ACCESS_MUTEX_SB_PCI0_SBRG_SIO1_MUT0,
+ .family = family_amd_600_series,
+};
+
static const struct ec_board_info board_info_crosshair_x670e_gene = {
.sensors = SENSOR_TEMP_CPU | SENSOR_TEMP_CPU_PACKAGE |
SENSOR_TEMP_T_SENSOR |
@@ -825,6 +834,8 @@ static const struct dmi_system_id dmi_table[] = {
&board_info_crosshair_viii_hero),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR VIII IMPACT",
&board_info_crosshair_viii_impact),
+ DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR X670E EXTREME",
+ &board_info_crosshair_x670e_extreme),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR X670E GENE",
&board_info_crosshair_x670e_gene),
DMI_EXACT_MATCH_ASUS_BOARD_NAME("ROG CROSSHAIR X670E HERO",
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] docs: maintainer-netdev: fix typo in "targeting"
From: Breno Leitao @ 2026-04-20 13:35 UTC (permalink / raw)
To: Ariful Islam Shoikot; +Cc: netdev, linux-doc, workflows, linux-kernel
In-Reply-To: <20260420114554.1026-1-islamarifulshoikat@gmail.com>
On Mon, Apr 20, 2026 at 05:45:53PM +0600, Ariful Islam Shoikot wrote:
> Fix spelling mistake "targgeting" -> "targeting" in
> maintainer-netdev.rst
>
> No functional change.
>
> Signed-off-by: Ariful Islam Shoikot <islamarifulshoikat@gmail.com>
Reviewed-by: Breno Leitao <leitao@debian.org>
^ permalink raw reply
* Re: [PATCH v7 3/4] KVM: arm64: PMU: Introduce FIXED_COUNTERS_ONLY
From: Marc Zyngier @ 2026-04-20 13:53 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Oliver Upton, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
kvmarm, linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <ad44c69e-2f99-4f31-81b4-faae52eea080@rsg.ci.i.u-tokyo.ac.jp>
On Mon, 20 Apr 2026 13:07:15 +0100,
Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
>
> On 2026/04/20 18:51, Marc Zyngier wrote:
> > On Mon, 20 Apr 2026 09:36:16 +0100,
> > Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
> >>
> >> On 2026/04/20 2:19, Marc Zyngier wrote:
> >>> On Sat, 18 Apr 2026 09:14:25 +0100,
> >>> Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> wrote:
> >>>>
> >>>> On a heterogeneous arm64 system, KVM's PMU emulation is based on the
> >>>> features of a single host PMU instance. When a vCPU is migrated to a
> >>>> pCPU with an incompatible PMU, counters such as PMCCNTR_EL0 stop
> >>>> incrementing.
> >>>>
> >>>> Although this behavior is permitted by the architecture, Windows does
> >>>> not handle it gracefully and may crash with a division-by-zero error.
> >>>>
> >>>> The current workaround requires VMMs to pin vCPUs to a set of pCPUs
> >>>> that share a compatible PMU. This is difficult to implement correctly in
> >>>> QEMU/libvirt, where pinning occurs after vCPU initialization, and it
> >>>> also restricts the guest to a subset of available pCPUs.
> >>>>
> >>>> Introduce the KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY attribute to
> >>>> create a "fixed-counters-only" PMU. When set, KVM exposes a PMU that is
> >>>> compatible with all pCPUs but that does not support programmable
> >>>> event counters which may have different feature sets on different PMUs.
> >>>>
> >>>> This allows Windows guests to run reliably on heterogeneous systems
> >>>> without crashing, even without vCPU pinning, and enables VMMs to
> >>>> schedule vCPUs across all available pCPUs, making full use of the host
> >>>> hardware.
> >>>>
> >>>> Much like KVM_ARM_VCPU_PMU_V3_IRQ and other read-write attributes, this
> >>>> attribute provides a getter that facilitates kernel and userspace
> >>>> debugging/testing.
> >>>
> >>> OK, so that's the sales pitch. But how is it implemented? I would like
> >>> to be able to read a high-level description of the implementation
> >>> trade-offs.
> >>
> >> Implementation-wise it is very trivial. Essentially the following
> >> addition in kvm_arm_pmu_v3_get_attr() is the entire implementation:
> >> + case KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY:
> >> + if (test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY,
> >> &vcpu->kvm->arch.flags))
> >> + return 0;
> >>
> >> Both its functionality and code complexity is trivial. So we can argue that:
> >> - the functionality is too trivial to be useful or
> >> - the interface/implementation complexity is so trivial that it does not
> >> incur maintenance burden
> >>
> >> In this case the selftest uses the getter so I was more inclined to
> >> have it, but adding one just for the selftest sounds too ad-hoc, so
> >> here I looked into other attributes to ensure that it was not
> >> introducing inconsistency with existing interfaces.
> >>
> >> As the result, I found there are other read-write attributes; in fact
> >> there are more read-write attributes than write-only ones.
> >
> > You're completely missing the point. I'm referring to the whole of the
> > commit message, which is more of a marketing slide than a technical
> > description.
>
> In terms of implementation, the obvious tradeoff is that it adds more
> code to implement the feature. One thing to note is that
> kvm_vcpu_load_pmu() is added and is called each time a vCPU migrates
> across pCPUs. The heavy part, making the KVM_REQ_RELOAD_PMU request,
> only happens when the feature is enabled.
Well, that's what I want to see. The repeated blurb about Windows
being broken is cover letter material, but not fir for a commit
message.
[...]
> >>> "for the first time" gives the impression that it will work if you try
> >>> again. I'd rather we say that "This feature is incompatible with the
> >>> existence of a PMU event filter".
> >>
> >> The following sequence will work:
> >> 1. Set KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
> >> 2. Set KVM_ARM_VCPU_PMU_V3_FILTER
> >> 3. Set KVM_ARM_VCPU_PMU_V3_FIXED_COUNTERS_ONLY
> >>
> >> This is to make the behavior conistent with KVM_ARM_VCPU_PMU_V3_SET_PMU.
> >
> > I don't think this is correct. Filtering is completely at odds with
> > this patch, and I don't want to have to reason about the combination.
>
> kvm_arm_pmu_v3_set_pmu() has the following condition:
>
> if (kvm_vm_has_ran_once(kvm) ||
> (kvm->arch.pmu_filter && kvm->arch.arm_pmu != arm_pmu)) {
> ret = -EBUSY;
> break;
> }
>
> kvm_arm_pmu_v3_set_pmu_fixed_counters_only() has the corresponding
> condition for consistency:
>
> if (kvm_vm_has_ran_once(kvm) ||
> (kvm->arch.pmu_filter &&
> !test_bit(KVM_ARCH_FLAG_PMU_V3_FIXED_COUNTERS_ONLY,
> &kvm->arch.flags)))
> return -EBUSY;
>
> We can of course kill the PMU event filter for
> FIXED_COUNTERS_ONLY. The filter is effectively no-op with
> FIXED_COUNTERS_ONLY and I don't think that consistency matters much.
We shouldn't allow weird combinations in the UAPI. Since it makes no
sense to have both fixed-function *and* filters, we should make them
mutually exclusive.
[...]
> >> I expect migration will be handled with the conventional register
> >> getters and setters, but please share if you have a concern.
> >
> > At the very least I want to see some documentation explaining that.
>
> What kind of documentation do you expect?
A description of what counters are exposed by this feature, and what
architectural features they are dependent on.
> If we change kvm_vcpu_load_pmu() to avoid for_each_set_bit(), there
> would be a good chance to forget updating it when mechanically
> updating existing for_each_set_bit() instances, so it is a candidate
> for documentation. But I don't have a good idea where to place it
> either.
The moment we introduce FEAT_PMUv3_ICNTR, the whole PMUv3 emulation
will catch fire anyway, as we already limit ourselves to 32 bits for
reset and nesting switch.
So this will be a major redesign anyway. If you are really worried,
leave a comment in there.
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH 7.2 v16 04/13] mm/khugepaged: generalize __collapse_huge_page_* for mTHP support
From: Usama Arif @ 2026-04-20 13:55 UTC (permalink / raw)
To: Nico Pache
Cc: Usama Arif, linux-doc, linux-kernel, linux-mm, linux-trace-kernel,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, ljs, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260419185750.260784-5-npache@redhat.com>
On Sun, 19 Apr 2026 12:57:41 -0600 Nico Pache <npache@redhat.com> wrote:
> generalize the order of the __collapse_huge_page_* and collapse_max_*
> functions to support future mTHP collapse.
>
> The current mechanism for determining collapse with the
> khugepaged_max_ptes_none value is not designed with mTHP in mind. This
> raises a key design issue: if we support user defined max_pte_none values
> (even those scaled by order), a collapse of a lower order can introduces
> an feedback loop, or "creep", when max_ptes_none is set to a value greater
> than HPAGE_PMD_NR / 2.
>
> With this configuration, a successful collapse to order N will populate
> enough pages to satisfy the collapse condition on order N+1 on the next
> scan. This leads to unnecessary work and memory churn.
>
> To fix this issue introduce a helper function that will limit mTHP
> collapse support to two max_ptes_none values, 0 and HPAGE_PMD_NR - 1.
> This effectively supports two modes:
>
> - max_ptes_none=0: never introduce new none-pages for mTHP collapse.
> - max_ptes_none=511 (on 4k pagesz): Always collapse to the highest
> available mTHP order.
>
> This removes the possiblilty of "creep", while not modifying any uAPI
> expectations. A warning will be emitted if any non-supported
> max_ptes_none value is configured with mTHP enabled.
>
> mTHP collapse will not honor the khugepaged_max_ptes_shared or
> khugepaged_max_ptes_swap parameters, and will fail if it encounters a
> shared or swapped entry.
>
> No functional changes in this patch; however it defines future behavior
> for mTHP collapse.
>
> Co-developed-by: Dev Jain <dev.jain@arm.com>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> mm/khugepaged.c | 124 ++++++++++++++++++++++++++++++++++--------------
> 1 file changed, 88 insertions(+), 36 deletions(-)
>
Small nits. Most might not need change.
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index f42b55421191..283bb63854a5 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -352,51 +352,86 @@ static bool pte_none_or_zero(pte_t pte)
> * collapse_max_ptes_none - Calculate maximum allowed empty PTEs for collapse
> * @cc: The collapse control struct
> * @vma: The vma to check for userfaultfd
> + * @order: The folio order being collapsed to
> *
> * If we are not in khugepaged mode use HPAGE_PMD_NR to allow any
> - * empty page.
> + * empty page. For PMD-sized collapses (order == HPAGE_PMD_ORDER), use the
> + * configured khugepaged_max_ptes_none value.
> + *
> + * For mTHP collapses, we currently only support khugepaged_max_pte_none values
> + * of 0 or (KHUGEPAGED_MAX_PTES_LIMIT). Any other value will emit a warning and
> + * no mTHP collapse will be attempted
> *
> * Return: Maximum number of empty PTEs allowed for the collapse operation
> */
> -static unsigned int collapse_max_ptes_none(struct collapse_control *cc,
> - struct vm_area_struct *vma)
> +static int collapse_max_ptes_none(struct collapse_control *cc,
> + struct vm_area_struct *vma, unsigned int order)
> {
> if (vma && userfaultfd_armed(vma))
> return 0;
> if (!cc->is_khugepaged)
> return HPAGE_PMD_NR;
> - return khugepaged_max_ptes_none;
> + if (is_pmd_order(order))
> + return khugepaged_max_ptes_none;
> + /* Zero/non-present collapse disabled. */
> + if (!khugepaged_max_ptes_none)
> + return 0;
> + if (khugepaged_max_ptes_none == KHUGEPAGED_MAX_PTES_LIMIT)
> + return (1 << order) - 1;
> +
There are 2 reads of khugepaged_max_ptes_none here.
A concurrent sysctl write between reads can yield "0 then non-zero" or "LIMIT
then mid-value".
Would be good to just snapshot once at the start of the function and use that
value?
> + pr_warn_once("mTHP collapse only supports max_ptes_none values of 0 or %u\n",
> + KHUGEPAGED_MAX_PTES_LIMIT);
IMO, warn_once can get lost quickly in dmesg. Maybe pr_warn_ratelimited?
Not sure what others opinions are..
> + return -EINVAL;
> }
>
> /**
> * collapse_max_ptes_shared - Calculate maximum allowed shared PTEs for collapse
> * @cc: The collapse control struct
> + * @order: The folio order being collapsed to
> *
> * If we are not in khugepaged mode use HPAGE_PMD_NR to allow any
> * shared page.
> *
> + * For mTHP collapses, we currently dont support collapsing memory with
> + * shared memory.
> + *
> * Return: Maximum number of shared PTEs allowed for the collapse operation
> */
> -static unsigned int collapse_max_ptes_shared(struct collapse_control *cc)
> +static unsigned int collapse_max_ptes_shared(struct collapse_control *cc,
> + unsigned int order)
> {
> if (!cc->is_khugepaged)
> return HPAGE_PMD_NR;
> + if (!is_pmd_order(order))
> + return 0;
> +
> return khugepaged_max_ptes_shared;
> }
>
> /**
> * collapse_max_ptes_swap - Calculate maximum allowed swap PTEs for collapse
> * @cc: The collapse control struct
> + * @order: The folio order being collapsed to
> *
> * If we are not in khugepaged mode use HPAGE_PMD_NR to allow any
> * swap page.
> *
> + * For PMD-sized collapses (order == HPAGE_PMD_ORDER), use the configured
> + * khugepaged_max_ptes_swap value.
> + *
> + * For mTHP collapses, we currently dont support collapsing memory with
> + * swapped out memory.
> + *
> * Return: Maximum number of swap PTEs allowed for the collapse operation
> */
> -static unsigned int collapse_max_ptes_swap(struct collapse_control *cc)
> +static unsigned int collapse_max_ptes_swap(struct collapse_control *cc,
> + unsigned int order)
> {
> if (!cc->is_khugepaged)
> return HPAGE_PMD_NR;
> + if (!is_pmd_order(order))
> + return 0;
> +
> return khugepaged_max_ptes_swap;
> }
>
> @@ -590,18 +625,22 @@ static void release_pte_pages(pte_t *pte, pte_t *_pte,
>
> static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma,
> unsigned long start_addr, pte_t *pte, struct collapse_control *cc,
> - struct list_head *compound_pagelist)
> + unsigned int order, struct list_head *compound_pagelist)
> {
> + const unsigned long nr_pages = 1UL << order;
> struct page *page = NULL;
> struct folio *folio = NULL;
> unsigned long addr = start_addr;
> pte_t *_pte;
> int none_or_zero = 0, shared = 0, referenced = 0;
> enum scan_result result = SCAN_FAIL;
> - unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma);
> - unsigned int max_ptes_shared = collapse_max_ptes_shared(cc);
> + int max_ptes_none = collapse_max_ptes_none(cc, vma, order);
> + unsigned int max_ptes_shared = collapse_max_ptes_shared(cc, order);
> +
> + if (max_ptes_none < 0)
> + return result;
Would a dedicated SCAN_INVALID_PTES_NONE make more sense here instead
of SCAN_FAIL?
>
> - for (_pte = pte; _pte < pte + HPAGE_PMD_NR;
> + for (_pte = pte; _pte < pte + nr_pages;
> _pte++, addr += PAGE_SIZE) {
> pte_t pteval = ptep_get(_pte);
> if (pte_none_or_zero(pteval)) {
> @@ -734,18 +773,18 @@ static enum scan_result __collapse_huge_page_isolate(struct vm_area_struct *vma,
> }
>
> static void __collapse_huge_page_copy_succeeded(pte_t *pte,
> - struct vm_area_struct *vma,
> - unsigned long address,
> - spinlock_t *ptl,
> - struct list_head *compound_pagelist)
> + struct vm_area_struct *vma, unsigned long address,
> + spinlock_t *ptl, unsigned int order,
> + struct list_head *compound_pagelist)
> {
> - unsigned long end = address + HPAGE_PMD_SIZE;
> + const unsigned long nr_pages = 1UL << order;
> + unsigned long end = address + (PAGE_SIZE << order);
> struct folio *src, *tmp;
> pte_t pteval;
> pte_t *_pte;
> unsigned int nr_ptes;
>
> - for (_pte = pte; _pte < pte + HPAGE_PMD_NR; _pte += nr_ptes,
> + for (_pte = pte; _pte < pte + nr_pages; _pte += nr_ptes,
> address += nr_ptes * PAGE_SIZE) {
> nr_ptes = 1;
> pteval = ptep_get(_pte);
> @@ -798,13 +837,11 @@ static void __collapse_huge_page_copy_succeeded(pte_t *pte,
> }
>
> static void __collapse_huge_page_copy_failed(pte_t *pte,
> - pmd_t *pmd,
> - pmd_t orig_pmd,
> - struct vm_area_struct *vma,
> - struct list_head *compound_pagelist)
> + pmd_t *pmd, pmd_t orig_pmd, struct vm_area_struct *vma,
> + unsigned int order, struct list_head *compound_pagelist)
> {
> + const unsigned long nr_pages = 1UL << order;
> spinlock_t *pmd_ptl;
> -
Shouldn't remove the newline above?
> /*
> * Re-establish the PMD to point to the original page table
> * entry. Restoring PMD needs to be done prior to releasing
> @@ -818,7 +855,7 @@ static void __collapse_huge_page_copy_failed(pte_t *pte,
> * Release both raw and compound pages isolated
> * in __collapse_huge_page_isolate.
> */
> - release_pte_pages(pte, pte + HPAGE_PMD_NR, compound_pagelist);
> + release_pte_pages(pte, pte + nr_pages, compound_pagelist);
> }
>
> /*
> @@ -838,16 +875,16 @@ static void __collapse_huge_page_copy_failed(pte_t *pte,
> */
> static enum scan_result __collapse_huge_page_copy(pte_t *pte, struct folio *folio,
> pmd_t *pmd, pmd_t orig_pmd, struct vm_area_struct *vma,
> - unsigned long address, spinlock_t *ptl,
> + unsigned long address, spinlock_t *ptl, unsigned int order,
> struct list_head *compound_pagelist)
> {
> + const unsigned long nr_pages = 1UL << order;
> unsigned int i;
> enum scan_result result = SCAN_SUCCEED;
> -
Same here?
> /*
> * Copying pages' contents is subject to memory poison at any iteration.
> */
> - for (i = 0; i < HPAGE_PMD_NR; i++) {
> + for (i = 0; i < nr_pages; i++) {
> pte_t pteval = ptep_get(pte + i);
> struct page *page = folio_page(folio, i);
> unsigned long src_addr = address + i * PAGE_SIZE;
> @@ -866,10 +903,10 @@ static enum scan_result __collapse_huge_page_copy(pte_t *pte, struct folio *foli
>
> if (likely(result == SCAN_SUCCEED))
> __collapse_huge_page_copy_succeeded(pte, vma, address, ptl,
> - compound_pagelist);
> + order, compound_pagelist);
> else
> __collapse_huge_page_copy_failed(pte, pmd, orig_pmd, vma,
> - compound_pagelist);
> + order, compound_pagelist);
>
> return result;
> }
> @@ -1040,12 +1077,12 @@ static enum scan_result check_pmd_still_valid(struct mm_struct *mm,
> * Returns result: if not SCAN_SUCCEED, mmap_lock has been released.
> */
> static enum scan_result __collapse_huge_page_swapin(struct mm_struct *mm,
> - struct vm_area_struct *vma, unsigned long start_addr, pmd_t *pmd,
> - int referenced)
> + struct vm_area_struct *vma, unsigned long start_addr,
> + pmd_t *pmd, int referenced, unsigned int order)
Will probably find out in later reviews, but there is tracepoint in __collapse_huge_page_swapin.
Would be good to add order in that tracepoint if you are adding order here?
> {
> int swapped_in = 0;
> vm_fault_t ret = 0;
> - unsigned long addr, end = start_addr + (HPAGE_PMD_NR * PAGE_SIZE);
> + unsigned long addr, end = start_addr + (PAGE_SIZE << order);
> enum scan_result result;
> pte_t *pte = NULL;
> spinlock_t *ptl;
> @@ -1077,6 +1114,19 @@ static enum scan_result __collapse_huge_page_swapin(struct mm_struct *mm,
> pte_present(vmf.orig_pte))
> continue;
>
> + /*
> + * TODO: Support swapin without leading to further mTHP
> + * collapses. Currently bringing in new pages via swapin may
> + * cause a future higher order collapse on a rescan of the same
> + * range.
> + */
> + if (!is_pmd_order(order)) {
Would it be good to introduce this in the patch that activates it? No strong
preference btw. Just that its dead code in this patch itself.
> + pte_unmap(pte);
> + mmap_read_unlock(mm);
> + result = SCAN_EXCEED_SWAP_PTE;
> + goto out;
> + }
> +
> vmf.pte = pte;
> vmf.ptl = ptl;
> ret = do_swap_page(&vmf);
> @@ -1196,7 +1246,7 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
> * that case. Continuing to collapse causes inconsistency.
> */
> result = __collapse_huge_page_swapin(mm, vma, address, pmd,
> - referenced);
> + referenced, HPAGE_PMD_ORDER);
> if (result != SCAN_SUCCEED)
> goto out_nolock;
> }
> @@ -1244,6 +1294,7 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
> pte = pte_offset_map_lock(mm, &_pmd, address, &pte_ptl);
> if (pte) {
> result = __collapse_huge_page_isolate(vma, address, pte, cc,
> + HPAGE_PMD_ORDER,
> &compound_pagelist);
> spin_unlock(pte_ptl);
> } else {
> @@ -1274,6 +1325,7 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
>
> result = __collapse_huge_page_copy(pte, folio, pmd, _pmd,
> vma, address, pte_ptl,
> + HPAGE_PMD_ORDER,
> &compound_pagelist);
> pte_unmap(pte);
> if (unlikely(result != SCAN_SUCCEED))
> @@ -1318,9 +1370,9 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> unsigned long addr;
> spinlock_t *ptl;
> int node = NUMA_NO_NODE, unmapped = 0;
> - unsigned int max_ptes_none = collapse_max_ptes_none(cc, vma);
> - unsigned int max_ptes_shared = collapse_max_ptes_shared(cc);
> - unsigned int max_ptes_swap = collapse_max_ptes_swap(cc);
> + int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> + unsigned int max_ptes_shared = collapse_max_ptes_shared(cc, HPAGE_PMD_ORDER);
> + unsigned int max_ptes_swap = collapse_max_ptes_swap(cc, HPAGE_PMD_ORDER);
>
> VM_BUG_ON(start_addr & ~HPAGE_PMD_MASK);
>
> @@ -2371,8 +2423,8 @@ static enum scan_result collapse_scan_file(struct mm_struct *mm,
> int present, swap;
> int node = NUMA_NO_NODE;
> enum scan_result result = SCAN_SUCCEED;
> - unsigned int max_ptes_none = collapse_max_ptes_none(cc, NULL);
> - unsigned int max_ptes_swap = collapse_max_ptes_swap(cc);
> + int max_ptes_none = collapse_max_ptes_none(cc, NULL, HPAGE_PMD_ORDER);
> + unsigned int max_ptes_swap = collapse_max_ptes_swap(cc, HPAGE_PMD_ORDER);
>
> present = 0;
> swap = 0;
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH] docs/zh_CN: restructure how-to.rst patch submission workflow
From: Yanteng Si @ 2026-04-20 14:09 UTC (permalink / raw)
To: Dongliang Mu, Alex Shi, Jonathan Corbet, Shuah Khan
Cc: linux-doc, linux-kernel
In-Reply-To: <20260420115647.2718959-1-dzm91@hust.edu.cn>
在 2026/4/20 19:56, Dongliang Mu 写道:
> Split "导出补丁和制作封面" into separate "导出补丁" and
> "为补丁集制作封面" sections, and document the single-patch
> (git format-patch -1) and multi-patch (-N) flows side by side
> so new contributors do not have to infer one from the other.
>
> Replace the invalid "git am --amend" invocations with "git commit
> --amend" in both the checkpatch fix-up and the iteration sections.
>
> Expand the iteration section with a worked v2 example showing where the
> changelog goes relative to the --- separator, and describe how v3/v4
> changelogs stack newest-on-top.
>
> Finally, add a note reminding submitters to carry Reviewed-by tags from
> reviewers into the next revision, placed below Signed-off-by.
>
> Assisted-by: Claude:claude-opus-4-7
> Signed-off-by: Dongliang Mu <dzm91@hust.edu.cn>
Reviewed-by: Yanteng Si <si.yanteng@linux.dev>
Thanks
Yanteng
> ---
> Documentation/translations/zh_CN/how-to.rst | 105 ++++++++++++++------
> 1 file changed, 77 insertions(+), 28 deletions(-)
>
> diff --git a/Documentation/translations/zh_CN/how-to.rst b/Documentation/translations/zh_CN/how-to.rst
> index 3dcf6754d1df..9ec2384e1e76 100644
> --- a/Documentation/translations/zh_CN/how-to.rst
> +++ b/Documentation/translations/zh_CN/how-to.rst
> @@ -269,13 +269,22 @@ Git 和邮箱配置
> **请注意** 以上四行，缺少任何一行，您都将会在第一轮审阅后返工，如果您需要一个
> 更加明确的示例，请对 zh_CN 目录执行 git log。
>
> -导出补丁和制作封面
> -------------------
> +导出补丁
> +--------
> +
> +这个时候，可以导出补丁，做发送邮件列表最后的准备了。对于单个补丁，
> +命令行执行::
> +
> + git format-patch -1
> +
> +然后命令行会输出类似下面的内容::
> +
> + 0001-docs-zh_CN-add-xxxxxxxx.patch
>
> -这个时候，可以导出补丁，做发送邮件列表最后的准备了。命令行执行::
> +如果您有多个补丁，命令行执行::
>
> git format-patch -N
> - # N 要替换为补丁数量，一般 N 大于等于 1
> + # N 要替换为补丁数量，一般 N 大于 1
>
> 然后命令行会输出类似下面的内容::
>
> @@ -290,13 +299,12 @@ Git 和邮箱配置
>
> ./scripts/checkpatch.pl *.patch
>
> -参考脚本输出，解决掉所有的 error 和 warning，通常情况下，只有下面这个
> +参考脚本输出，解决掉所有的 error 和 warning。通常情况下，只有下面这个
> warning 不需要解决::
>
> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
>
> -一个简单的解决方法是一次只检查一个补丁，然后打上该补丁，直接对译文进行修改，
> -然后执行以下命令为补丁追加更改::
> +对于单个补丁，解决方案很简单，只需要打上该补丁，直接对译文进行修改，为补丁追加后续更改::
>
> git checkout docs-next
> git checkout -b test-trans-new
> @@ -304,15 +312,21 @@ warning 不需要解决::
> ./scripts/checkpatch.pl 0001-xxxxx.patch
> # 直接修改您的翻译
> git add .
> - git am --amend
> + git commit --amend
> # 保存退出
> - git am 0002-xxxxx.patch
> - ……
>
> -重新导出再次检测，重复这个过程，直到处理完所有的补丁。
> +随后，重新导出补丁再次检测，重复这个过程，直到处理完所有 warning 和
> +error。
> +
> +如果您有多个补丁，请按补丁集中补丁顺序对每个补丁重复上述流程，一次只处理
> +一个，不要一次 git am 多个补丁。全部处理完毕后再重新导出并再次测试。
>
> -最后，如果检测时没有需要处理的 warning 和 error，或者您只有一个补丁，请
> -跳过下面这个步骤，否则请重新导出补丁制作封面::
> +为补丁集制作封面
> +----------------
> +
> +对于单个补丁，请跳过本节。
> +
> +如果您有多个补丁，则需要为补丁集制作一份封面，即 0 号补丁::
>
> git format-patch -N --cover-letter --thread=shallow
> # N 要替换为补丁数量，一般 N 大于 1
> @@ -329,18 +343,14 @@ warning 不需要解决::
> vim 0000-cover-letter.patch
>
> ...
> - Subject: [PATCH 0/N] *** SUBJECT HERE *** #修改该字段，概括您的补丁集都做了哪些事情
> + Subject: [PATCH 0/N] *** SUBJECT HERE *** # 修改该字段，概括您的补丁集都做了哪些事情
>
> - *** BLURB HERE *** #修改该字段，详细描述您的补丁集做了哪些事情
> + *** BLURB HERE *** # 修改该字段，详细描述您的补丁集做了哪些事情
>
> Yanteng Si (1):
> docs/zh_CN: add xxxxx
> ...
>
> -如果您只有一个补丁，则无需制作封面（即 0 号补丁），只需执行::
> -
> - git format-patch -1
> -
> 把补丁提交到邮件列表
> ====================
>
> @@ -392,28 +402,67 @@ reviewer 的评论，做到每条都有回复，每个回复都落实到位。
> 迭代补丁
> --------
>
> -建议您每回复一条评论，就修改一处翻译。然后重新生成补丁，相信您现在已经具
> -备了灵活使用 git am --amend 的能力。
> +建议您每回复一条评论，就修改一处翻译，然后重新生成补丁，相信您现在
> +已经具备了灵活使用 git am 与 git commit --amend 的能力。
>
> -每次迭代一个补丁，不要一次多个::
> +对于单个补丁，每回复完评论后修改、追加::
>
> - git am <您要修改的补丁>
> + git am 0001-xxxxx.patch
> # 直接对文件进行您的修改
> git add .
> git commit --amend
>
> -当您将所有的评论落实到位后，导出第二版补丁，并修改封面::
> +当您将所有的评论落实到位后，导出第二版补丁::
>
> - git format-patch -N -v 2 --cover-letter --thread=shallow
> + git format-patch -1 -v 2
> +
> +命令行会输出 v2-0001-xxxxx.patch。打开该文件，在 --- 分割线下方追加
> +changelog。注意，分割线以下的内容不会进入 git 提交历史，仅作为邮件中的
> +说明供 reviewer 检查::
> +
> + Subject: [PATCH v2] docs/zh_CN: add xxxxxx translation
> +
> + Translate .../xxx.rst into Chinese.
> +
> + Signed-off-by: Yanteng Si <si.yanteng@linux.dev>
> + ---
> + v1->v2:
> + - 修正第二节的错别字，Reviewer-A 提出的意见
> + - 根据 Reviewer-B 的建议调整段落顺序
>
> -打开 0 号补丁，在 BLURB HERE 处编写相较于上个版本，您做了哪些改动。
> + Documentation/translations/zh_CN/xxx.rst | 100 ++++++
> + 1 file changed, 100 insertions(+)
>
> -然后执行::
> +后续迭代 v3、v4 …… 时，新的 changelog 放在最上面，旧的保留在下方，按
> +从新到旧的顺序叠加。例如 v3 补丁的 --- 下方::
>
> - git send-email v2* --to <maintainer email addr> --cc <others addr>
> + ---
> + v2->v3:
> + - ...本次相较 v2 的改动...
> + v1->v2:
> + - ...上一次相较 v1 的改动...
> +
> +然后发送::
> +
> + git send-email v2-0001-*.patch --to <maintainer email addr> --cc <others addr>
> +
> +如果您有多个补丁，迭代时请按以下原则：每次只迭代一个补丁，不要一次多个，
> +每个补丁独立重复上述流程。所有评论落实到位后，导出 v2 时附带封面::
> +
> + git format-patch -N -v 2 --cover-letter --thread=shallow
> +
> +打开 0 号补丁，在 BLURB HERE 处写明整组补丁相较 v1 的总体改动，格式
> +同上面的单个补丁 changelog 示例。如果某个补丁需要单独说明，可在该
> +补丁文件的 --- 分割线下方追加单个补丁的 changelog。最后执行::
> +
> + git send-email v2-*.patch --to <maintainer email addr> --cc <others addr>
>
> 这样，新的一版补丁就又发送到邮件列表等待审阅，之后就是重复这个过程。
>
> +此外，如果审阅者或维护者在邮件回复中给出了 Reviewed-by tag，请在下
> +一版补丁的 commit 信息中加入该 tag，放在 Signed-off-by 行的下方，以
> +便维护者合入时保留您的审阅记录。
> +
> 审阅周期
> --------
>
^ permalink raw reply
* Re: [PATCH 7.2 v16 05/13] mm/khugepaged: generalize collapse_huge_page for mTHP collapse
From: Usama Arif @ 2026-04-20 14:20 UTC (permalink / raw)
To: Nico Pache
Cc: Usama Arif, linux-doc, linux-kernel, linux-mm, linux-trace-kernel,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, ljs, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260419185750.260784-6-npache@redhat.com>
On Sun, 19 Apr 2026 12:57:42 -0600 Nico Pache <npache@redhat.com> wrote:
> Pass an order and offset to collapse_huge_page to support collapsing anon
> memory to arbitrary orders within a PMD. order indicates what mTHP size we
> are attempting to collapse to, and offset indicates were in the PMD to
> start the collapse attempt.
>
> For non-PMD collapse we must leave the anon VMA write locked until after
> we collapse the mTHP-- in the PMD case all the pages are isolated, but in
> the mTHP case this is not true, and we must keep the lock to prevent
> access/changes to the page tables. This can happen if the rmap walkers hit
> a pmd_none while the PMD entry is currently unavailable due to being
> temporarily removed during the collapse phase.
>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> mm/khugepaged.c | 103 +++++++++++++++++++++++++++---------------------
> 1 file changed, 57 insertions(+), 46 deletions(-)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index 283bb63854a5..ff6f9f1883ed 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -1198,42 +1198,36 @@ static enum scan_result alloc_charge_folio(struct folio **foliop, struct mm_stru
> return SCAN_SUCCEED;
> }
>
> -static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long address,
> - int referenced, int unmapped, struct collapse_control *cc)
> +static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long start_addr,
> + int referenced, int unmapped, struct collapse_control *cc,
> + unsigned int order)
> {
> LIST_HEAD(compound_pagelist);
> pmd_t *pmd, _pmd;
> - pte_t *pte;
> + pte_t *pte = NULL;
> pgtable_t pgtable;
> struct folio *folio;
> spinlock_t *pmd_ptl, *pte_ptl;
> enum scan_result result = SCAN_FAIL;
> struct vm_area_struct *vma;
> struct mmu_notifier_range range;
> + bool anon_vma_locked = false;
> + const unsigned long pmd_addr = start_addr & HPAGE_PMD_MASK;
> + const unsigned long end_addr = start_addr + (PAGE_SIZE << order);
>
> - VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> -
> - /*
> - * Before allocating the hugepage, release the mmap_lock read lock.
> - * The allocation can take potentially a long time if it involves
> - * sync compaction, and we do not need to hold the mmap_lock during
> - * that. We will recheck the vma after taking it again in write mode.
> - */
> - mmap_read_unlock(mm);
> -
My understanding now is that the caller will need to drop the mmap_read lock?
This needs explicit documentation at the start of the function IMO. I think
there are callers in later patches and its very easy to miss this.
> - result = alloc_charge_folio(&folio, mm, cc, HPAGE_PMD_ORDER);
> + result = alloc_charge_folio(&folio, mm, cc, order);
> if (result != SCAN_SUCCEED)
> goto out_nolock;
>
> mmap_read_lock(mm);
> - result = hugepage_vma_revalidate(mm, address, true, &vma, cc,
> - HPAGE_PMD_ORDER);
> + result = hugepage_vma_revalidate(mm, pmd_addr, /*expect_anon=*/ true,
> + &vma, cc, order);
> if (result != SCAN_SUCCEED) {
> mmap_read_unlock(mm);
> goto out_nolock;
> }
>
> - result = find_pmd_or_thp_or_none(mm, address, &pmd);
> + result = find_pmd_or_thp_or_none(mm, pmd_addr, &pmd);
> if (result != SCAN_SUCCEED) {
> mmap_read_unlock(mm);
> goto out_nolock;
> @@ -1245,8 +1239,8 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
> * released when it fails. So we jump out_nolock directly in
> * that case. Continuing to collapse causes inconsistency.
> */
> - result = __collapse_huge_page_swapin(mm, vma, address, pmd,
> - referenced, HPAGE_PMD_ORDER);
> + result = __collapse_huge_page_swapin(mm, vma, start_addr, pmd,
> + referenced, order);
> if (result != SCAN_SUCCEED)
> goto out_nolock;
> }
> @@ -1261,20 +1255,21 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
> * mmap_lock.
> */
> mmap_write_lock(mm);
> - result = hugepage_vma_revalidate(mm, address, true, &vma, cc,
> - HPAGE_PMD_ORDER);
> + result = hugepage_vma_revalidate(mm, pmd_addr, /*expect_anon=*/ true,
> + &vma, cc, order);
> if (result != SCAN_SUCCEED)
> goto out_up_write;
> /* check if the pmd is still valid */
> vma_start_write(vma);
> - result = check_pmd_still_valid(mm, address, pmd);
> + result = check_pmd_still_valid(mm, pmd_addr, pmd);
> if (result != SCAN_SUCCEED)
> goto out_up_write;
>
> anon_vma_lock_write(vma->anon_vma);
> + anon_vma_locked = true;
>
> - mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, mm, address,
> - address + HPAGE_PMD_SIZE);
> + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, mm, start_addr,
> + end_addr);
> mmu_notifier_invalidate_range_start(&range);
>
> pmd_ptl = pmd_lock(mm, pmd); /* probably unnecessary */
> @@ -1286,26 +1281,23 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
> * Parallel GUP-fast is fine since GUP-fast will back off when
> * it detects PMD is changed.
> */
> - _pmd = pmdp_collapse_flush(vma, address, pmd);
> + _pmd = pmdp_collapse_flush(vma, pmd_addr, pmd);
For an mTHP collapse covering, say, 64KiB of a 2MiB PMD, the patch still
flushes the entire PMD via pmdp_collapse_flush and tlb_remove_table_sync_one.
That triggers cross-CPU TLB shootdowns for ~1.94MiB of unrelated mappings on
every successful sub-PMD collapse. Probably acceptable as a first cut?
> spin_unlock(pmd_ptl);
> mmu_notifier_invalidate_range_end(&range);
> tlb_remove_table_sync_one();
>
> - pte = pte_offset_map_lock(mm, &_pmd, address, &pte_ptl);
> + pte = pte_offset_map_lock(mm, &_pmd, start_addr, &pte_ptl);
> if (pte) {
> - result = __collapse_huge_page_isolate(vma, address, pte, cc,
> - HPAGE_PMD_ORDER,
> - &compound_pagelist);
> + result = __collapse_huge_page_isolate(vma, start_addr, pte, cc,
> + order, &compound_pagelist);
> spin_unlock(pte_ptl);
> } else {
> result = SCAN_NO_PTE_TABLE;
> }
>
> if (unlikely(result != SCAN_SUCCEED)) {
> - if (pte)
> - pte_unmap(pte);
> spin_lock(pmd_ptl);
> - BUG_ON(!pmd_none(*pmd));
> + WARN_ON_ONCE(!pmd_none(*pmd));
Why was this turned into WARN_ON_ONCE? Would be good to add to commit message
what the reason is if it has been discussed earlier.
The next line writes a PMD entry over an existing one — that leaks the
previous page table or PMD-mapped folio and can corrupt VA mappings. BUG_ON
failed loudly and safely; WARN_ON_ONCE continues into the corruption and falls
silent after the first hit.
> /*
> * We can only use set_pmd_at when establishing
> * hugepmds and never for establishing regular pmds that
> @@ -1313,21 +1305,24 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
> */
> pmd_populate(mm, pmd, pmd_pgtable(_pmd));
> spin_unlock(pmd_ptl);
> - anon_vma_unlock_write(vma->anon_vma);
> goto out_up_write;
> }
>
> /*
> - * All pages are isolated and locked so anon_vma rmap
> - * can't run anymore.
> + * For PMD collapse all pages are isolated and locked so anon_vma
> + * rmap can't run anymore. For mTHP collapse the PMD entry has been
> + * removed and not all pages are isolated and locked, so we must hold
> + * the lock to prevent neighboring folios from attempting to access
> + * this PMD until its reinstalled.
> */
> - anon_vma_unlock_write(vma->anon_vma);
> + if (is_pmd_order(order)) {
> + anon_vma_unlock_write(vma->anon_vma);
> + anon_vma_locked = false;
> + }
>
> result = __collapse_huge_page_copy(pte, folio, pmd, _pmd,
> - vma, address, pte_ptl,
> - HPAGE_PMD_ORDER,
> - &compound_pagelist);
> - pte_unmap(pte);
> + vma, start_addr, pte_ptl,
> + order, &compound_pagelist);
> if (unlikely(result != SCAN_SUCCEED))
> goto out_up_write;
>
> @@ -1337,18 +1332,27 @@ static enum scan_result collapse_huge_page(struct mm_struct *mm, unsigned long a
> * write.
> */
> __folio_mark_uptodate(folio);
> - pgtable = pmd_pgtable(_pmd);
> -
> spin_lock(pmd_ptl);
> - BUG_ON(!pmd_none(*pmd));
> - pgtable_trans_huge_deposit(mm, pmd, pgtable);
> - map_anon_folio_pmd_nopf(folio, pmd, vma, address);
> + WARN_ON_ONCE(!pmd_none(*pmd));
> + if (is_pmd_order(order)) { /* PMD collapse */
> + pgtable = pmd_pgtable(_pmd);
> + pgtable_trans_huge_deposit(mm, pmd, pgtable);
> + map_anon_folio_pmd_nopf(folio, pmd, vma, pmd_addr);
> + } else { /* mTHP collapse */
> + map_anon_folio_pte_nopf(folio, pte, vma, start_addr, /*uffd_wp=*/ false);
map_anon_folio_pte_nopf calls set_ptes and modifies pagetable, while holding
pmd_ptl only. It should be safe as we expect pmd_none. But I think you should
put a comment about this?
> + smp_wmb(); /* make PTEs visible before PMD. See pmd_install() */
> + pmd_populate(mm, pmd, pmd_pgtable(_pmd));
> + }
> spin_unlock(pmd_ptl);
>
> folio = NULL;
>
> result = SCAN_SUCCEED;
> out_up_write:
> + if (anon_vma_locked)
> + anon_vma_unlock_write(vma->anon_vma);
> + if (pte)
> + pte_unmap(pte);
> mmap_write_unlock(mm);
> out_nolock:
> if (folio)
> @@ -1525,8 +1529,15 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> out_unmap:
> pte_unmap_unlock(pte, ptl);
> if (result == SCAN_SUCCEED) {
> + /*
> + * Before allocating the hugepage, release the mmap_lock read lock.
> + * The allocation can take potentially a long time if it involves
> + * sync compaction, and we do not need to hold the mmap_lock during
> + * that. We will recheck the vma after taking it again in write mode.
> + */
> + mmap_read_unlock(mm);
> result = collapse_huge_page(mm, start_addr, referenced,
> - unmapped, cc);
> + unmapped, cc, HPAGE_PMD_ORDER);
> /* collapse_huge_page will return with the mmap_lock released */
> *lock_dropped = true;
> }
> --
> 2.53.0
>
>
^ permalink raw reply
* [PATCH] Documentation: coding-assistants: add optional Acted-By: trailer
From: Blake Morrison @ 2026-04-20 14:27 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan
Cc: workflows, linux-doc, linux-kernel, Blake Morrison
The existing policy correctly separates AI tool attribution
(Assisted-by:) from legal accountability (Signed-off-by:). In practice,
contributors increasingly work across pseudonymous and legal-name
contexts, and a third slot -- identifying the human sovereign identity
under which the work was performed -- lets downstream tooling (CI,
provenance trackers, identity systems) bind a commit to a stable handle
without disturbing the DCO.
Add Acted-By: as an optional, informational companion trailer. It does
not replace Signed-off-by:, does not change DCO requirements, and does
not mandate any format; the out-of-tree
draft-morrison-identity-attributed-commits defines one such scheme, but
contributors are free to use any handle form they prefer.
The three trailers then map cleanly:
* Assisted-by: -- what tool drafted this
* Acted-By: -- who the human was, as a handle
* Signed-off-by: -- legal DCO attestation
This mirrors the informal separation already present in commits that
carry both a pseudonymous Reported-by: and a separate Signed-off-by:.
Signed-off-by: Blake Morrison <blake@truealter.com>
---
Documentation/process/coding-assistants.rst | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
index 899f4459c..b1d2d2f66 100644
--- a/Documentation/process/coding-assistants.rst
+++ b/Documentation/process/coding-assistants.rst
@@ -57,3 +57,16 @@ Basic development tools (git, gcc, make, editors) should not be listed.
Example::
Assisted-by: Claude:claude-3-opus coccinelle sparse
+
+Contributors may optionally add an ``Acted-By:`` tag identifying the
+human sovereign identity under which the work was performed, in a form
+stable across pseudonymous and legal-name contexts::
+
+ Acted-By: handle
+
+``Acted-By:`` is informational. It does not replace ``Signed-off-by:``;
+DCO attestation remains mandatory. Where ``Assisted-by:`` identifies
+*what tooling* contributed, ``Acted-By:`` identifies *who* the human
+was, as a stable handle. Handle format is out of scope for this
+document; draft-morrison-identity-attributed-commits in the IETF
+document stream describes one such scheme.
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v7 1/5] bug/kunit: Core support for suppressing warning backtraces
From: Peter Zijlstra @ 2026-04-20 14:39 UTC (permalink / raw)
To: Albert Esteve
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati, Guenter Roeck,
Kees Cook
In-Reply-To: <20260420-kunit_add_support-v7-1-e8bc6e0f70de@redhat.com>
On Mon, Apr 20, 2026 at 02:28:03PM +0200, Albert Esteve wrote:
> From: Alessandro Carminati <acarmina@redhat.com>
>
> Some unit tests intentionally trigger warning backtraces by passing bad
> parameters to kernel API functions. Such unit tests typically check the
> return value from such calls, not the existence of the warning backtrace.
>
> Such intentionally generated warning backtraces are neither desirable
> nor useful for a number of reasons:
> - They can result in overlooked real problems.
> - A warning that suddenly starts to show up in unit tests needs to be
> investigated and has to be marked to be ignored, for example by
> adjusting filter scripts. Such filters are ad hoc because there is
> no real standard format for warnings. On top of that, such filter
> scripts would require constant maintenance.
>
> Solve the problem by providing a means to identify and suppress specific
> warning backtraces while executing test code. Support suppressing multiple
> backtraces while at the same time limiting changes to generic code to the
> absolute minimum.
>
> Implementation details:
> Suppression is checked at two points in the warning path:
> - In warn_slowpath_fmt(), the check runs before any output, fully
> suppressing both message and backtrace.
> - In __report_bug(), the check runs before __warn() is called,
> suppressing the backtrace and stack dump. Note that on this path,
> the WARN() format message may still appear in the kernel log since
> __warn_printk() runs before the trap that enters __report_bug().
This is for architectures that implement __WARN_FLAGS but not
__WARN_printf right? (which is arm64, loongarch, parisc, powerpc, riscv,
sh, afaict). ARM64 should eventually get __WARN_printf, but other than
that this should be fixable by moving __WARN_FLAGS() into
__warn_printk() or so. This is the only __warn_printk() user anyway.
> diff --git a/include/kunit/bug.h b/include/kunit/bug.h
> new file mode 100644
> index 0000000000000..e52c9d21d9fe6
> --- /dev/null
> +++ b/include/kunit/bug.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * KUnit helpers for backtrace suppression
> + *
> + * Copyright (C) 2025 Alessandro Carminati <acarmina@redhat.com>
> + * Copyright (C) 2024 Guenter Roeck <linux@roeck-us.net>
> + */
> +
> +#ifndef _KUNIT_BUG_H
> +#define _KUNIT_BUG_H
> +
> +#ifndef __ASSEMBLY__
> +
> +#include <linux/kconfig.h>
> +
> +struct kunit;
> +
> +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> +
> +#include <linux/types.h>
> +
> +struct task_struct;
> +
> +struct __suppressed_warning {
> + struct list_head node;
> + struct task_struct *task;
> + int counter;
> +};
> +
> +struct __suppressed_warning *
> +__kunit_start_suppress_warning(struct kunit *test);
> +void __kunit_end_suppress_warning(struct kunit *test,
> + struct __suppressed_warning *warning);
> +int __kunit_suppressed_warning_count(struct __suppressed_warning *warning);
> +bool __kunit_is_suppressed_warning(void);
> +
> +#define KUNIT_START_SUPPRESSED_WARNING(test) \
> + struct __suppressed_warning *__kunit_suppress = \
> + __kunit_start_suppress_warning(test)
> +
> +#define KUNIT_END_SUPPRESSED_WARNING(test) \
> + __kunit_end_suppress_warning(test, __kunit_suppress)
We have __cleanup for this?
> +
> +#define KUNIT_SUPPRESSED_WARNING_COUNT() \
> + __kunit_suppressed_warning_count(__kunit_suppress)
> +
> +#else /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> +
> +#define KUNIT_START_SUPPRESSED_WARNING(test)
> +#define KUNIT_END_SUPPRESSED_WARNING(test)
> +#define KUNIT_SUPPRESSED_WARNING_COUNT() 0
> +static inline bool __kunit_is_suppressed_warning(void) { return false; }
> +
> +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
> +#endif /* __ASSEMBLY__ */
> +#endif /* _KUNIT_BUG_H */
> diff --git a/lib/kunit/Makefile b/lib/kunit/Makefile
> index 656f1fa35abcc..fe177ff3ebdef 100644
> --- a/lib/kunit/Makefile
> +++ b/lib/kunit/Makefile
> @@ -16,8 +16,10 @@ ifeq ($(CONFIG_KUNIT_DEBUGFS),y)
> kunit-objs += debugfs.o
> endif
>
> -# KUnit 'hooks' are built-in even when KUnit is built as a module.
> -obj-$(if $(CONFIG_KUNIT),y) += hooks.o
> +# KUnit 'hooks' and bug handling are built-in even when KUnit is built
> +# as a module.
> +obj-$(if $(CONFIG_KUNIT),y) += hooks.o \
> + bug.o
>
> obj-$(CONFIG_KUNIT_TEST) += kunit-test.o
> obj-$(CONFIG_KUNIT_TEST) += platform-test.o
> diff --git a/lib/kunit/bug.c b/lib/kunit/bug.c
> new file mode 100644
> index 0000000000000..356c8a5928828
> --- /dev/null
> +++ b/lib/kunit/bug.c
> @@ -0,0 +1,84 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit helpers for backtrace suppression
> + *
> + * Copyright (C) 2025 Alessandro Carminati <acarmina@redhat.com>
> + * Copyright (C) 2024 Guenter Roeck <linux@roeck-us.net>
> + */
> +
> +#include <kunit/bug.h>
> +#include <kunit/resource.h>
> +#include <linux/export.h>
> +#include <linux/rculist.h>
> +#include <linux/sched.h>
> +
> +#ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
> +
> +static LIST_HEAD(suppressed_warnings);
> +
> +static void __kunit_suppress_warning_remove(struct __suppressed_warning *warning)
> +{
> + list_del_rcu(&warning->node);
> + synchronize_rcu(); /* Wait for readers to finish */
> +}
> +
> +KUNIT_DEFINE_ACTION_WRAPPER(__kunit_suppress_warning_cleanup,
> + __kunit_suppress_warning_remove,
> + struct __suppressed_warning *);
> +
> +struct __suppressed_warning *
> +__kunit_start_suppress_warning(struct kunit *test)
> +{
> + struct __suppressed_warning *warning;
> + int ret;
> +
> + warning = kunit_kzalloc(test, sizeof(*warning), GFP_KERNEL);
> + if (!warning)
> + return NULL;
> +
> + warning->task = current;
> + list_add_rcu(&warning->node, &suppressed_warnings);
What if anything serializes this global list?
> +
> + ret = kunit_add_action_or_reset(test,
> + __kunit_suppress_warning_cleanup,
> + warning);
> + if (ret)
> + return NULL;
> +
> + return warning;
> +}
> +EXPORT_SYMBOL_GPL(__kunit_start_suppress_warning);
> +
> +void __kunit_end_suppress_warning(struct kunit *test,
> + struct __suppressed_warning *warning)
> +{
> + if (!warning)
> + return;
> + kunit_release_action(test, __kunit_suppress_warning_cleanup, warning);
> +}
> +EXPORT_SYMBOL_GPL(__kunit_end_suppress_warning);
> +
> +int __kunit_suppressed_warning_count(struct __suppressed_warning *warning)
> +{
> + return warning ? warning->counter : 0;
> +}
> +EXPORT_SYMBOL_GPL(__kunit_suppressed_warning_count);
> +
> +bool __kunit_is_suppressed_warning(void)
> +{
> + struct __suppressed_warning *warning;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(warning, &suppressed_warnings, node) {
> + if (warning->task == current) {
> + warning->counter++;
> + rcu_read_unlock();
> + return true;
> + }
> + }
> + rcu_read_unlock();
> +
> + return false;
> +}
> +
> +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
>
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v7 2/5] bug/kunit: Reduce runtime impact of warning backtrace suppression
From: Peter Zijlstra @ 2026-04-20 14:44 UTC (permalink / raw)
To: Albert Esteve
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati
In-Reply-To: <20260420-kunit_add_support-v7-2-e8bc6e0f70de@redhat.com>
On Mon, Apr 20, 2026 at 02:28:04PM +0200, Albert Esteve wrote:
> From: Alessandro Carminati <acarmina@redhat.com>
>
> KUnit support is not consistently present across distributions, some
> include it in their stock kernels, while others do not.
> While both KUNIT and KUNIT_SUPPRESS_BACKTRACE can be considered debug
> features, the fact that some distros ship with KUnit enabled means it's
> important to minimize the runtime impact of this patch.
>
> To that end, this patch adds an atomic counter that tracks the number
> of active suppressions. __kunit_is_suppressed_warning() checks this
> counter first and returns immediately when no suppressions are active,
> avoiding RCU-protected list traversal in the common case.
>
> Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
> lib/kunit/bug.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/lib/kunit/bug.c b/lib/kunit/bug.c
> index 356c8a5928828..a7a88f0670d44 100644
> --- a/lib/kunit/bug.c
> +++ b/lib/kunit/bug.c
> @@ -8,6 +8,7 @@
>
> #include <kunit/bug.h>
> #include <kunit/resource.h>
> +#include <linux/atomic.h>
> #include <linux/export.h>
> #include <linux/rculist.h>
> #include <linux/sched.h>
> @@ -15,11 +16,13 @@
> #ifdef CONFIG_KUNIT_SUPPRESS_BACKTRACE
>
> static LIST_HEAD(suppressed_warnings);
> +static atomic_t suppressed_warnings_cnt = ATOMIC_INIT(0);
>
> static void __kunit_suppress_warning_remove(struct __suppressed_warning *warning)
> {
> list_del_rcu(&warning->node);
> synchronize_rcu(); /* Wait for readers to finish */
> + atomic_dec(&suppressed_warnings_cnt);
> }
>
> KUNIT_DEFINE_ACTION_WRAPPER(__kunit_suppress_warning_cleanup,
> @@ -37,6 +40,7 @@ __kunit_start_suppress_warning(struct kunit *test)
> return NULL;
>
> warning->task = current;
> + atomic_inc(&suppressed_warnings_cnt);
> list_add_rcu(&warning->node, &suppressed_warnings);
>
> ret = kunit_add_action_or_reset(test,
> @@ -68,6 +72,9 @@ bool __kunit_is_suppressed_warning(void)
> {
> struct __suppressed_warning *warning;
>
> + if (!atomic_read(&suppressed_warnings_cnt))
> + return false;
> +
> rcu_read_lock();
> list_for_each_entry_rcu(warning, &suppressed_warnings, node) {
> if (warning->task == current) {
>
So the thing you're skipping is:
rcu_read_lock();
list_for_each_entry_rcu() {
}
rcu_read_unlock();
Which is really cheap. Did you actually have performance numbers for
this?
A possibly better option is to add a static_branch() that could elide
any and all memory access.
^ permalink raw reply
* Re: [PATCH v7 1/5] bug/kunit: Core support for suppressing warning backtraces
From: Peter Zijlstra @ 2026-04-20 14:45 UTC (permalink / raw)
To: Albert Esteve
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Alessandro Carminati, Guenter Roeck,
Kees Cook
In-Reply-To: <20260420-kunit_add_support-v7-1-e8bc6e0f70de@redhat.com>
On Mon, Apr 20, 2026 at 02:28:03PM +0200, Albert Esteve wrote:
> +bool __kunit_is_suppressed_warning(void)
> +{
> + struct __suppressed_warning *warning;
> +
> + rcu_read_lock();
guard(rcu)();
> + list_for_each_entry_rcu(warning, &suppressed_warnings, node) {
> + if (warning->task == current) {
> + warning->counter++;
> + rcu_read_unlock();
> + return true;
> + }
> + }
> + rcu_read_unlock();
> +
> + return false;
> +}
> +
> +#endif /* CONFIG_KUNIT_SUPPRESS_BACKTRACE */
>
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v7 4/5] drm: Suppress intentional warning backtraces in scaling unit tests
From: Peter Zijlstra @ 2026-04-20 14:47 UTC (permalink / raw)
To: Albert Esteve
Cc: Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Jonathan Corbet, Shuah Khan, Andrew Morton,
linux-kernel, linux-arch, linux-kselftest, kunit-dev, dri-devel,
workflows, linux-doc, Guenter Roeck,
Linux Kernel Functional Testing, Dan Carpenter, Maíra Canal,
Alessandro Carminati, Simona Vetter
In-Reply-To: <20260420-kunit_add_support-v7-4-e8bc6e0f70de@redhat.com>
On Mon, Apr 20, 2026 at 02:28:06PM +0200, Albert Esteve wrote:
> From: Guenter Roeck <linux@roeck-us.net>
>
> The drm_test_rect_calc_hscale and drm_test_rect_calc_vscale unit tests
> intentionally trigger warning backtraces by providing bad parameters to
> the tested functions. What is tested is the return value, not the existence
> of a warning backtrace. Suppress the backtraces to avoid clogging the
> kernel log and distraction from real problems.
>
> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
> Acked-by: Dan Carpenter <dan.carpenter@linaro.org>
> Acked-by: Maíra Canal <mcanal@igalia.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: David Airlie <airlied@gmail.com>
> Cc: Daniel Vetter <daniel@ffwll.ch>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Alessandro Carminati <acarmina@redhat.com>
> Signed-off-by: Albert Esteve <aesteve@redhat.com>
> ---
> drivers/gpu/drm/tests/drm_rect_test.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/gpu/drm/tests/drm_rect_test.c b/drivers/gpu/drm/tests/drm_rect_test.c
> index 17e1f34b76101..1dd7d819165e7 100644
> --- a/drivers/gpu/drm/tests/drm_rect_test.c
> +++ b/drivers/gpu/drm/tests/drm_rect_test.c
> @@ -409,8 +409,15 @@ static void drm_test_rect_calc_hscale(struct kunit *test)
> const struct drm_rect_scale_case *params = test->param_value;
> int scaling_factor;
>
> + /*
> + * drm_rect_calc_hscale() generates a warning backtrace whenever bad
> + * parameters are passed to it. This affects all unit tests with an
> + * error code in expected_scaling_factor.
> + */
> + KUNIT_START_SUPPRESSED_WARNING(test);
> scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
> params->min_range, params->max_range);
> + KUNIT_END_SUPPRESSED_WARNING(test);
Would not something like:
scoped_kunit_suppress() {
scaling_factor = drm_rect_calc_hscale(¶ms->src, ¶ms->dst,
params->min_range, params->max_range);
}
be better?
Also, how can you stand all this screaming in the code?
^ permalink raw reply
* Re: [PATCH 7.2 v16 06/13] mm/khugepaged: skip collapsing mTHP to smaller orders
From: Usama Arif @ 2026-04-20 15:36 UTC (permalink / raw)
To: Nico Pache
Cc: Usama Arif, linux-doc, linux-kernel, linux-mm, linux-trace-kernel,
akpm, anshuman.khandual, apopple, baohua, baolin.wang, byungchul,
catalin.marinas, cl, corbet, dave.hansen, david, dev.jain, gourry,
hannes, hughd, jack, jackmanb, jannh, jglisse, joshua.hahnjy, kas,
lance.yang, Liam.Howlett, ljs, mathieu.desnoyers, matthew.brost,
mhiramat, mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap,
richard.weiyang, rientjes, rostedt, rppt, ryan.roberts, shivankg,
sunnanyong, surenb, thomas.hellstrom, tiwai, usamaarif642, vbabka,
vishal.moola, wangkefeng.wang, will, willy, yang, ying.huang, ziy,
zokeefe
In-Reply-To: <20260419185750.260784-7-npache@redhat.com>
On Sun, 19 Apr 2026 12:57:43 -0600 Nico Pache <npache@redhat.com> wrote:
> khugepaged may try to collapse a mTHP to a smaller mTHP, resulting in
> some pages being unmapped. Skip these cases until we have a way to check
> if its ok to collapse to a smaller mTHP size (like in the case of a
> partially mapped folio). This check is also not done during the scan phase
> as the current collapse order is unknown at that time.
>
> This patch is inspired by Dev Jain's work on khugepaged mTHP support [1].
>
> [1] https://lore.kernel.org/lkml/20241216165105.56185-11-dev.jain@arm.com/
>
> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org>
> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> Co-developed-by: Dev Jain <dev.jain@arm.com>
> Signed-off-by: Dev Jain <dev.jain@arm.com>
> Signed-off-by: Nico Pache <npache@redhat.com>
> ---
> mm/khugepaged.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
Acked-by: Usama Arif <usama.arif@linux.dev>
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Nhat Pham @ 2026-04-20 16:02 UTC (permalink / raw)
To: Kairui Song
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel
In-Reply-To: <CAMgjq7AiUr_Ntj51qoqvV+=XbEATjr7S4MH+rgD32T5pHfF7mg@mail.gmail.com>
On Mon, Mar 23, 2026 at 3:09 AM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Sat, Mar 21, 2026 at 3:29 AM Nhat Pham <nphamcs@gmail.com> wrote:
> > This patch series is based on 6.19. There are a couple more
> > swap-related changes in mainline that I would need to coordinate
> > with, but I still want to send this out as an update for the
> > regressions reported by Kairui Song in [15]. It's probably easier
> > to just build this thing rather than dig through that series of
> > emails to get the fix patch :)
> >
> > Changelog:
> > * v4 -> v5:
> > * Fix a deadlock in memcg1_swapout (reported by syzbot [16]).
> > * Replace VM_WARN_ON(!spin_is_locked()) with lockdep_assert_held(),
> > and use guard(rcu) in vswap_cpu_dead
> > (reported by Peter Zijlstra [17]).
> > * v3 -> v4:
> > * Fix poor swap free batching behavior to alleviate a regression
> > (reported by Kairui Song).
>
> I tested the v5 (including the batched-free hotfix) and am still
> seeing significant regressions in both sequential and concurrent swap
> workloads
>
> Thanks for the update as I can see It's a lot of thoughtful work.
> Actually I did run some tests already with your previously posted
> hotfix based on v3. I didn't update the result because very
> unfortunately, I still see a major performance regression even with a
> very simple setup.
>
> BTW there seems a simpler way to reproduce that, just use memhog:
> sudo mkswap /dev/pmem0; sudo swapon /dev/pmem0; time memhog 48G; sudo swapoff -a
>
> Before:
> (I'm using fish shell on that test machine so this is fish time format):
> ________________________________________________________
> Executed in 20.80 secs fish external
> usr time 5.14 secs 0.00 millis 5.14 secs
> sys time 15.65 secs 1.17 millis 15.65 secs
> ________________________________________________________
> Executed in 21.69 secs fish external
> usr time 5.31 secs 725.00 micros 5.31 secs
> sys time 16.36 secs 579.00 micros 16.36 secs
> ________________________________________________________
> Executed in 21.86 secs fish external
> usr time 5.39 secs 1.02 millis 5.39 secs
> sys time 16.46 secs 0.27 millis 16.46 secs
>
> After:
> ________________________________________________________
> Executed in 30.77 secs fish external
> usr time 5.16 secs 767.00 micros 5.16 secs
> sys time 25.59 secs 580.00 micros 25.59 secs
> ________________________________________________________
> Executed in 37.47 secs fish external
> usr time 5.48 secs 0.00 micros 5.48 secs
> sys time 31.98 secs 674.00 micros 31.98 secs
> ________________________________________________________
> Executed in 31.34 secs fish external
> usr time 5.22 secs 0.00 millis 5.22 secs
> sys time 26.09 secs 1.30 millis 26.09 secs
>
> It's obviously a lot slower.
>
> pmem may seem rare but SSDs are good at sequential, and memhog uses
> the same filled page and backend like ZRAM has extremely low overhead
> for same filled pages. Results with ZRAM are very similar, and many
> production workloads have massive amounts of samefill memory.
>
> For example on the Android phone I'm using right now at this moment:
> # cat /sys/block/zram0/mm_stat
> 4283899904 1317373036 1370259456 0 1475977216 116457 1991851
> 87273 1793760
> ~450M of samefill page in ZRAM, we may see more on some server
> workload. And I'm seeing similar memhog results with ZRAM, pmem is
> just easier to setup and less noisy. also simulates high speed
> storage.
>
> I also ran the previous usemem matrix, which seems better than V3 but
> still pretty bad:
> Test: usemem --init-time -O -n 1 56G, 16G mem, 48G swap, avgs of 8 run.
> Before:
> Throughput (Sum): 528.98 MB/s Throughput (Mean): 526.113333 MB/s Free
> Latency: 3037932.888889
> After:
> Throughput (Sum): 453.74 MB/s Throughput (Mean): 454.875000 MB/s Free
> Latency: 5001144.500000 (~10%, 64% slower)
>
> I'm not sure why our results differ so much — perhaps different LRU
> settings, memory pressure ratios, or THP/mTHP configs? Here's my exact
> config in the attachment. Also includes the full log and info, with
> all debug options disabled for close to production. I ran it 8 times
> and just attached the first result log, it's all similar anyway, my
> test framework reboot the machine after each test run to reduce any
> potential noise.
>
> And the above tests are only about sequential performance, concurrent
> ones seem worse:
> Test: usemem --init-time -O -R -n 32 622M, 16G mem, 48G swap, avgs of 8 run.
> Before:
> Throughput (Sum): 5467.51 MB/s Throughput (Mean): 170.04 MB/s Free
> Latency: 28648.65
> After:
> Throughput (Sum): 4914.86 MB/s Throughput (Mean): 152.74 MB/s Free
> Latency: 67789.81 (~10%, 230% slower)
For this test case, I took my 16G (a bit less than that technically)
52 cores host, using zram as the backend and MGLRU, for a spin.
Keeping the same parameters as your usemem command, unfortunately, led
to massive thrashing (even with baseline kernel) - unfortunately zram
still used physical memory so the overcommit level is too large
(especially with random access pattern, i.e the -R flag).
I then tried reducing the 622M part to 480M, but the problem with that
is VSS5 did not show any regression - probably because the
overcommitting is too low, or not enough concurrency. I had to push
the concurrency up to 52 workers, allocating 300M each (which is
slightly more memory allocated overall than the 480 x 32 case), to
finally show the regression you reported. Variance was very big with 8
runs though (what I normally use for usemem these days), so I had to
do 20 runs per kernel - fortunately these runs are fast:
Metric baseline vss_v5 new_opt_v2 cc_v2
real (s) 15.0 +/- 0.8 18.3 +/- 1.8 15.1 +/- 1.0 14.7 +/- 1.0
sys (s) 396.4 +/- 31.1 511.9 +/- 60.3 404.1 +/- 34.5 392.4 +/- 39.9
tput (KB/s) 28188 +/- 6996 23287 +/- 6629 27999 +/- 6623 28744 +/- 7015
free (ms) 101.1 +/- 52.4 91.4 +/- 41.5 93.1 +/- 43.8 97.6 +/- 49.5
% real n/a +22.4% +0.7% -1.7%
% sys n/a +29.1% +1.9% -1.0%
% tput n/a -17.4% -0.7% +2.0%
% free n/a -9.6% -7.9% -3.5%
(I realized I mangled the output last time of the "memory reclaim
metrics table" table due to auto line break. Let's hope this is
better).
Strangely, no free regression. Hmmm.
But real, sys, and throughput regression are real. The optimizations
do close the gap to within noise level here too.
^ permalink raw reply
* Re: [PATCH] Documentation: coding-assistants: add optional Acted-By: trailer
From: Greg KH @ 2026-04-20 17:40 UTC (permalink / raw)
To: Blake Morrison
Cc: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260420142741.3187814-1-blake@truealter.com>
On Mon, Apr 20, 2026 at 02:27:46PM +0000, Blake Morrison wrote:
> The existing policy correctly separates AI tool attribution
> (Assisted-by:) from legal accountability (Signed-off-by:). In practice,
> contributors increasingly work across pseudonymous and legal-name
> contexts, and a third slot -- identifying the human sovereign identity
> under which the work was performed -- lets downstream tooling (CI,
> provenance trackers, identity systems) bind a commit to a stable handle
> without disturbing the DCO.
>
> Add Acted-By: as an optional, informational companion trailer. It does
> not replace Signed-off-by:, does not change DCO requirements, and does
> not mandate any format; the out-of-tree
> draft-morrison-identity-attributed-commits defines one such scheme, but
> contributors are free to use any handle form they prefer.
>
> The three trailers then map cleanly:
>
> * Assisted-by: -- what tool drafted this
> * Acted-By: -- who the human was, as a handle
I really do not understand, how would this actually be used?
And as you have to have a signed-off-by, why would you use two different
names for yourself this way?
And who is asking for this? Who would want to use it? How would you
use it for this very commit?
confused,
greg k-h
^ permalink raw reply
* Re: [PATCH] Documentation: fix spelling mistake "Minumum" -> "Minimum"
From: Mark Pearson @ 2026-04-20 18:07 UTC (permalink / raw)
To: Jonathan Corbet, Derek J . Clark, Ninad Naik, Armin Wolf, skhan
Cc: platform-driver-x86@vger.kernel.org, linux-doc, linux-kernel, me,
linux-kernel-mentees
In-Reply-To: <87fr4qw2jy.fsf@trenco.lwn.net>
On Mon, Apr 20, 2026, at 2:47 AM, Jonathan Corbet wrote:
> "Derek J. Clark" <derekjohn.clark@gmail.com> writes:
>
>> The MOF spelling mistakes are well known. We've left them is as to
>> ensure match with what the hardware actually reports.
>>
>> See: https://lore.kernel.org/platform-driver-x86/cfd7977e-d612-4e08-a68a-65fed8e164b6@gmx.de
>>
>> I suppose if we're going to continue getting these types or PR I
>> should add a note to the documentation. I'll add that soon.
>
> Perhaps worth adding, but I'm not sure I would expect it to help. The
> people generating these patches aren't putting much attention into the
> context surrounding them.
>
I'd forgotten that previous discussion - sorry.
Part of the problem (I know I had this many years ago when I got started) is being told the best way to get involved in kernel development and learn the process is to find small things to fix (spelling mistakes, documentation, comments etc). I suspect that's accelerated with AI identifying them too :)
What if we fix the typo, and add a comment highlighting that the vendor documentation/MOF/whatever is wrong? Then everybody is 'happy'? (or at least we'll get less emails about it)
Mark
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox