* [PATCH 1/2] mm/kmemleak: report leaks only after N consecutive unreferenced scans
From: Breno Leitao @ 2026-06-26 15:52 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan
Cc: workflows, linux-doc, linux-kernel, linux-mm, linux-kselftest,
Breno Leitao, kernel-team
In-Reply-To: <20260626-kmemleak_twice-v1-0-ab28f7cc0971@debian.org>
kmemleak reports an object the first scan it is found unreferenced. Its
mark phase runs without stopping the rest of the kernel and without a
write barrier, so a live object whose only reference is briefly invisible
during a concurrent RCU update -- e.g. a VMA moved between maple tree
nodes, or a page-cache xa_node -- can be seen as unreferenced for that one
scan. Because an object is flagged as reported only once, such a transient
race turns into a permanent false positive.
Track how many consecutive scans each object has been seen unreferenced
and only report it once that reaches min_unref_scans, a new module
parameter. It defaults to 1, leaving the behaviour unchanged; setting it
higher (e.g. 2) still reports a genuine leak, one scan later, while an
object referenced again before the threshold restarts its run and is never
reported.
min_unref_scans can be set at boot with kmemleak.min_unref_scans=<n> or at
run-time via /sys/module/kmemleak/parameters/min_unref_scans.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
Documentation/dev-tools/kmemleak.rst | 8 ++++++++
mm/kmemleak.c | 14 ++++++++++++--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/Documentation/dev-tools/kmemleak.rst b/Documentation/dev-tools/kmemleak.rst
index 7d784e03f3f9d..a8a83bc69ceb8 100644
--- a/Documentation/dev-tools/kmemleak.rst
+++ b/Documentation/dev-tools/kmemleak.rst
@@ -198,6 +198,14 @@ systems, because of pointers temporarily stored in CPU registers or
stacks. Kmemleak defines MSECS_MIN_AGE (defaulting to 1000) representing
the minimum age of an object to be reported as a memory leak.
+The ``min_unref_scans`` module parameter (default 1) requires an object to
+be seen unreferenced in that many consecutive scans before it is reported.
+Keeping it at 1 preserves the historical behaviour; higher values filter
+the transient false positives described above, at the cost of delaying
+genuine reports by up to that many scans. It can be set at boot with
+``kmemleak.min_unref_scans=<n>`` or at run-time via
+``/sys/module/kmemleak/parameters/min_unref_scans``.
+
Limitations and Drawbacks
-------------------------
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 7c7ba17ce7af0..5b14ccb36f95b 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -151,6 +151,8 @@ struct kmemleak_object {
int min_count;
/* the total number of pointers found pointing to this object */
int count;
+ /* consecutive scans the object has been seen unreferenced */
+ unsigned int unref_scans;
/* checksum for detecting modified objects */
u32 checksum;
depot_stack_handle_t trace_handle;
@@ -232,6 +234,9 @@ static unsigned long max_percpu_addr;
static struct task_struct *scan_thread;
/* used to avoid reporting of recently allocated objects */
static unsigned long jiffies_min_age;
+/* consecutive scans an object must stay unreferenced before reporting */
+static unsigned int min_unref_scans = 1;
+module_param(min_unref_scans, uint, 0644);
static unsigned long jiffies_last_scan;
/* delay between automatic memory scannings */
static unsigned long jiffies_scan_wait;
@@ -687,6 +692,7 @@ static struct kmemleak_object *__alloc_object(gfp_t gfp)
atomic_set(&object->use_count, 1);
object->excess_ref = 0;
object->count = 0; /* white color initially */
+ object->unref_scans = 0;
object->checksum = 0;
object->del_state = 0;
@@ -1833,6 +1839,9 @@ static void kmemleak_scan(void)
__paint_it(object, KMEMLEAK_BLACK);
}
+ /* referenced last scan: restart the unreferenced run */
+ if (!color_white(object))
+ object->unref_scans = 0;
/* reset the reference count (whiten the object) */
object->count = 0;
if (color_gray(object) && get_object(object))
@@ -1968,8 +1977,9 @@ static void kmemleak_scan(void)
raw_spin_lock_irq(&object->lock);
trace_handle = 0;
dedup_print = false;
- if (unreferenced_object(object) &&
- !(object->flags & OBJECT_REPORTED)) {
+ if (!(object->flags & OBJECT_REPORTED) &&
+ unreferenced_object(object) &&
+ ++object->unref_scans >= min_unref_scans) {
object->flags |= OBJECT_REPORTED;
if (kmemleak_verbose) {
trace_handle = object->trace_handle;
--
2.53.0-Meta
^ permalink raw reply related
* [PATCH 2/2] selftests/mm: test kmemleak's N-consecutive-scan leak confirmation
From: Breno Leitao @ 2026-06-26 15:52 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Shuah Khan
Cc: workflows, linux-doc, linux-kernel, linux-mm, linux-kselftest,
Breno Leitao, kernel-team
In-Reply-To: <20260626-kmemleak_twice-v1-0-ab28f7cc0971@debian.org>
Add a functional test for the min_unref_scans kmemleak module parameter.
Using samples/kmemleak's helper module it checks that min_unref_scans=1
reports an orphan on the first scan, min_unref_scans=2 reports nothing on
the first scan but does on the second, and that the parameter reads back
what was written.
It counts only the helper module's own orphans (matched by their
[kmemleak_test] backtrace, with the module kept loaded so the symbols
resolve) so unrelated leaks already present on the system do not perturb
the result. The test skips when run as non-root, without
CONFIG_DEBUG_KMEMLEAK / CONFIG_SAMPLE_KMEMLEAK, on a kernel without the
parameter, or when the helper yields no detectable orphan.
Signed-off-by: Breno Leitao <leitao@debian.org>
---
tools/testing/selftests/mm/Makefile | 1 +
.../testing/selftests/mm/ksft_kmemleak_confirm.sh | 111 +++++++++++++++++++++
2 files changed, 112 insertions(+)
diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile
index e6df968f0971c..84026b62a1ae5 100644
--- a/tools/testing/selftests/mm/Makefile
+++ b/tools/testing/selftests/mm/Makefile
@@ -150,6 +150,7 @@ TEST_PROGS += ksft_gup_test.sh
TEST_PROGS += ksft_hmm.sh
TEST_PROGS += ksft_hugetlb.sh
TEST_PROGS += ksft_hugevm.sh
+TEST_PROGS += ksft_kmemleak_confirm.sh
TEST_PROGS += ksft_kmemleak_dedup.sh
TEST_PROGS += ksft_ksm.sh
TEST_PROGS += ksft_ksm_numa.sh
diff --git a/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh b/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh
new file mode 100755
index 0000000000000..34ab64bc6948f
--- /dev/null
+++ b/tools/testing/selftests/mm/ksft_kmemleak_confirm.sh
@@ -0,0 +1,111 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+#
+# Functional test for kmemleak's N-consecutive-scan leak confirmation
+# (the min_unref_scans module parameter).
+#
+# kmemleak only reports an object once it has stayed unreferenced for
+# min_unref_scans consecutive scans. The default of 1 reports on the first
+# scan (historical behaviour); higher values filter transient false
+# positives where a live object's only reference is briefly invisible to a
+# single scan (e.g. an RCU tree update in flight while the scan runs). The
+# test loads samples/kmemleak's helper module to create orphan allocations
+# and, counting only those orphans (matched by their [kmemleak_test]
+# backtrace so unrelated leaks already present on the system are ignored),
+# checks that:
+# - min_unref_scans=1 reports them on the first scan,
+# - min_unref_scans=2 reports nothing on the first scan but does on the
+# second,
+# - the parameter reads back what was written.
+#
+# The "nothing on the first scan" check is the core regression test: with
+# min_unref_scans=2 no object can be reported in fewer than two scans. Like
+# ksft_kmemleak_dedup.sh, if the module yields no detectable orphan at all
+# in the running environment the test skips rather than failing.
+#
+# Author: Breno Leitao <leitao@debian.org>
+
+ksft_skip=4
+KMEMLEAK=/sys/kernel/debug/kmemleak
+PARAM=/sys/module/kmemleak/parameters/min_unref_scans
+MODULE=kmemleak-test
+AGE=6 # seconds; must exceed kmemleak's 5s minimum object age
+
+skip() { echo "SKIP: $*"; exit $ksft_skip; }
+fail() { echo "FAIL: $*"; exit 1; }
+pass() { echo "PASS: $*"; exit 0; }
+
+[ "$(id -u)" -eq 0 ] || skip "must run as root"
+[ -r "$KMEMLEAK" ] || skip "no kmemleak debugfs (CONFIG_DEBUG_KMEMLEAK)"
+[ -w "$PARAM" ] || skip "min_unref_scans module parameter not present"
+modinfo "$MODULE" >/dev/null 2>&1 ||
+ skip "$MODULE not built (CONFIG_SAMPLE_KMEMLEAK)"
+
+# kmemleak can be present but disabled at runtime (kmemleak=off boot arg,
+# or it self-disabled after an internal error); a "scan" then returns
+# EPERM. Probe once and skip if so.
+echo scan > "$KMEMLEAK" 2>/dev/null ||
+ skip "kmemleak is disabled (check dmesg or kmemleak= boot arg)"
+
+prev=$(cat "$PARAM")
+# shellcheck disable=SC2317 # invoked indirectly via trap
+cleanup() {
+ echo "$prev" > "$PARAM" 2>/dev/null # restore the parameter
+ echo scan=on > "$KMEMLEAK" 2>/dev/null # re-enable auto scan
+ rmmod "$MODULE" 2>/dev/null
+ echo clear > "$KMEMLEAK" 2>/dev/null
+}
+trap cleanup EXIT
+
+# Stop the automatic scan thread: only our manual scans should advance an
+# object's consecutive-unreferenced run. An auto scan landing between two
+# manual scans would change the result and make the test flaky.
+echo scan=off > "$KMEMLEAK" 2>/dev/null
+
+# Create a fresh, aged set of orphan objects from the helper module's init
+# path (its kmalloc/vmalloc/percpu allocations are dropped right away).
+# Pre-existing reported leaks are greyed first ("clear") so only our
+# orphans are counted. The module is left loaded on purpose: once it is
+# unloaded its symbols are gone, so the orphan backtraces no longer resolve
+# to [kmemleak_test] and could not be matched below.
+gen_orphans() {
+ rmmod "$MODULE" 2>/dev/null
+ echo clear > "$KMEMLEAK"
+ modprobe "$MODULE" || skip "failed to load $MODULE"
+ sleep "$AGE"
+}
+
+scan() { echo scan > "$KMEMLEAK"; }
+
+# Number of helper-module orphans currently reported by kmemleak. Matching
+# the module's own backtrace ([kmemleak_test]) keeps the count immune to
+# unrelated leaks on the running system. kmemleak only lists an object here
+# once it has been reported, so this reflects the confirmation gating.
+count_orphans() {
+ c=$(grep -c '\[kmemleak_test\]' "$KMEMLEAK" 2>/dev/null)
+ echo "${c:-0}"
+}
+
+# 0) the parameter reads back what was written.
+echo 3 > "$PARAM"
+[ "$(cat "$PARAM")" = "3" ] || fail "min_unref_scans did not read back as 3"
+
+# 1) min_unref_scans=1 (default): orphans reported on the first scan. This
+# also establishes that the helper produces detectable orphans here.
+echo 1 > "$PARAM"
+gen_orphans
+scan
+first=$(count_orphans)
+[ "$first" -gt 0 ] ||
+ skip "$MODULE produced no detectable orphans (cannot test min_unref_scans)"
+
+# 2) min_unref_scans=2: nothing reported after the first scan, reported
+# after the second. The first-scan-zero check is the core regression.
+echo 2 > "$PARAM"
+gen_orphans
+scan; s1=$(count_orphans)
+scan; s2=$(count_orphans)
+[ "$s1" -eq 0 ] || fail "min_unref_scans=2: $s1 orphan(s) reported after the 1st scan (must be 0)"
+[ "$s2" -gt 0 ] || fail "min_unref_scans=2: no report on the 2nd scan (false negative)"
+
+pass "min_unref_scans=1 immediate; =2 gated to 2nd scan (counts $first/$s1/$s2); param read-back ok"
--
2.53.0-Meta
^ permalink raw reply related
* Re: [PATCH v3 00/12] [PATCH v3 00/12] x86/resctrl: Add kernel-mode (e.g., PLZA) support to the resctrl subsystem
From: Luck, Tony @ 2026-06-26 15:55 UTC (permalink / raw)
To: Babu Moger
Cc: corbet, reinette.chatre, Dave.Martin, james.morse, tglx, bp,
dave.hansen, skhan, x86, mingo, hpa, akpm, rdunlap,
pawan.kumar.gupta, feng.tang, dapeng1.mi, kees, elver, lirongqing,
paulmck, bhelgaas, seanjc, alexandre.chartre, yazen.ghannam,
peterz, chang.seok.bae, kim.phillips, xin, naveen,
thomas.lendacky, linux-doc, linux-kernel, eranian, peternewman,
sos-linux-ext-patches
In-Reply-To: <cover.1777591496.git.babu.moger@amd.com>
On Thu, Apr 30, 2026 at 06:24:45PM -0500, Babu Moger wrote:
>
> Hi,
>
> This series adds support for AMD's Privilege-Level Zero Association
> (PLZA) so kernel work can be assigned to a resctrl group, and wires it
> up through a small generic "kernel mode" (kmode) layer in fs/resctrl
> so future architectures can plug in without touching core resctrl.
>
> The features are documented in:
>
> AMD64 Zen6 Platform Quality of Service (PQOS) Extensions,
> Publication # 69193 Revision 1.00, Issue Date March 2026
>
> available at https://bugzilla.kernel.org/show_bug.cgi?id=206537
>
> The patches are based on top of commit (7.1.0-rc1)
> Commit 3382329a309d Merge branch into tip/master: 'timers/clocksource'.
Hi Babu,
Have you had any thoughts about a resctrl selftest for PLZA?
I'm not sure there are any easy ways to show that PLZA is effective for
MBA control (as most normal system calls don't do enough to easily detect
whether the kernel CLOSID is applied). But perhaps you have some ideas for this?
A test that sets global_assign_ctrl_assign_mon_per_cpu mode with a dedicated
RMID to track kernel memory traffic would easily show MBM and llc_occupancy
numbers for kernel activity.
-Tony
^ permalink raw reply
* Re: [PATCH v2 1/9] dt-bindings: adm1275: ROHM BD12780 hot-swap controller
From: Conor Dooley @ 2026-06-26 15:58 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Matti Vaittinen, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Wensheng Wang, Ashish Yadav, Vasileios Amoiridis, Kim Seer Paller,
ChiShih Tsai, Chris Packham, Robert Coulson, linux-hwmon,
devicetree, linux-kernel, linux-doc
In-Reply-To: <2b7d5bb8cba773d0bba1d6779f0e6daa6a40eed4.1782458224.git.mazziesaccount@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] docs: pagemap: fix flags location, member name and sample code
From: Zenghui Yu @ 2026-06-26 16:03 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: linux-mm, linux-doc, linux-kernel, akpm, ljs, liam, vbabka, rppt,
surenb, mhocko, corbet, skhan
In-Reply-To: <511c2e7c-0305-4917-a639-e8e9e8710903@kernel.org>
On 6/26/26 10:47 PM, David Hildenbrand (Arm) wrote:
> On 6/25/26 19:44, Zenghui Yu wrote:
> > The userland visible page flags (KPF_*) were initially moved to
> > include/linux/kernel-page-flags.h in commit 1a9b5b7fe0c5 ("mm: export
> > stable page flags"), and later moved to
> > include/uapi/linux/kernel-page-flags.h in commit 607ca46e97a1 ("UAPI:
> > (Scripted) Disintegrate include/linux"). Upadte the doc to reflect the
>
> s/Upadte/Update/
>
> > current location of these flags.
>
> Ack
>
> >
> > The member @walk_end of struct pm_scan_arg {} was wrongly written as
> > "end_walk".
>
> Ack
>
> >
> > The first sample code of the PAGEMAP_SCAN ioctl wrongly used the
> > PM_SCAN_CHECK_WPASYNC flag twice, instead of the PM_SCAN_WP_MATCHING flag.
>
> That makes sense.
>
> > The second one missed PAGE_IS_FILE in the required mask.
>
> Hm. The description says: "Find pages which have been written, are file backed,
> not swapped and either present or huge".
>
> But doesn't that mean that
>
> it should actually be
>
> .category_mask = PAGE_IS_WRITTEN | PAGE_IS_FILE,
>
> Because
>
> .category_inverted = PAGE_IS_SWAPPED,
Ah! Thanks for pointing it out. I'll fix it soon.
Thanks,
Zenghui
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: riscv: Add generic CBQRI controller binding
From: Drew Fustini @ 2026-06-26 16:05 UTC (permalink / raw)
To: Conor Dooley
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, yunhui cui, linux-kernel, linux-riscv,
x86, devicetree, linux-rt-devel, linux-doc
In-Reply-To: <20260626-immobile-staining-c825a86bd613@spud>
[-- Attachment #1: Type: text/plain, Size: 2591 bytes --]
On Fri, Jun 26, 2026 at 04:44:56PM +0100, Conor Dooley wrote:
> On Thu, Jun 25, 2026 at 12:21:52PM -0700, Drew Fustini wrote:
> > On Thu, Jun 25, 2026 at 05:19:28PM +0100, Conor Dooley wrote:
> > > On Wed, Jun 24, 2026 at 06:38:35PM -0700, Drew Fustini wrote:
> > > > Document the generic compatibles for capacity and bandwidth controllers
> > > > that implement the RISC-V CBQRI specification. The binding also
> > > > describes the common riscv,cbqri-rcid and riscv,cbqri-mcid properties,
> > > > and the optional riscv,cbqri-cache phandle that links a capacity
> > > > controller to the cache whose capacity it allocates.
> > > >
> > > > Assisted-by: Claude:claude-opus-4-8
> > > > Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > > > Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > > > Signed-off-by: Drew Fustini <fustini@kernel.org>
> > > > ---
> > > > .../devicetree/bindings/riscv/riscv,cbqri.yaml | 97 ++++++++++++++++++++++
> > > > MAINTAINERS | 1 +
> > > > 2 files changed, 98 insertions(+)
> >
> > Thanks for the review.
> >
> > [..]
> > > > +properties:
> > > > + compatible:
> > > > + oneOf:
> > > > + - items:
> > > > + - description: Tenstorrent Ascalon Shared Cache
> > > > + const: tenstorrent,ascalon-sc-cbqri
> > > > + - const: riscv,cbqri-capacity-controller
> > > > + - enum:
> > > > + - riscv,cbqri-capacity-controller
> > > > + - riscv,cbqri-bandwidth-controller
> > >
> > > Please modify this, as has been done for other riscv spec related
> > > bindings, to let people get away without using device-specific
> > > compatibles.
> > >
> > > In this case, you can just delete the first entry from this enum, since
> > > it already has a user and only have to implement this feedback for the
> > > second entry.
> >
> > Would this work?
> >
> > properties:
> > compatible:
> > oneOf:
> > - items:
> > - enum:
> > - tenstorrent,ascalon-sc-cbqri # Tenstorrent Ascalon Shared Cache
> > - const: riscv,cbqri-capacity-controller
> > - items:
> > - {}
> > - const: riscv,cbqri-bandwidth-controller
>
>
> Should do, yes. I question the need for a comment though, seems pretty
> evident from the compatible what it is.
I was thinking people may not know that 'sc' is the Shared Cache. I
probably should have shortend the comment to 'Ascalon Shared Cache'.
Anyways, I can drop it.
Thanks,
Drew
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: riscv: Add generic CBQRI controller binding
From: Conor Dooley @ 2026-06-26 16:08 UTC (permalink / raw)
To: Drew Fustini
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, yunhui cui, linux-kernel, linux-riscv,
x86, devicetree, linux-rt-devel, linux-doc
In-Reply-To: <aj6jLrECZM18I4MP@thelio>
[-- Attachment #1: Type: text/plain, Size: 2818 bytes --]
On Fri, Jun 26, 2026 at 09:05:02AM -0700, Drew Fustini wrote:
> On Fri, Jun 26, 2026 at 04:44:56PM +0100, Conor Dooley wrote:
> > On Thu, Jun 25, 2026 at 12:21:52PM -0700, Drew Fustini wrote:
> > > On Thu, Jun 25, 2026 at 05:19:28PM +0100, Conor Dooley wrote:
> > > > On Wed, Jun 24, 2026 at 06:38:35PM -0700, Drew Fustini wrote:
> > > > > Document the generic compatibles for capacity and bandwidth controllers
> > > > > that implement the RISC-V CBQRI specification. The binding also
> > > > > describes the common riscv,cbqri-rcid and riscv,cbqri-mcid properties,
> > > > > and the optional riscv,cbqri-cache phandle that links a capacity
> > > > > controller to the cache whose capacity it allocates.
> > > > >
> > > > > Assisted-by: Claude:claude-opus-4-8
> > > > > Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > > > > Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > > > > Signed-off-by: Drew Fustini <fustini@kernel.org>
> > > > > ---
> > > > > .../devicetree/bindings/riscv/riscv,cbqri.yaml | 97 ++++++++++++++++++++++
> > > > > MAINTAINERS | 1 +
> > > > > 2 files changed, 98 insertions(+)
> > >
> > > Thanks for the review.
> > >
> > > [..]
> > > > > +properties:
> > > > > + compatible:
> > > > > + oneOf:
> > > > > + - items:
> > > > > + - description: Tenstorrent Ascalon Shared Cache
> > > > > + const: tenstorrent,ascalon-sc-cbqri
> > > > > + - const: riscv,cbqri-capacity-controller
> > > > > + - enum:
> > > > > + - riscv,cbqri-capacity-controller
> > > > > + - riscv,cbqri-bandwidth-controller
> > > >
> > > > Please modify this, as has been done for other riscv spec related
> > > > bindings, to let people get away without using device-specific
> > > > compatibles.
> > > >
> > > > In this case, you can just delete the first entry from this enum, since
> > > > it already has a user and only have to implement this feedback for the
> > > > second entry.
> > >
> > > Would this work?
> > >
> > > properties:
> > > compatible:
> > > oneOf:
> > > - items:
> > > - enum:
> > > - tenstorrent,ascalon-sc-cbqri # Tenstorrent Ascalon Shared Cache
> > > - const: riscv,cbqri-capacity-controller
> > > - items:
> > > - {}
> > > - const: riscv,cbqri-bandwidth-controller
> >
> >
> > Should do, yes. I question the need for a comment though, seems pretty
> > evident from the compatible what it is.
>
> I was thinking people may not know that 'sc' is the Shared Cache. I
> probably should have shortend the comment to 'Ascalon Shared Cache'.
> Anyways, I can drop it.
Or call the device "ascalon-shared-cache-controller"!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] cgroup/cpu: document cpu.stat.local
From: Michal Koutný @ 2026-06-26 16:24 UTC (permalink / raw)
To: Sun Shaojie
Cc: cui.tao, Tejun Heo, Johannes Weiner, Jonathan Corbet, Shuah Khan,
cgroups, linux-doc, linux-kernel
In-Reply-To: <20260626010914.1154495-1-sunshaojie@kylinos.cn>
[-- Attachment #1: Type: text/plain, Size: 1046 bytes --]
Hi.
On Fri, Jun 26, 2026 at 09:09:14AM +0800, Sun Shaojie <sunshaojie@kylinos.cn> wrote:
> + cpu.stat.local
> + A read-only flat-keyed file.
> + This file exists whether the controller is enabled or not.
> +
> + It reports the following stat when the controller is enabled:
> +
> + - throttled_usec
> +
> + Unlike the ``throttled_usec`` reported by ``cpu.stat`` which
> + accounts for throttling caused by this cgroup's own CFS
> + bandwidth limit, ``cpu.stat.local`` reports the actual
> + throttling time incurred by this cgroup's own runqueues,
> + which may include throttling inherited from ancestor
> + cgroup bandwidth limits.
> +
> + When the controller is not enabled, this stat is not reported.
I like that you contrast this to regular cpu.stat and implicitly explain
that cpu.stat is not hierarchical.
Here I think it's been such so long that it's not worth changing (also
it's less useful than existing metrics for diagnostics).
Hence would you also update the cpu.stat paragraph about the
non-hierarchical values?
Thanks,
Michal
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
* [PATCH v2] docs: pagemap: fix flags location, member name and sample code
From: Zenghui Yu @ 2026-06-26 16:27 UTC (permalink / raw)
To: linux-mm, linux-doc, linux-kernel
Cc: akpm, david, ljs, liam, vbabka, rppt, surenb, mhocko, corbet,
skhan, sj, Zenghui Yu
The userland visible page flags (KPF_*) were initially moved to
include/linux/kernel-page-flags.h in commit 1a9b5b7fe0c5 ("mm: export
stable page flags"), and later moved to
include/uapi/linux/kernel-page-flags.h in commit 607ca46e97a1 ("UAPI:
(Scripted) Disintegrate include/linux"). Update the doc to reflect the
current location of these flags.
The member @walk_end of struct pm_scan_arg {} was wrongly written as
"end_walk".
The first sample code of the PAGEMAP_SCAN ioctl wrongly used the
PM_SCAN_CHECK_WPASYNC flag twice, instead of the PM_SCAN_WP_MATCHING flag.
The second one included the wrong category in the required mask -
PAGE_IS_FILE should be used instead of PAGE_IS_SWAPPED as per the
intention.
Fix them all together.
Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
---
* From v1 [1]:
- drop PAGE_IS_SWAPPED in .category_mask (David)
- fix typo in commit message (David)
- didn't collect SeongJae's R-b (as the content has changed anyway) but
thank you for that!
[1] https://lore.kernel.org/20260625174447.24292-1-zenghui.yu@linux.dev
Documentation/admin-guide/mm/pagemap.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst
index c57e61b5d8aa..20e3fe76f099 100644
--- a/Documentation/admin-guide/mm/pagemap.rst
+++ b/Documentation/admin-guide/mm/pagemap.rst
@@ -67,7 +67,7 @@ number of times a page is mapped.
* ``/proc/kpageflags``. This file contains a 64-bit set of flags for each
page, indexed by PFN.
- The flags are (from ``fs/proc/page.c``, above kpageflags_read):
+ The flags are (from ``include/uapi/linux/kernel-page-flags.h``):
0. LOCKED
1. ERROR
@@ -264,7 +264,7 @@ The ``struct pm_scan_arg`` is used as the argument of the IOCTL.
provided or not.
3. The range is specified through ``start`` and ``end``.
4. The walk can abort before visiting the complete range such as the user buffer
- can get full etc. The walk ending address is specified in``end_walk``.
+ can get full etc. The walk ending address is specified in ``walk_end``.
5. The output buffer of ``struct page_region`` array and size is specified in
``vec`` and ``vec_len``.
6. The optional maximum requested pages are specified in the ``max_pages``.
@@ -275,7 +275,7 @@ Find pages which have been written and WP them as well::
struct pm_scan_arg arg = {
.size = sizeof(arg),
- .flags = PM_SCAN_CHECK_WPASYNC | PM_SCAN_CHECK_WPASYNC,
+ .flags = PM_SCAN_WP_MATCHING | PM_SCAN_CHECK_WPASYNC,
..
.category_mask = PAGE_IS_WRITTEN,
.return_mask = PAGE_IS_WRITTEN,
@@ -288,7 +288,7 @@ present or huge::
.size = sizeof(arg),
.flags = 0,
..
- .category_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED,
+ .category_mask = PAGE_IS_WRITTEN | PAGE_IS_FILE,
.category_inverted = PAGE_IS_SWAPPED,
.category_anyof_mask = PAGE_IS_PRESENT | PAGE_IS_HUGE,
.return_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED |
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v10 0/6] mm/memory-failure: add panic option for unrecoverable pages
From: Andrew Morton @ 2026-06-26 16:27 UTC (permalink / raw)
To: Breno Leitao
Cc: Miaohe Lin, David Hildenbrand, Lorenzo Stoakes, Vlastimil Babka,
Mike Rapoport, Suren Baghdasaryan, Michal Hocko, Shuah Khan,
Naoya Horiguchi, Jonathan Corbet, Shuah Khan, Liam R. Howlett,
lance.yang, Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team
In-Reply-To: <20260626-ecc_panic-v10-0-6dacb8ad024d@debian.org>
On Fri, 26 Jun 2026 08:33:14 -0700 Breno Leitao <leitao@debian.org> wrote:
> A multi-bit ECC error on a kernel-owned page that the memory failure
> handler cannot recover is currently swallowed: PG_hwpoison is set, the
> event is logged, and the kernel keeps running. The corrupted memory
> remains accessible to the kernel and either drives silent data
> corruption or surfaces seconds-to-minutes later as an apparently
> unrelated crash. In a large fleet that delayed, unattributable crash
> turns into significant engineering effort to root-cause; in a kdump
> configuration, by the time the crash happens the original error
> context (faulting PFN, MCE/GHES record, page state) is long gone.
>
> This series adds an opt-in sysctl,
> vm.panic_on_unrecoverable_memory_failure, that converts an
> unrecoverable kernel-page hwpoison event into an immediate panic with
> a clean dmesg/vmcore that still contains the original failure
> context. The default is disabled so existing workloads see no
> change.
Cool, thanks. I added this to mm.git's mm-new branch. Next week I'll
move it into the mm-unstable branch, where it will receive linux-next
exposure.
Sashiko identified a few possible things, some pre-existing:
https://sashiko.dev/#/patchset/20260626-ecc_panic-v10-0-6dacb8ad024d@debian.org
^ permalink raw reply
* Re: [PATCH v2] docs: pagemap: fix flags location, member name and sample code
From: David Hildenbrand (Arm) @ 2026-06-26 16:36 UTC (permalink / raw)
To: Zenghui Yu, linux-mm, linux-doc, linux-kernel
Cc: akpm, ljs, liam, vbabka, rppt, surenb, mhocko, corbet, skhan, sj
In-Reply-To: <20260626162710.25844-1-zenghui.yu@linux.dev>
On 6/26/26 18:27, Zenghui Yu wrote:
> The userland visible page flags (KPF_*) were initially moved to
> include/linux/kernel-page-flags.h in commit 1a9b5b7fe0c5 ("mm: export
> stable page flags"), and later moved to
> include/uapi/linux/kernel-page-flags.h in commit 607ca46e97a1 ("UAPI:
> (Scripted) Disintegrate include/linux"). Update the doc to reflect the
> current location of these flags.
>
> The member @walk_end of struct pm_scan_arg {} was wrongly written as
> "end_walk".
>
> The first sample code of the PAGEMAP_SCAN ioctl wrongly used the
> PM_SCAN_CHECK_WPASYNC flag twice, instead of the PM_SCAN_WP_MATCHING flag.
> The second one included the wrong category in the required mask -
> PAGE_IS_FILE should be used instead of PAGE_IS_SWAPPED as per the
> intention.
>
> Fix them all together.
>
> Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v4 2/5] mm/zswap: Factor writeback loop out of shrink_worker()
From: Yosry Ahmed @ 2026-06-26 17:09 UTC (permalink / raw)
To: Hao Jia
Cc: nphamcs, akpm, tj, hannes, shakeel.butt, mhocko, mkoutny,
chengming.zhou, muchun.song, roman.gushchin, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <f1cd1ec9-48b0-1b03-0514-6c9958f3c77f@gmail.com>
> >> /*
> >> * Take one step of a memcg-tree writeback walk driven by the caller's
> >> * iterator, and fold the result into @s, the retry bookkeeping shared
> >> * across steps. @memcg is the iterator's current memcg, or NULL once
> >> * it has wrapped around after a full pass over the tree.
> >> *
> >> * The function returns -EAGAIN to signal the caller to abort the walk
> >> * after encountering the following conditions MAX_RECLAIM_RETRIES times:
> >> * - No writeback-candidate memcgs were found in a memcg tree walk.
> >> * - Shrinking a writeback-candidate memcg failed.
> >
> > Orthogonal to this patch, but I wonder if this can be simplified. I
> > wonder if these two conditions can be replaced with "shrinking a memcg
> > that has zswap entries failed". The "no writeback-candidate memcgs in
> > the tree" case seems like we should abort right away instead of
> > retrying?
> >
> > Nhat, WDYT?
> >
>
> Perhaps something like the following is what you had in mind? I've
> drafted the implementation below to make it easier for Nhat to compare
> with the previous behavior.
Hmm I think if we pursue this it should be in a separate patch or even
outside of this series, ideally with numbers/proof that it's not
introducing regressions to the scenario that lead to its introduction.
>
>
> >> *
> >> * Return: The number of compressed bytes written back (>= 0), or -EAGAIN
> >> * once the retry budget is exhausted and the caller should abort the walk.
> >> */
> >> static long zswap_shrink_one(struct mem_cgroup *memcg,
> >
> > Nit: zswap_shrink_one_memcg()
> >
> > BTW, the existing writeback logic has been broken for a while now when
> > memcg is disabled. I think we constantly hit the !memcg case and run
> > out of retries. Not sure if your patch changes this in any way, or if
> > you want to fix that while you're at it :)
>
> Yes, I'd be happy to do that. However, would it be better to submit a
> separate fix patch or combine it with this one?
A separate patch. Feel free to send it with this series to avoid
conflicts, but probably as patch 1 as we'll want to CC stable on it.
[..]
> /* Track progress of a memcg-tree writeback walk. */
> struct zswap_shrink_state {
> int scans;
> int failures;
> };
>
> /*
> * Take one step of a memcg-tree writeback walk driven by the caller's
> * iterator, and fold the result into @s, the retry bookkeeping shared
> * across steps. @memcg is the iterator's current memcg, or NULL once
> * it has wrapped around after a full pass over the tree.
> *
> * The function returns -EBUSY to signal the caller to abort the walk when
> * either of the following occurs:
> * - A full pass over the tree found no writeback-candidate memcg.
> * - Shrinking a writeback-candidate memcg failed MAX_RECLAIM_RETRIES
> times.
> *
> * When memory cgroup is disabled, the iterator always yields NULL. All
> * zswap entries then live on the root list_lru, so NULL is treated as the
> * root memcg and shrunk directly rather than as a completed tree pass.
I think this chunk should be moved above the code returning -EBUSY
when mem_cgroup_disabled() is true, and probably made more succinct as
it should be obvious.
> *
> * Return: The number of compressed bytes written back (>= 0), or -EBUSY
> * when the caller should abort the walk.
> */
> static long zswap_shrink_one_memcg(struct mem_cgroup *memcg,
> struct zswap_shrink_state *s)
> {
> bool disabled = mem_cgroup_disabled();
No need to store this in a variable AFAICT, it's a static branch and
it's clearer to just call it directly in both call sites imo.
> long shrunk;
>
> /*
> * If the iterator has completed a full pass, update the shrink state
> * and check whether we should keep going.
> * With memcg disabled the iterator always yields NULL, so fall through
> * and shrink the root memcg directly instead.
> */
> if (!memcg && !disabled) {
> /*
> * Abort if no writeback-candidate memcgs in the last tree walk.
> * Otherwise reset the scans count and continue.
> */
> if (!s->scans)
> return -EBUSY;
> s->scans = 0;
> return 0;
> }
>
> shrunk = shrink_memcg(memcg, NR_ZSWAP_WB_BATCH);
>
> /*
> * There are no writeback-candidate pages in the memcg. With memcg
> * enabled this is not an issue as long as we can find another memcg
> * with pages in zswap, so skip without counting it as a candidate.
> * With memcg disabled the root LRU is the only target, so we should
> * abort if it has no writeback-candidate pages.
> */
> if (shrunk == -ENOENT)
> return disabled ? -EBUSY : 0;
> s->scans++;
>
> if (shrunk <= 0 && ++s->failures == MAX_RECLAIM_RETRIES)
> return -EBUSY;
>
> return shrunk;
> }
>
> static void shrink_worker(struct work_struct *w)
> {
> struct zswap_shrink_state s = {};
> unsigned long thr;
>
> /* Reclaim down to the accept threshold */
> thr = zswap_accept_thr_pages();
>
> /*
> * Global reclaim will select cgroup in a round-robin fashion from all
> * online memcgs, but memcgs that have no pages in zswap and
> * writeback-disabled memcgs (memory.zswap.writeback=0) are not
> * candidates for shrinking.
> *
> * We save iteration cursor memcg into zswap_next_shrink,
> * which can be modified by the offline memcg cleaner
> * zswap_memcg_offline_cleanup().
> *
> * Since the offline cleaner is called only once, we cannot leave an
> * offline memcg reference in zswap_next_shrink.
> * We can rely on the cleaner only if we get online memcg under lock.
> *
> * If we get an offline memcg, we cannot determine if the cleaner has
> * already been called or will be called later. We must put back the
> * reference before returning from this function. Otherwise, the
> * offline memcg left in zswap_next_shrink will hold the reference
> * until the next run of shrink_worker().
> */
> while (zswap_total_pages() > thr) {
> struct mem_cgroup *memcg;
> long ret;
>
> cond_resched();
> /*
> * Start shrinking from the next memcg after zswap_next_shrink.
> * When the offline cleaner has already advanced the cursor,
> * advancing the cursor here overlooks one memcg, but this
> * should be negligibly rare.
> *
> * If we get an online memcg, keep the extra reference in case
> * the original one obtained by mem_cgroup_iter() is dropped by
> * zswap_memcg_offline_cleanup() while we are shrinking the
> * memcg.
> */
> spin_lock(&zswap_shrink_lock);
> do {
> memcg = mem_cgroup_iter(NULL, zswap_next_shrink, NULL);
> zswap_next_shrink = memcg;
> } while (memcg && !mem_cgroup_tryget_online(memcg));
> spin_unlock(&zswap_shrink_lock);
>
> ret = zswap_shrink_one_memcg(memcg, &s);
> /* drop the extra reference taken above */
> mem_cgroup_put(memcg);
> if (ret == -EBUSY)
> break;
> }
> }
>
>
> Thanks,
> Hao
^ permalink raw reply
* Re: [PATCH 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub
From: Krishnamoorthy, Saravanakrishnan @ 2026-06-26 17:15 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Albert Ou, Ousherovitch, Alex, Conor Dooley, David S. Miller,
Herbert Xu, Jonathan Corbet, Krzysztof Kozlowski, Palmer Dabbelt,
Paul Walmsley, Rob Herring, Shuah Khan, Alexandre Ghiti,
devicetree@vger.kernel.org, Wittenauer, Joel,
linux-api@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org,
Shuah Khan, SIPSupport, Nguyen, Thi
In-Reply-To: <20260626-radiant-affable-raccoon-f48b9a@quoll>
Hi Krzysztof,
Understood, and apologies. The confidentiality footer was auto-appended by our corporate mail gateway, not something we intended on an open-source submission. We've had IT disable it, so it won't be on future mail. We'll resend the series as v2 without the disclaimer.
Sorry for the noise.
Krishnan (Saravanakrishnan Krishnamoorthy)
________________________________________
From: Krzysztof Kozlowski <krzk@kernel.org>
Sent: Friday, June 26, 2026 3:55 AM
To: Krishnamoorthy, Saravanakrishnan
Cc: Albert Ou; Ousherovitch, Alex; Conor Dooley; David S. Miller; Herbert Xu; Jonathan Corbet; Krzysztof Kozlowski; Palmer Dabbelt; Paul Walmsley; Rob Herring; Shuah Khan; Alexandre Ghiti; devicetree@vger.kernel.org; Wittenauer, Joel; linux-api@vger.kernel.org; linux-crypto@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-kselftest@vger.kernel.org; linux-riscv@lists.infradead.org; Shuah Khan; SIPSupport; Nguyen, Thi
Subject: Re: [PATCH 01/19] dt-bindings: crypto: add Rambus CryptoManager Hub
[Some people who received this message don't often get email from krzk@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Caution: < External Email >
On Thu, Jun 25, 2026 at 10:33:09AM -0700, Saravanakrishnan Krishnamoorthy wrote:
> From: Alex Ousherovitch <aousherovitch@rambus.com>
>
> Add device tree binding schema for the CRI CryptoManager Hub (CMH)
> hardware crypto accelerator. The binding covers the parent SoC-level
> node with register region, interrupt, DMA properties, and per-core
> child nodes identified by compatible string and unit address.
...
>
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
OK, we are done. I am removing your posting from Patchwork.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] Documentation/bpf: make it clear that kfuncs should be non-static
From: JP Kobryn @ 2026-06-26 17:20 UTC (permalink / raw)
To: ast, roman.gushchin, daniel, andrii, eddyz87, memxor, martin.lau,
song, yonghong.song, jolsa, emil, corbet, skhan, bpf
Cc: linux-doc, linux-kernel
The kfunc documentation mentions how the macro __bpf_kfunc prevents
inlining for static functions. This makes it sound like static kfuncs are
acceptable. Although static kfuncs may happen to work, it is by chance that
the compiler chose not to rename these functions and BTF resolution still
succeeds.
Make it clear in the documentation why kfuncs should not be declared
static. First, remove wording that makes it sound like static is ok. Then
point out the external naming needed for BTF resolution. Finally point out
that sparse may warn on unreferenced kfuncs and that this warning can be
ignored.
Signed-off-by: JP Kobryn <jp.kobryn@linux.dev>
---
Documentation/bpf/kfuncs.rst | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst
index 4c814ff6061e..1dbaff8d4805 100644
--- a/Documentation/bpf/kfuncs.rst
+++ b/Documentation/bpf/kfuncs.rst
@@ -276,19 +276,26 @@ This set encodes the BTF ID of each kfunc listed above, and encodes the flags
along with it. Ofcourse, it is also allowed to specify no flags.
kfunc definitions should also always be annotated with the ``__bpf_kfunc``
-macro. This prevents issues such as the compiler inlining the kfunc if it's a
-static kernel function, or the function being elided in an LTO build as it's
-not used in the rest of the kernel. Developers should not manually add
-annotations to their kfunc to prevent these issues. If an annotation is
-required to prevent such an issue with your kfunc, it is a bug and should be
-added to the definition of the macro so that other kfuncs are similarly
-protected. An example is given below::
+macro. This prevents issues such as the compiler inlining the kfunc, or the
+function being elided in an LTO build as it's not used in the rest of the
+kernel. Developers should not manually add annotations to their kfunc to prevent
+these issues. If an annotation is required to prevent such an issue with your
+kfunc, it is a bug and should be added to the definition of the macro so that
+other kfuncs are similarly protected. An example is given below::
__bpf_kfunc struct task_struct *bpf_get_task_pid(s32 pid)
{
...
}
+Note that kfuncs must not be declared ``static``. A kfunc can be called from a
+BPF program ``*.c`` file outside the compilation unit that defines it, so its
+externally visible name must remain available for BTF ID lookup. ``static``
+linkage allows the compiler to rename the function, which can break this
+BTF-based kfunc resolution. Further note that sparse may warn that an otherwise
+unreferenced kfunc should be static. Such warnings should be ignored for kfunc
+definitions.
+
2.5.1 KF_ACQUIRE flag
---------------------
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 19/19] MAINTAINERS: add Rambus CryptoManager Hub (CMH)
From: Krishnamoorthy, Saravanakrishnan @ 2026-06-26 17:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Albert Ou, Ousherovitch, Alex, Conor Dooley, David S. Miller,
Herbert Xu, Jonathan Corbet, Krzysztof Kozlowski, Palmer Dabbelt,
Paul Walmsley, Rob Herring, Shuah Khan, Alexandre Ghiti,
devicetree@vger.kernel.org, Wittenauer, Joel,
linux-api@vger.kernel.org, linux-crypto@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org,
Shuah Khan, SIPSupport, Nguyen, Thi
In-Reply-To: <20260626-lush-eel-of-election-5fcbde@quoll>
Hi Krzysztof,
Thanks for the review - all fair, and we'll fix them in v2:
Drop L: sipsupport@rambus.com (keeping only linux-crypto).
Drop the T: line - we don't maintain a tree; the driver will go through the crypto tree.
Yes, Joel and Thi reviewed and acknowledged with the statement of oversight.
Krishnan
________________________________________
From: Krzysztof Kozlowski <krzk@kernel.org>
Sent: Friday, June 26, 2026 3:57 AM
To: Krishnamoorthy, Saravanakrishnan
Cc: Albert Ou; Ousherovitch, Alex; Conor Dooley; David S. Miller; Herbert Xu; Jonathan Corbet; Krzysztof Kozlowski; Palmer Dabbelt; Paul Walmsley; Rob Herring; Shuah Khan; Alexandre Ghiti; devicetree@vger.kernel.org; Wittenauer, Joel; linux-api@vger.kernel.org; linux-crypto@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-kselftest@vger.kernel.org; linux-riscv@lists.infradead.org; Shuah Khan; SIPSupport; Nguyen, Thi
Subject: Re: [PATCH 19/19] MAINTAINERS: add Rambus CryptoManager Hub (CMH)
[Some people who received this message don't often get email from krzk@kernel.org. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
Caution: < External Email >
On Thu, Jun 25, 2026 at 10:33:27AM -0700, Saravanakrishnan Krishnamoorthy wrote:
> From: Alex Ousherovitch <aousherovitch@rambus.com>
>
> Add MAINTAINERS entry for the CRI CryptoManager Hub (CMH) hardware
> crypto accelerator driver under drivers/crypto/cmh/.
>
> Co-developed-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com>
> Signed-off-by: Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com>
> Signed-off-by: Alex Ousherovitch <aousherovitch@rambus.com>
> Reviewed-by: Joel Wittenauer <Joel.Wittenauer@cryptography.com>
> Reviewed-by: Thi Nguyen <thin@rambus.com>
Are these people really provided you with Reviewer's statement of
oversight? Do they understand what does it mean?
> ---
> MAINTAINERS | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 90034eb7874e..ecb389795e3d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6797,6 +6797,25 @@ F: kernel/cred.c
> F: rust/kernel/cred.rs
> F: Documentation/security/credentials.rst
>
> +CRI CRYPTOMANAGER HUB (CMH) HARDWARE CRYPTO ACCELERATOR
> +M: Alex Ousherovitch <aousherovitch@rambus.com>
> +M: Saravanakrishnan Krishnamoorthy <skrishnamoorthy@rambus.com>
> +R: Joel Wittenauer <Joel.Wittenauer@cryptography.com>
> +R: Thi Nguyen <thin@rambus.com>
> +L: linux-crypto@vger.kernel.org
> +L: sipsupport@rambus.com (moderated for non-subscribers)
NAK, drop. You are not allowed to add here internal moderated mailing
lists. We are not going to participate in your corporate dances.
> +S: Maintained
> +T: git https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
Drop, you do not have commit rights there.
> +F: Documentation/ABI/testing/cmh-mgmt
> +F: Documentation/ABI/testing/debugfs-driver-cmh
> +F: Documentation/ABI/testing/sysfs-driver-cmh
> +F: Documentation/crypto/device_drivers/cmh.rst
> +F: Documentation/devicetree/bindings/crypto/cri,cmh.yaml
> +F: Documentation/userspace-api/ioctl/cmh_mgmt.rst
> +F: drivers/crypto/cmh/
> +F: include/uapi/linux/cmh_mgmt_ioctl.h
> +F: tools/testing/selftests/drivers/crypto/cmh/
> +
> INTEL CRPS COMMON REDUNDANT PSU DRIVER
> M: Ninad Palsule <ninad@linux.ibm.com>
> L: linux-hwmon@vger.kernel.org
> --
> 2.43.7
>
>
> ** This message and any attachments are for the sole use of the intended recipient(s). It may contain information that is confidential and privileged. If you are not the intended recipient of this message, you are prohibited from printing, copying, forwarding or saving it. Please delete the message and attachments and notify the sender immediately. **
Heh, I should have ignored your message...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 06/24] sched/core: allow only preferred CPUs in is_cpu_allowed
From: Shrikanth Hegde @ 2026-06-26 18:43 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, mingo, peterz, juri.lelli, vincent.guittot,
kprateek.nayak, iii, corbet, tglx, gregkh, pbonzini, seanjc,
vschneid, huschle, rostedt, dietmar.eggemann, maddy, srikar,
hdanton, chleroy, vineeth, frederic, arighi, pauld,
christian.loehle, tj, tommaso.cucinotta, maz, rafael, rdunlap,
kernellwp, linux-doc
In-Reply-To: <0a223931-5172-4ed5-a9f8-c2b316a0f6cc@linux.ibm.com>
Hi Yury.
On 6/26/26 6:55 PM, Shrikanth Hegde wrote:
> Hi Yury. Thanks for going through the patches.
>
[...]
>> So, you've got 3 options to declare the status: self-explaining enum,
>> self-explaining #defines, and this random numbers explained in
>> comment. The latter option is the worst to me.
>
> ok. I will define the enums.
>
>>
>> And you didn't provide any benchmark advocating this caching
>> optimization.
I did below to see. Made interval as 100ms.
Ran ./hackbench 30 process 30000 loops in both the VM at the same time.
Values are average of 5 runs.
With optimization:
13.6 seconds
Without optimization:
13.8 seconds
>>
>> Sorry, but NAK.
>>
>
> If we move to local variable then this won;t be necessary,
> just enum's would be enough (I think). Let me go stare at it.
I have made it use the local variable instead. There maybe better names
for variable, put something quickly to check the idea.
Effectively this PATCH 6 becomes:
Does this seems better?
Please let me know your comments.
---
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 9e16946c9d62..fafedd52611f 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2498,8 +2498,10 @@ static inline bool rq_has_pinned_tasks(struct rq *rq)
* Per-CPU kthreads are allowed to run on !active && online CPUs, see
* __set_cpus_allowed_ptr() and select_fallback_rq().
*/
-static inline bool is_cpu_allowed(struct task_struct *p, int cpu)
+static inline bool is_cpu_allowed(struct task_struct *p, int cpu, int cached)
{
+ bool task_check_preferred_cpu;
+
/* When not in the task's cpumask, no point in looking further. */
if (!task_allowed_on_cpu(p, cpu))
return false;
@@ -2508,9 +2510,24 @@ static inline bool is_cpu_allowed(struct task_struct *p, int cpu)
if (is_migration_disabled(p))
return cpu_online(cpu);
+ /*
+ * This is essential to maintain user affinities when preferred
+ * CPUs change. A task pinned on non-preferred CPU should continue
+ * to run there, since this is non-user triggered.
+ *
+ * If CPU is non-preferred and task can run on other CPUs which are
+ * currently preferred, then choose those other CPUs instead.
+ * Overhead is minimal when CPU is preferred.
+ */
+ task_check_preferred_cpu = !cpu_preferred(cpu) &&
+ task_has_preferred_cpus(p, cached);
+
/* Non kernel threads are not allowed during either online or offline. */
- if (!(p->flags & PF_KTHREAD))
+ if (!(p->flags & PF_KTHREAD)) {
+ if (task_check_preferred_cpu)
+ return false;
return cpu_active(cpu);
+ }
/* KTHREAD_IS_PER_CPU is always allowed. */
if (kthread_is_per_cpu(p))
@@ -2520,6 +2537,10 @@ static inline bool is_cpu_allowed(struct task_struct *p, int cpu)
if (cpu_dying(cpu))
return false;
+ /* Try on preferred CPU first if possible*/
+ if (task_check_preferred_cpu)
+ return false;
+
/* But are allowed during online. */
return cpu_online(cpu);
}
@@ -2595,7 +2616,7 @@ static struct rq *__migrate_task(struct rq *rq, struct rq_flags *rf,
__must_hold(__rq_lockp(rq))
{
/* Affinity changed (again). */
- if (!is_cpu_allowed(p, dest_cpu))
+ if (!is_cpu_allowed(p, dest_cpu, NO_CACHED_VAL))
return rq;
rq = move_queued_task(rq, rf, p, dest_cpu);
@@ -3547,7 +3568,15 @@ static int select_fallback_rq(int cpu, struct task_struct *p)
int nid = cpu_to_node(cpu);
const struct cpumask *nodemask = NULL;
enum { cpuset, possible, fail } state = cpuset;
- int dest_cpu;
+ int dest_cpu, has_preferred_cpu;
+
+ /*
+ * Cache the value whether task's affinity spans preferred CPUs.
+ * This helps to avoid repeating the same for each CPU
+ * later in the loop.
+ */
+ has_preferred_cpu = task_has_preferred_cpus(p, NO_CACHED_VAL) ?
+ TASK_HAS_PREFERRED_CPUS : TASK_NO_PREFERRED_CPUS;
/*
* If the node that the CPU is on has been offlined, cpu_to_node()
@@ -3559,7 +3588,7 @@ static int select_fallback_rq(int cpu, struct task_struct *p)
/* Look for allowed, online CPU in same node. */
for_each_cpu(dest_cpu, nodemask) {
- if (is_cpu_allowed(p, dest_cpu))
+ if (is_cpu_allowed(p, dest_cpu, has_preferred_cpu))
return dest_cpu;
}
}
@@ -3567,7 +3596,7 @@ static int select_fallback_rq(int cpu, struct task_struct *p)
for (;;) {
/* Any allowed, online CPU? */
for_each_cpu(dest_cpu, p->cpus_ptr) {
- if (!is_cpu_allowed(p, dest_cpu))
+ if (!is_cpu_allowed(p, dest_cpu, has_preferred_cpu))
continue;
goto out;
@@ -3632,7 +3661,7 @@ int select_task_rq(struct task_struct *p, int cpu, int *wake_flags)
* [ this allows ->select_task() to simply return task_cpu(p) and
* not worry about this generic constraint ]
*/
- if (unlikely(!is_cpu_allowed(p, cpu)))
+ if (unlikely(!is_cpu_allowed(p, cpu, NO_CACHED_VAL)))
cpu = select_fallback_rq(task_cpu(p), p);
return cpu;
@@ -6467,7 +6496,7 @@ static bool try_steal_cookie(int this, int that)
if (p == src->core_pick || p == src->curr)
goto next;
- if (!is_cpu_allowed(p, this))
+ if (!is_cpu_allowed(p, this, NO_CACHED_VAL))
goto next;
if (p->core_occupation > dst->idle->core_occupation)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index c7c2dea65edd..949c044702c1 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -4213,4 +4213,32 @@ DEFINE_CLASS_IS_UNCONDITIONAL(sched_change)
#include "ext.h"
+enum task_preferred_cached {
+ TASK_NO_PREFERRED_CPUS = -1,
+ NO_CACHED_VAL,
+ TASK_HAS_PREFERRED_CPUS,
+};
+
+/*
+ * Value is cached when called via select_fallback_rq().
+ *
+ * TASK_NO_PREFERRED_CPUS : Cached and preferred CPUs exists in task's
+ * affinity.
+ * NO_CACHED_VAL: Not cached and need to evaluate.
+ * TASK_HAS_PREFERRED_CPUS: Cached and preferred CPU doesn't exits
+ * task's affinity
+ *
+ * Only affects FAIR task.
+ */
+static inline bool task_has_preferred_cpus(struct task_struct *p, int cached)
+{
+ /* Only FAIR tasks honor preferred CPU state */
+ if (unlikely(p->sched_class != &fair_sched_class))
+ return false;
+
+ if (cached)
+ return cached > 0;
+ else
+ return cpumask_intersects(p->cpus_ptr, cpu_preferred_mask);
+}
#endif /* _KERNEL_SCHED_SCHED_H */
^ permalink raw reply related
* Re: [PATCH v5 04/24] cpumask: Introduce cpu_preferred_mask
From: Shrikanth Hegde @ 2026-06-26 18:51 UTC (permalink / raw)
To: Peter Zijlstra
Cc: linux-kernel, mingo, juri.lelli, vincent.guittot, yury.norov,
kprateek.nayak, iii, corbet, tglx, gregkh, pbonzini, seanjc,
vschneid, huschle, rostedt, dietmar.eggemann, maddy, srikar,
hdanton, chleroy, vineeth, frederic, arighi, pauld,
christian.loehle, tj, tommaso.cucinotta, maz, rafael, rdunlap,
kernellwp, linux-doc
In-Reply-To: <20260626093901.GN1181229@noisy.programming.kicks-ass.net>
Hi Peter,
On 6/26/26 3:09 PM, Peter Zijlstra wrote:
> On Thu, Jun 25, 2026 at 06:16:28PM +0530, Shrikanth Hegde wrote:
>
>> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
>> index 80211900f373..5a643d608ea6 100644
>> --- a/include/linux/cpumask.h
>> +++ b/include/linux/cpumask.h
>> @@ -120,12 +120,20 @@ extern struct cpumask __cpu_enabled_mask;
>> extern struct cpumask __cpu_present_mask;
>> extern struct cpumask __cpu_active_mask;
>> extern struct cpumask __cpu_dying_mask;
>> +
>> +#ifdef CONFIG_PREFERRED_CPU
>> +extern struct cpumask __cpu_preferred_mask;
>> +#else
>> +#define __cpu_preferred_mask __cpu_active_mask
>> +#endif
>
> This is cure, but does it not result in set_cpu_preferred() changing
> active mask, and it that not somewhat unexpected behaviour?
>
>> #define cpu_possible_mask ((const struct cpumask *)&__cpu_possible_mask)
>> #define cpu_online_mask ((const struct cpumask *)&__cpu_online_mask)
>> #define cpu_enabled_mask ((const struct cpumask *)&__cpu_enabled_mask)
>> #define cpu_present_mask ((const struct cpumask *)&__cpu_present_mask)
>> #define cpu_active_mask ((const struct cpumask *)&__cpu_active_mask)
>> #define cpu_dying_mask ((const struct cpumask *)&__cpu_dying_mask)
>> +#define cpu_preferred_mask ((const struct cpumask *)&__cpu_preferred_mask)
>>
>> extern atomic_t __num_online_cpus;
>> extern unsigned int __num_possible_cpus;
>
>> diff --git a/kernel/cpu.c b/kernel/cpu.c
>> index bc4f7a9ba64e..d623a9c5554a 100644
>> --- a/kernel/cpu.c
>> +++ b/kernel/cpu.c
>> @@ -3107,6 +3107,11 @@ EXPORT_SYMBOL(__cpu_dying_mask);
>> atomic_t __num_online_cpus __read_mostly;
>> EXPORT_SYMBOL(__num_online_cpus);
>>
>> +#ifdef CONFIG_PREFERRED_CPU
>> +struct cpumask __cpu_preferred_mask __read_mostly;
>> +EXPORT_SYMBOL(__cpu_preferred_mask);
>> +#endif
>
> Precedent is definitely towards !GPL exports for this, but could we get
> away with making this one GPL?
>
I think it is better to put EXPORT_SYMBOL_GPL.
So that any module tries to alter it must be a GPL one.
Would be less headache for us i guess.
>
>> @@ -3164,6 +3169,7 @@ void __init boot_cpu_init(void)
>> /* Mark the boot cpu "present", "online" etc for SMP and UP case */
>> set_cpu_online(cpu, true);
>> set_cpu_active(cpu, true);
>> + set_cpu_preferred(cpu, true);
>
> This sets active twice, which is harmless, but wasteful...
>
>> set_cpu_present(cpu, true);
>> set_cpu_possible(cpu, true);
>>
>> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>> index 2f4530eb543f..9e16946c9d62 100644
>> --- a/kernel/sched/core.c
>> +++ b/kernel/sched/core.c
>> @@ -8685,6 +8685,9 @@ int sched_cpu_activate(unsigned int cpu)
>> */
>> sched_set_rq_online(rq, cpu);
>>
>> + /* preferred is subset of active and follows its state */
>> + set_cpu_preferred(cpu, true);
>> +
>> return 0;
>> }
>>
>> @@ -8698,6 +8701,8 @@ int sched_cpu_deactivate(unsigned int cpu)
>> if (ret)
>> return ret;
>>
>> + set_cpu_preferred(cpu, false);
>> +
>> /*
>> * Remove CPU from nohz.idle_cpus_mask to prevent participating in
>> * load balancing when not active
>
> But this one clears active earlier, is that not a problem?
>
> Perhaps it is best if the modifier is a no-op when preferred mask does
> not exist?
Will make it as yury suggested in other thread with ifdefs.
^ permalink raw reply
* Re: [PATCH v4 2/2] tracing: Remove trace_printk.h from kernel.h
From: Nathan Chancellor @ 2026-06-26 19:03 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260626045119.659d1e6b@fedora>
On Fri, Jun 26, 2026 at 04:51:19AM -0400, Steven Rostedt wrote:
> On Thu, 25 Jun 2026 16:41:58 -0700
> Nathan Chancellor <nathan@kernel.org> wrote:
>
>
> > The following diff resolves it for me, should I send it as a separate
> > patch or do you want to just fold it in with a note?
> >
> > diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
> > index 621566345406..2301a701ffbb 100644
> > --- a/include/linux/lockdep.h
> > +++ b/include/linux/lockdep.h
> > @@ -10,6 +10,7 @@
> > #ifndef __LINUX_LOCKDEP_H
> > #define __LINUX_LOCKDEP_H
> >
> > +#include <linux/instruction_pointer.h>
>
> Ah, so the reason for this breakage is because lockdep was relying on
> instruction_pointer.h, that just happened to be included in kernel.h
> via trace_printk.h.
Correct.
> This is a separate issue, so it should be a separate patch. I'll add it
> as patch 1 of this series.
Sounds good, thanks!
> Can you send me the config you used. This didn't trigger in my tests.
It is a plain allmodconfig, for example on arm:
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- allmodconfig lib/test_context-analysis.o
In file included from include/linux/local_lock_internal.h:8,
from include/linux/local_lock.h:5,
from lib/test_context-analysis.c:9:
include/linux/local_lock_internal.h: In function 'local_lock_acquire':
include/linux/lockdep.h:541:87: error: '_THIS_IP_' undeclared (first use in this function)
541 | #define lock_map_acquire(l) lock_acquire_exclusive(l, 0, 0, NULL, _THIS_IP_)
| ^~~~~~~~~
include/linux/lockdep.h:509:88: note: in definition of macro 'lock_acquire_exclusive'
509 | #define lock_acquire_exclusive(l, s, t, n, i) lock_acquire(l, s, t, 0, 1, n, i)
| ^
include/linux/local_lock_internal.h:46:9: note: in expansion of macro 'lock_map_acquire'
46 | lock_map_acquire(&l->dep_map);
| ^~~~~~~~~~~~~~~~
include/linux/lockdep.h:541:87: note: each undeclared identifier is reported only once for each function it appears in
...
I also reproduced it on top of allnoconfig:
$ cat allno.config
CONFIG_CONTEXT_ANALYSIS_TEST=y
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_EXPERT=y
CONFIG_MMU=y
CONFIG_RUNTIME_TESTING_MENU=y
$ make -skj"$(nproc)" ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- KCONFIG_ALLCONFIG=1 clean allnoconfig lib/test_context-analysis.o
<same error as above>
--
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH v8 24/46] KVM: guest_memfd: Make in-place conversion the default\
From: Sean Christopherson @ 2026-06-26 19:06 UTC (permalink / raw)
To: Yan Zhao
Cc: Ackerley Tng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, jmattson, jthoughton, michael.roth, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
tabba, willy, wyihan, forkloop, pratyush, suzuki.poulose,
aneesh.kumar, liam, Paolo Bonzini, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Baoquan He, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <aj3H2sxymOYTWTnE@yzhao56-desk.sh.intel.com>
On Fri, Jun 26, 2026, Yan Zhao wrote:
> On Thu, Jun 25, 2026 at 07:36:28AM -0700, Sean Christopherson wrote:
> > On Thu, Jun 25, 2026, Yan Zhao wrote:
> > And I'm not remotely convinced that prepending allow_ to the param will help
> > end users diagnose "unexpected" memory consumption, in quotes because anyone that
> > is deploying a stack that utilizes out-of-place conversion absolutely needs to
> > understand and plan for the additional memory consumption. I.e. if the memory
> > consumption is "unexpected" to the end user, they likely have far bigger problems.
> My first impression of gmem_in_place_conversion=true was that it enforces gmem
> in-place conversion. However, it actually only enforces per-gmem private/shared
> attribute.
> My worry was that people might think it's a kernel bug if userspace can still
> have shared memory from other sources after they configured
> gmem_in_place_conversion=true.
Ah, I see where you're coming from. FWIW, truly enforcing in-place conversion
is flat out impossible. E.g. userspace can simply replace the memslot, at which
point the memory effectively reverts to shared.
> However, I have no strong opinion if you think gmem_in_place_conversion is good,
> and with the above documentation. :)
Ya, I think this largely a documentation problem. I agree that a param name
like gmem_private_memory_attributes would be more precise, but I think it'd be
far less informative for the vast majority of users that only care whether or
not KVM can do in-place conversion, and don't care about how that is done.
^ permalink raw reply
* Re: [PATCH] docs: fix openSUSE libelf-devel package name
From: Randy Dunlap @ 2026-06-26 19:50 UTC (permalink / raw)
To: David Disseldorp, linux-doc
In-Reply-To: <20260626044804.14258-1-ddiss@suse.de>
On 6/25/26 9:48 PM, David Disseldorp wrote:
> The proposed "zypper install ... libelf-dev" invocation results in an
> error:
> 'libelf-dev' not found in package names. Trying capabilities.
> No provider of 'libelf-dev' found.
>
> openSUSE and derivitives (Tumbleweed, Leap and SLES) use a "devel"
> suffix instead of "dev".
>
> Link: https://build.opensuse.org/projects/openSUSE:Factory/packages/elfutils/files/elfutils.spec
> Signed-off-by: David Disseldorp <ddiss@suse.de>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
> ---
> Documentation/admin-guide/quickly-build-trimmed-linux.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> index cb178e0a62084..f6b31d7207ff6 100644
> --- a/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> +++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
> @@ -446,7 +446,7 @@ distributions:
> * openSUSE and derivatives::
>
> sudo zypper install bc binutils bison dwarves flex gcc git make perl-base \
> - openssl openssl-devel libelf-dev
> + openssl openssl-devel libelf-devel
>
> In case you wonder why these lists include openssl and its development headers:
> they are needed for the Secure Boot support, which many distributions enable in
--
~Randy
^ permalink raw reply
* Re: [PATCH] Documentation/bpf: make it clear that kfuncs should be non-static
From: Randy Dunlap @ 2026-06-26 19:53 UTC (permalink / raw)
To: JP Kobryn, ast, roman.gushchin, daniel, andrii, eddyz87, memxor,
martin.lau, song, yonghong.song, jolsa, emil, corbet, skhan, bpf
Cc: linux-doc, linux-kernel
In-Reply-To: <20260626172026.7327-1-jp.kobryn@linux.dev>
On 6/26/26 10:20 AM, JP Kobryn wrote:
> The kfunc documentation mentions how the macro __bpf_kfunc prevents
> inlining for static functions. This makes it sound like static kfuncs are
> acceptable. Although static kfuncs may happen to work, it is by chance that
> the compiler chose not to rename these functions and BTF resolution still
> succeeds.
>
> Make it clear in the documentation why kfuncs should not be declared
> static. First, remove wording that makes it sound like static is ok. Then
> point out the external naming needed for BTF resolution. Finally point out
> that sparse may warn on unreferenced kfuncs and that this warning can be
> ignored.
>
> Signed-off-by: JP Kobryn <jp.kobryn@linux.dev>
> ---
> Documentation/bpf/kfuncs.rst | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst
> index 4c814ff6061e..1dbaff8d4805 100644
> --- a/Documentation/bpf/kfuncs.rst
> +++ b/Documentation/bpf/kfuncs.rst
> @@ -276,19 +276,26 @@ This set encodes the BTF ID of each kfunc listed above, and encodes the flags
> along with it. Ofcourse, it is also allowed to specify no flags.
>
Not part of this patch, but "Ofcourse," should be "Of course,"
of course.
--
~Randy
^ permalink raw reply
* Re: [PATCH] Documentation/bpf: make it clear that kfuncs should be non-static
From: Roman Gushchin @ 2026-06-26 23:57 UTC (permalink / raw)
To: JP Kobryn
Cc: ast, daniel, andrii, eddyz87, memxor, martin.lau, song,
yonghong.song, jolsa, emil, corbet, skhan, bpf, linux-doc,
linux-kernel
In-Reply-To: <20260626172026.7327-1-jp.kobryn@linux.dev>
JP Kobryn <jp.kobryn@linux.dev> writes:
> The kfunc documentation mentions how the macro __bpf_kfunc prevents
> inlining for static functions. This makes it sound like static kfuncs are
> acceptable. Although static kfuncs may happen to work, it is by chance that
> the compiler chose not to rename these functions and BTF resolution still
> succeeds.
>
> Make it clear in the documentation why kfuncs should not be declared
> static. First, remove wording that makes it sound like static is ok. Then
> point out the external naming needed for BTF resolution. Finally point out
> that sparse may warn on unreferenced kfuncs and that this warning can be
> ignored.
>
> Signed-off-by: JP Kobryn <jp.kobryn@linux.dev>
> ---
> Documentation/bpf/kfuncs.rst | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst
> index 4c814ff6061e..1dbaff8d4805 100644
> --- a/Documentation/bpf/kfuncs.rst
> +++ b/Documentation/bpf/kfuncs.rst
> @@ -276,19 +276,26 @@ This set encodes the BTF ID of each kfunc listed above, and encodes the flags
> along with it. Ofcourse, it is also allowed to specify no flags.
>
> kfunc definitions should also always be annotated with the ``__bpf_kfunc``
> -macro. This prevents issues such as the compiler inlining the kfunc if it's a
> -static kernel function, or the function being elided in an LTO build as it's
> -not used in the rest of the kernel. Developers should not manually add
> -annotations to their kfunc to prevent these issues. If an annotation is
> -required to prevent such an issue with your kfunc, it is a bug and should be
> -added to the definition of the macro so that other kfuncs are similarly
> -protected. An example is given below::
> +macro. This prevents issues such as the compiler inlining the kfunc, or the
> +function being elided in an LTO build as it's not used in the rest of the
> +kernel. Developers should not manually add annotations to their kfunc to prevent
> +these issues. If an annotation is required to prevent such an issue with your
> +kfunc, it is a bug and should be added to the definition of the macro so that
> +other kfuncs are similarly protected. An example is given below::
>
> __bpf_kfunc struct task_struct *bpf_get_task_pid(s32 pid)
> {
> ...
> }
>
> +Note that kfuncs must not be declared ``static``. A kfunc can be called from a
> +BPF program ``*.c`` file outside the compilation unit that defines it, so its
> +externally visible name must remain available for BTF ID lookup. ``static``
> +linkage allows the compiler to rename the function, which can break this
> +BTF-based kfunc resolution. Further note that sparse may warn that an otherwise
> +unreferenced kfunc should be static. Such warnings should be ignored for kfunc
> +definitions.
> +
> 2.5.1 KF_ACQUIRE flag
> ---------------------
Acked-by: Roman Gushchin <roman.gushchin@linux.dev>
Thanks
^ permalink raw reply
* Re: [PATCH v2] docs: pagemap: fix flags location, member name and sample code
From: SeongJae Park @ 2026-06-27 0:15 UTC (permalink / raw)
To: Zenghui Yu
Cc: SeongJae Park, linux-mm, linux-doc, linux-kernel, akpm, david,
ljs, liam, vbabka, rppt, surenb, mhocko, corbet, skhan
In-Reply-To: <20260626162710.25844-1-zenghui.yu@linux.dev>
On Sat, 27 Jun 2026 00:27:10 +0800 Zenghui Yu <zenghui.yu@linux.dev> wrote:
> The userland visible page flags (KPF_*) were initially moved to
> include/linux/kernel-page-flags.h in commit 1a9b5b7fe0c5 ("mm: export
> stable page flags"), and later moved to
> include/uapi/linux/kernel-page-flags.h in commit 607ca46e97a1 ("UAPI:
> (Scripted) Disintegrate include/linux"). Update the doc to reflect the
> current location of these flags.
>
> The member @walk_end of struct pm_scan_arg {} was wrongly written as
> "end_walk".
>
> The first sample code of the PAGEMAP_SCAN ioctl wrongly used the
> PM_SCAN_CHECK_WPASYNC flag twice, instead of the PM_SCAN_WP_MATCHING flag.
> The second one included the wrong category in the required mask -
> PAGE_IS_FILE should be used instead of PAGE_IS_SWAPPED as per the
> intention.
>
> Fix them all together.
>
> Signed-off-by: Zenghui Yu <zenghui.yu@linux.dev>
> ---
>
> * From v1 [1]:
> - drop PAGE_IS_SWAPPED in .category_mask (David)
> - fix typo in commit message (David)
Good catches!
> - didn't collect SeongJae's R-b (as the content has changed anyway) but
> thank you for that!
Let me give it again :)
Reviewed-by: SeongJae Park <sj@kernel.org>
>
> [1] https://lore.kernel.org/20260625174447.24292-1-zenghui.yu@linux.dev
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH net-next] Documentation: networking: Add a test plan for ethtool pause validation
From: Jakub Kicinski @ 2026-06-27 0:33 UTC (permalink / raw)
To: Andrew Lunn
Cc: Maxime Chevallier, davem, Eric Dumazet, Paolo Abeni, Simon Horman,
Russell King, Heiner Kallweit, Jonathan Corbet, Shuah Khan,
Oleksij Rempel, Vladimir Oltean, Florian Fainelli,
thomas.petazzoni, netdev, linux-kernel, linux-doc
In-Reply-To: <5b7dbdbc-93fd-4664-abad-0f47855fab55@lunn.ch>
On Fri, 26 Jun 2026 14:39:57 +0200 Andrew Lunn wrote:
> On Fri, Jun 26, 2026 at 10:33:50AM +0200, Maxime Chevallier wrote:
> >
> > > Sphinx follows pythons object orientate structure. So you could have a
> > > class test_ethtool_pause_advertising, with class documentation. And
> > > then methods within the class which are individual tests. The
> > > commented out section would then be method documentation.
> >
> > Good point, so maybe something along these lines :
> >
> > - A class for the test
> > - methods for indivitual tests
> > - For readability, I've written what the internal test helper would look
> > like (_adv_test), and how a test would look like without the helper in
> > adv_rx_on_tx_on().
> >
> > I'm already diving into coding, but it helps me a bit in the definition of the
> > "description" format :)
> >
> > this is what the class would look like :
>
> I like this :-)
This is very far from what existing python tests do in netdev.
I would prefer to stick to the "bash on steroids" use of Python.
Are you both familiar with the existing tests?
^ permalink raw reply
* [PATCH v5 00/38] VKMS: Introduce multiple configFS attributes
From: Louis Chauvet @ 2026-06-27 3:30 UTC (permalink / raw)
To: Haneen Mohammed, Simona Vetter, Melissa Wen, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, jose.exposito89,
Jonathan Corbet, Shuah Khan, Miguel Ojeda, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt
Cc: Luca Ceresoli, Kory Maincent, victoria, sebastian.wick, victoria,
airlied, thomas.petazzoni, dri-devel, linux-kernel, linux-doc,
Louis Chauvet, llvm, José Expósito
VKMS have a wide range of options. The aim of this series is to introduce
many configfs attribute so VKMS can be used to test a wide range of
configurations.
PATCH 1-5 are to expose human readable strings from drm core
PATCH 6 is a fix for rotation value
PATCH 7 is ABI documentation
PATCH 8 added some error checks in plane configuration
PATCH 9 cleanup in plane_release
PATCH 10-12 change the display in configfs to be more readable
PATCH 13,14 plane name
PATCH 15,16 plane rotation
PATCH 17,18 plane color encoding
PATCH 19,20 plane color range
PATCH 21,22 plane format
PATCH 23 properly use zpos
PATCH 24,25 plane zpos
PATCH 26,27 connector type
PATCH 28 preparation in connector initialization
PATCH 29,30 connector supported colorspace
PATCH 31,32 connector EDID
PATCH 33-35 dynamic connectors
PATCH 36-37 PATH property
PS: Each pair of config/configfs patch are independant. I could
technically create ≈10 different series, but there will be a lot of
(trivial) conflicts between them. I will be happy to reordoer, split and
partially apply this series to help the review process.
PS2: I am currently cleaning the IGT test series to validate all that,
it should come on Monday/Tuesday
Signed-off-by: Louis Chauvet <louis.chauvet@bootlin.com>
---
Changes in v5:
- Fixed missing property creation for PATH
- Use the folder name instead of a new attribute for plane
- Rebased on drm-misc-next
- Link to v4: https://patch.msgid.link/20260422-vkms-all-config-v4-0-dbb52e9aadc3@bootlin.com
Changes in v4:
- Introduced a way to change the PATH property
- Reordered drm-only patches to the front of the series.
- Fixed a bug when dynamic connector are allocated/freed (drmm instead of
kzalloc)
- Properly handle errors in vkms_connector_init
- Only parse formats one by one (no more complex algorithm, you will have
to write multiple times for multiple formats)
- Use sysfs_emit instead of sprintf
- Fix rotate property default value
- Link to v3: https://lore.kernel.org/r/20251222-vkms-all-config-v3-0-ba42dc3fb9ff@bootlin.com
Changes in v3:
- Added Documentation/ABI (Thomas Petazzoni)
- PATCH 2: Clarify return value
- PATCH 6,7: Avoid passing null to printf
- PATCH 7: Restrict plane name to A-Za-z0-9
- PATCH 12: Fix missing s
- PATCH 13: Add macro to avoid repetition, fix missing s, make code
consistent, remove wrong comment, properly check bit values
- PATCH 15: Fix missing s
- PATCH 16: Fix missing s, make code consistent, remove wrong comments,
properly check value and fix default_color_range value
- PATCH 17: Create function to reduce code complexity, fix missing s
- PATCH 18: Fix parsing, rename data, reject strings > 4 chars
- PATCH 20: Remove duplicated lines, fix test comments simplify conditions,
remove useless documentation,
- PATCH 21: {Min,Max}imal -> {Min,Max}imum, simplify commit log
- PATCH 25: Fix wrong comment
- PATCH 26: Rename type to colorspaces
- PATCH 27: Improve comment, avoid useless iterations
- PATCH 28: Fix typo in commit log
- PATCH 29: Fix typo in commit log
- PATCH 30: Remove useless include and move it to proper commit
- PATCH 32: Clarify documentation
- PATCH 33: Simplify code and use better variable names
- PATCH *: Fix EINVAL/EBUSY
- Link to v2: https://lore.kernel.org/r/20251029-vkms-all-config-v2-0-be20b9bf146e@bootlin.com
Changes in v2:
- PATCH 1: reorder includes (José)
- PATCH 2: use name property instead of folder name (José)
- PATCH 3: Fix default rotations (José)
- PATCH 3,5,7,12: Add tests and extract validation for planes (José)
- PATCH 3,5: Do not create color range/encoding properties if not set
- PATCH 5,6,7,8: Set plural form for vkms_config_plane fields (José)
- PATCH 4,6,8,13: Remove checking for default in supported (José)
- PATCH 9: Add break in vkms_config_plane_add_format (José)
- PATCH 12: fix zpos_enabled typo (José)
- PATCH 13: fix documentation (José)
- Add debug display (José)
- PATCH 20: use drmm_kzalloc instead of kzalloc (José)
- PATCH 22: simplify the code (José)
- Link to v1: https://lore.kernel.org/r/20251018-vkms-all-config-v1-0-a7760755d92d@bootlin.com
To: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
To: Maxime Ripard <mripard@kernel.org>
To: Thomas Zimmermann <tzimmermann@suse.de>
To: David Airlie <airlied@gmail.com>
To: Simona Vetter <simona@ffwll.ch>
To: Louis Chauvet <louis.chauvet@bootlin.com>
To: Haneen Mohammed <hamohammed.sa@gmail.com>
To: Melissa Wen <melissa.srw@gmail.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
To: Miguel Ojeda <ojeda@kernel.org>
To: Nathan Chancellor <nathan@kernel.org>
To: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
To: Bill Wendling <morbo@google.com>
To: Justin Stitt <justinstitt@google.com>
Cc: thomas.petazzoni@bootlin.com
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: llvm@lists.linux.dev
---
Louis Chauvet (38):
drm/drm_mode_config: Add helper to get plane type name
drm/blend: Get a rotation name from it's bitfield
drm/drm_color_mgmt: Expose drm_get_color_encoding_name
drm/drm_color_mgmt: Expose drm_get_color_range_name
drm/connector: Export drm_get_colorspace_name
drm/drm_atomic_state_helper: Properly load default value for rotation
Documentation: ABI: vkms: Add current VKMS ABI documentation
drm/vkms: Add error handling in plane config creation
drm/vkms: Simplify plane_release code
drm/vkms: Explicitly display plane type
drm/vkms: Use enabled/disabled instead of 1/0 for debug
drm/vkms: Explicitly display connector status
drm/vkms: Introduce config for plane name
drm/vkms: Use plane folder name as plane name
drm/vkms: Introduce config for plane rotation
drm/vkms: Use DRM_ROTATION_FMT macros for rotation display
drm/vkms: Introduce configfs for plane rotation
drm/vkms: Introduce config for plane color encoding
drm/vkms: Introduce configfs for plane color encoding
drm/vkms: Introduce config for plane color range
drm/vkms: Introduce configfs for plane color range
drm/vkms: Introduce config for plane format
drm/vkms: Introduce configfs for plane format
drm/vkms: Properly render plane using their zpos
drm/vkms: Introduce config for plane zpos property
drm/vkms: Introduce configfs for plane zpos property
drm/vkms: Introduce config for connector type
drm/vkms: Introduce configfs for connector type
drm/vkms: Rename vkms_connector_init to vkms_connector_init_static
drm/vkms: Introduce config for connector supported colorspace
drm/vkms: Introduce configfs for connector supported colorspace
drm/vkms: Introduce config for connector EDID
drm/vkms: Introduce configfs for connector EDID
drm/vkms: Store the enabled/disabled status for connector
drm/vkms: Allow to hot-add connectors
drm/vkms: Introduce configfs for dynamic connector creation
drm/vkms: Add connector parent configuration in vkms_config
drm/vkms: Add ConfigFS interface for connector parent and port_id
.clang-format | 2 +
Documentation/ABI/testing/configfs-vkms | 250 ++++
Documentation/gpu/vkms.rst | 44 +-
drivers/gpu/drm/drm_atomic_state_helper.c | 6 +
drivers/gpu/drm/drm_blend.c | 35 +-
drivers/gpu/drm/drm_color_mgmt.c | 4 +-
drivers/gpu/drm/drm_connector.c | 1 +
drivers/gpu/drm/drm_crtc_internal.h | 6 -
drivers/gpu/drm/drm_mode_config.c | 16 +
drivers/gpu/drm/vkms/tests/Makefile | 3 +-
drivers/gpu/drm/vkms/tests/vkms_config_test.c | 513 ++++++++-
drivers/gpu/drm/vkms/tests/vkms_configfs_test.c | 102 ++
drivers/gpu/drm/vkms/vkms_config.c | 421 ++++++-
drivers/gpu/drm/vkms/vkms_config.h | 641 ++++++++++-
drivers/gpu/drm/vkms/vkms_configfs.c | 1402 +++++++++++++++++++----
drivers/gpu/drm/vkms/vkms_configfs.h | 4 +
drivers/gpu/drm/vkms/vkms_connector.c | 268 ++++-
drivers/gpu/drm/vkms/vkms_connector.h | 48 +-
drivers/gpu/drm/vkms/vkms_crtc.c | 10 +-
drivers/gpu/drm/vkms/vkms_output.c | 15 +-
drivers/gpu/drm/vkms/vkms_plane.c | 73 +-
include/drm/drm_blend.h | 17 +
include/drm/drm_color_mgmt.h | 3 +
include/drm/drm_mode_config.h | 3 +
24 files changed, 3581 insertions(+), 306 deletions(-)
---
base-commit: 6648301c5bb2ef23f0fb15bcb01d21ff66f36799
change-id: 20251017-vkms-all-config-bd0c2a01846f
Best regards,
--
Louis Chauvet <louis.chauvet@bootlin.com>
^ 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