* [PATCH v4 3/3] drm/panthor: Reduce padding in gems debugfs for refcount
From: Nicolas Frattaroli @ 2026-05-20 13:04 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Boris Brezillon, Steven Price, Liviu Dudau,
Jonathan Corbet, Shuah Khan, Tvrtko Ursulin
Cc: dri-devel, linux-kernel, kernel, linux-doc, Nicolas Frattaroli
In-Reply-To: <20260520-panthor-bo-reclaim-observability-v4-0-a47ab61cb80d@collabora.com>
The "gems" debugfs file is getting a little too wide for comfort. While
a lot of this is unavoidable due to the theoretical upper limits of
numbers here (e.g. size needs to be 16 chars because 2**48-1 in decimal
is 15 digits, plus one space for separation), the refcount column has a
decent 5 characters to be saved, as it can only ever contain a 10-digit
decimal number.
Reduce the refcount column's width to 11, which fulfils this requirement
with an additional space for separation.
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/panthor/panthor_gem.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
index 068aa935c8fc..dfdcda3d0189 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.c
+++ b/drivers/gpu/drm/panthor/panthor_gem.c
@@ -1644,7 +1644,7 @@ static void panthor_gem_debugfs_bo_print(struct panthor_gem_object *bo,
snprintf(creator_info, sizeof(creator_info),
"%s/%d", bo->debugfs.creator.process_name, bo->debugfs.creator.tgid);
- seq_printf(m, "%-32s%-16d%-16d%-11d%-16zd%-16zd0x%-16lx",
+ seq_printf(m, "%-32s%-16d%-11d%-11d%-16zd%-16zd0x%-16lx",
creator_info,
bo->base.name,
refcount,
@@ -1681,8 +1681,8 @@ static void panthor_gem_debugfs_print_bos(struct panthor_device *ptdev,
panthor_gem_debugfs_print_flag_names(m);
- seq_puts(m, "created-by global-name refcount evictions size resident-size file-offset state usage label\n");
- seq_puts(m, "---------------------------------------------------------------------------------------------------------------------------------------------------------\n");
+ seq_puts(m, "created-by global-name refcount evictions size resident-size file-offset state usage label\n");
+ seq_puts(m, "----------------------------------------------------------------------------------------------------------------------------------------------------\n");
scoped_guard(mutex, &ptdev->gems.lock) {
list_for_each_entry(bo, &ptdev->gems.node, debugfs.node) {
@@ -1690,7 +1690,7 @@ static void panthor_gem_debugfs_print_bos(struct panthor_device *ptdev,
}
}
- seq_puts(m, "=========================================================================================================================================================\n");
+ seq_puts(m, "====================================================================================================================================================\n");
seq_printf(m, "Total size: %zd, Total resident: %zd, Total reclaimable: %zd\n",
totals.size, totals.resident, totals.reclaimable);
}
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v4 0/4] Introduce Per-CPU Work helpers (was QPW)
From: Sebastian Andrzej Siewior @ 2026-05-20 13:09 UTC (permalink / raw)
To: Leonardo Bras
Cc: Jonathan Corbet, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Thomas Gleixner, Feng Tang, Dapeng Mi, Kees Cook,
Marco Elver, Jakub Kicinski, Li RongQing, Eric Biggers,
Paul E. McKenney, Nathan Chancellor, Miguel Ojeda, Nicolas Schier,
Thomas Weißschuh, Douglas Anderson, Gary Guo,
Christian Brauner, Pasha Tatashin, Masahiro Yamada, Coiby Xu,
Frederic Weisbecker, linux-doc, linux-kernel, linux-mm,
linux-rt-devel
In-Reply-To: <20260519012754.240804-1-leobras.c@gmail.com>
On 2026-05-18 22:27:46 [-0300], Leonardo Bras wrote:
> The problem:
> Some places in the kernel implement a parallel programming strategy
> consisting on local_locks() for most of the work, and some rare remote
> operations are scheduled on target cpu. This keeps cache bouncing low since
> cacheline tends to be mostly local, and avoids the cost of locks in non-RT
> kernels, even though the very few remote operations will be expensive due
> to scheduling overhead.
>
> On the other hand, for RT workloads this can represent a problem: getting
> an important workload scheduled out to deal with remote requests is
> sure to introduce unexpected deadline misses.
>
> The idea:
> Currently with PREEMPT_RT=y, local_locks() become per-cpu spinlocks.
It does not become a _spin_lock because it does not spin. It sleeps.
> In this case, instead of scheduling work on a remote cpu, it should
> be safe to grab that remote cpu's per-cpu spinlock and run the required
> work locally. That major cost, which is un/locking in every local function,
> already happens in PREEMPT_RT.
We did have this before but only in the RT tree. It was a bit messy from
the naming because it started with local_ but then it was a remote CPU.
The main issue was the different code path which led to a few deadlocks
back then.
By the time local_lock_t went upstream, the cross-CPU locking was
removed. As far as I remember, the cross-CPU user which did schedule
work on a remote CPU and annoyed NOHZ folks were replaced.
> Also, there is no need to worry about extra cache bouncing:
> The cacheline invalidation already happens due to schedule_work_on().
>
> This will avoid schedule_work_on(), and thus avoid scheduling-out an
> RT workload.
>
> Proposed solution:
> A new interface called PerCPU Work (PW), which should replace
> Work Queue in the above mentioned use case.
>
> If CONFIG_PWLOCKS=n this interfaces just wraps the current
> local_locks + WorkQueue behavior, so no expected change in runtime.
>
> If CONFIG_PWLOCKS=y, and kernel boot option pwlocks=1,
> pw_queue_on(cpu,...) will lock that cpu's per-cpu structure
> and perform work on it locally.
>
Sebastian
^ permalink raw reply
* Re: [PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team
From: Jonathan Corbet @ 2026-05-20 13:07 UTC (permalink / raw)
To: Sasha Levin, patches, stable
Cc: Willy Tarreau, Greg KH, Leon Romanovsky, Sasha Levin, security,
workflows, linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-63-sashal@kernel.org>
Sasha Levin <sashal@kernel.org> writes:
> From: Willy Tarreau <w@1wt.eu>
>
> [ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]
>
> With the increase of automated reports, the security team is dealing
> with way more messages than really needed. The reporting process works
> well with most teams so there is no need to systematically involve the
> security team in reports.
You'll want, at a minimum, f2e65e4e5b4b4b9ecf43f03c3fdbe8c9a8a43a9e to
go with this, or you'll add a broken reference with this commit.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 1/2] tools/mm: add a standalone GUP microbenchmark
From: Sarthak Sharma @ 2026-05-20 13:06 UTC (permalink / raw)
To: Mike Rapoport, Mark Brown
Cc: Andrew Morton, David Hildenbrand, Jonathan Corbet,
Jason Gunthorpe, John Hubbard, Peter Xu, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Shuah Khan, linux-mm, linux-kselftest, linux-kernel,
linux-doc
In-Reply-To: <ag2v6KW8E94kl4M_@kernel.org>
On 5/20/26 6:28 PM, Mike Rapoport wrote:
> On Wed, May 20, 2026 at 12:58:32PM +0100, Mark Brown wrote:
>> On Wed, May 20, 2026 at 03:45:53PM +0530, Sarthak Sharma wrote:
>>> On 5/20/26 2:25 PM, Mike Rapoport wrote:
>>
>>>> It seems that we need to better share the common code in
>>>> tools/testing/selftest.
>>
>>>> And adding another copy of the hugetlb detection and setup code does not
>>>> seem like a great idea.
>>
>>> Agreed, but that was the least disruptive approach I could think of.
>>
>>> I am thinking of doing this now: should I move the
>>> hugepage_settings.[ch] to tools/lib/ and move the read_num(),
>>> write_num(), read_file() and write_file() helpers to a separate file in
>
> these might need some adjustments because they use ksft_(), but in general
> it makes sense to me.
>
>>> tools/lib/ itself without any ksft dependency? Then both
>>> tools/testing/selftests/* and tools/mm/ could share the same code.
>>
>> Using tools/lib sounds sensible to me - as well as the sharing it makes
>> it clear that it's a library used by multiple things so avoids the
>> issues we sometimes have with selftest directories referencing each
>> other.
>
> I'd make it tools/lib/mm as most of the files tools/lib/*.c are stubs for
> the kernel functions.
>
Thanks Mark and Mike, I'll include these changes in v3.
^ permalink raw reply
* [PATCH v4 2/3] drm/panthor: Implement evicted status for GEM objects
From: Nicolas Frattaroli @ 2026-05-20 13:04 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Boris Brezillon, Steven Price, Liviu Dudau,
Jonathan Corbet, Shuah Khan, Tvrtko Ursulin
Cc: dri-devel, linux-kernel, kernel, linux-doc, Nicolas Frattaroli
In-Reply-To: <20260520-panthor-bo-reclaim-observability-v4-0-a47ab61cb80d@collabora.com>
For fdinfo to be able to fill its evicted counter with data, panthor
needs to keep track of whether a GEM object has ever been reclaimed.
Just checking whether the pages are resident isn't enough, as newly
allocated objects also won't be resident.
Do this with a new atomic_t member on panthor_gem_object. It's increased
when an object gets evicted by the shrinker, and saturates at INT_MAX.
This means that once an object has been evicted at least once, its
reclaim counter will never return to 0.
Due to this, it's possible to distinguish evicted non-resident pages
from newly allocated non-resident pages by checking whether
reclaimed_count is != 0
Use this new member to then set the appropriate DRM_GEM_OBJECT_EVICTED
status flag for fdinfo.
Also add a new column and status flag to the panthor gems debugfs: the
column is the number of times an object has been evicted, whereas the
flag indicates whether it currently is evicted.
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/panthor/panthor_gem.c | 18 ++++++++++++++----
drivers/gpu/drm/panthor/panthor_gem.h | 10 ++++++++++
2 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panthor/panthor_gem.c b/drivers/gpu/drm/panthor/panthor_gem.c
index 13295d7a593d..068aa935c8fc 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.c
+++ b/drivers/gpu/drm/panthor/panthor_gem.c
@@ -687,6 +687,8 @@ static void panthor_gem_evict_locked(struct panthor_gem_object *bo)
if (drm_WARN_ON_ONCE(bo->base.dev, !bo->backing.pages))
return;
+ atomic_add_unless(&bo->reclaimed_count, 1, INT_MAX);
+
panthor_gem_dev_map_cleanup_locked(bo);
panthor_gem_backing_cleanup_locked(bo);
panthor_gem_update_reclaim_state_locked(bo, NULL);
@@ -788,6 +790,8 @@ static enum drm_gem_object_status panthor_gem_status(struct drm_gem_object *obj)
if (drm_gem_is_imported(&bo->base) || bo->backing.pages)
res |= DRM_GEM_OBJECT_RESIDENT;
+ else if (atomic_read(&bo->reclaimed_count))
+ res |= DRM_GEM_OBJECT_EVICTED;
return res;
}
@@ -1595,6 +1599,7 @@ static void panthor_gem_debugfs_print_flag_names(struct seq_file *m)
static const char * const gem_state_flags_names[] = {
[PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT] = "imported",
[PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT] = "exported",
+ [PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT] = "evicted",
};
static const char * const gem_usage_flags_names[] = {
@@ -1625,6 +1630,7 @@ static void panthor_gem_debugfs_bo_print(struct panthor_gem_object *bo,
{
enum panthor_gem_reclaim_state reclaim_state = bo->reclaim_state;
unsigned int refcount = kref_read(&bo->base.refcount);
+ int reclaimed_count = atomic_read(&bo->reclaimed_count);
char creator_info[32] = {};
size_t resident_size;
u32 gem_usage_flags = bo->debugfs.flags;
@@ -1638,16 +1644,20 @@ static void panthor_gem_debugfs_bo_print(struct panthor_gem_object *bo,
snprintf(creator_info, sizeof(creator_info),
"%s/%d", bo->debugfs.creator.process_name, bo->debugfs.creator.tgid);
- seq_printf(m, "%-32s%-16d%-16d%-16zd%-16zd0x%-16lx",
+ seq_printf(m, "%-32s%-16d%-16d%-11d%-16zd%-16zd0x%-16lx",
creator_info,
bo->base.name,
refcount,
+ reclaimed_count,
bo->base.size,
resident_size,
drm_vma_node_start(&bo->base.vma_node));
if (drm_gem_is_imported(&bo->base))
gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED;
+ else if (!resident_size && reclaimed_count)
+ gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED;
+
if (bo->base.dma_buf)
gem_state_flags |= PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED;
@@ -1671,8 +1681,8 @@ static void panthor_gem_debugfs_print_bos(struct panthor_device *ptdev,
panthor_gem_debugfs_print_flag_names(m);
- seq_puts(m, "created-by global-name refcount size resident-size file-offset state usage label\n");
- seq_puts(m, "----------------------------------------------------------------------------------------------------------------------------------------------\n");
+ seq_puts(m, "created-by global-name refcount evictions size resident-size file-offset state usage label\n");
+ seq_puts(m, "---------------------------------------------------------------------------------------------------------------------------------------------------------\n");
scoped_guard(mutex, &ptdev->gems.lock) {
list_for_each_entry(bo, &ptdev->gems.node, debugfs.node) {
@@ -1680,7 +1690,7 @@ static void panthor_gem_debugfs_print_bos(struct panthor_device *ptdev,
}
}
- seq_puts(m, "==============================================================================================================================================\n");
+ seq_puts(m, "=========================================================================================================================================================\n");
seq_printf(m, "Total size: %zd, Total resident: %zd, Total reclaimable: %zd\n",
totals.size, totals.resident, totals.reclaimable);
}
diff --git a/drivers/gpu/drm/panthor/panthor_gem.h b/drivers/gpu/drm/panthor/panthor_gem.h
index ae0491d0b121..56d63137b4eb 100644
--- a/drivers/gpu/drm/panthor/panthor_gem.h
+++ b/drivers/gpu/drm/panthor/panthor_gem.h
@@ -19,12 +19,16 @@ struct panthor_vm;
enum panthor_debugfs_gem_state_flags {
PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT = 0,
PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT = 1,
+ PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT = 2,
/** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED: GEM BO is PRIME imported. */
PANTHOR_DEBUGFS_GEM_STATE_FLAG_IMPORTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_IMPORTED_BIT),
/** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED: GEM BO is PRIME exported. */
PANTHOR_DEBUGFS_GEM_STATE_FLAG_EXPORTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_EXPORTED_BIT),
+
+ /** @PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED: GEM BO is evicted to swap. */
+ PANTHOR_DEBUGFS_GEM_STATE_FLAG_EVICTED = BIT(PANTHOR_DEBUGFS_GEM_STATE_EVICTED_BIT),
};
enum panthor_debugfs_gem_usage_flags {
@@ -172,6 +176,12 @@ struct panthor_gem_object {
/** @reclaim_state: Cached reclaim state */
enum panthor_gem_reclaim_state reclaim_state;
+ /**
+ * @reclaimed_count: How many times object has been evicted to swap.
+ * The count saturates at %INT_MAX and will never wrap around to 0.
+ */
+ atomic_t reclaimed_count;
+
/**
* @exclusive_vm_root_gem: Root GEM of the exclusive VM this GEM object
* is attached to.
--
2.54.0
^ permalink raw reply related
* [PATCH v4 1/3] drm/fdinfo: Add "evicted" memory accounting
From: Nicolas Frattaroli @ 2026-05-20 13:04 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Boris Brezillon, Steven Price, Liviu Dudau,
Jonathan Corbet, Shuah Khan, Tvrtko Ursulin
Cc: dri-devel, linux-kernel, kernel, linux-doc, Nicolas Frattaroli
In-Reply-To: <20260520-panthor-bo-reclaim-observability-v4-0-a47ab61cb80d@collabora.com>
Currently, there's no way to know for certain how much GPU memory was
swapped out. The difference between total and resident memory would
include newly allocated pages, which are not resident, but also aren't
swapped out.
Add a new drm_gem_object_status so drivers can signal when an object has
been evicted to swap, and add a new "evicted" counter to
drm_memory_stats.
Due to how the supported_flags bitmask is determined, the "evicted"
count won't be printed to fdinfo if there's no swapped out pages.
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Documentation/gpu/drm-usage-stats.rst | 6 ++++++
drivers/gpu/drm/drm_file.c | 8 ++++++++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
4 files changed, 18 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
index 70b7cfcc194f..ac1dbf52d96d 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -202,6 +202,12 @@ One practical example of this could be the presence of unsignaled fences in a
GEM buffer reservation object. Therefore, the active category is a subset of the
resident category.
+- drm-evicted-<region>: <uint> [KiB|MiB]
+
+The total size of buffers that have been evicted and are no longer pinned by the
+device. Only present if there are buffers that are currently evicted, and if the
+driver implements reporting of this type of memory.
+
Implementation Details
======================
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ec820686b302..5078172976c0 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -868,6 +868,7 @@ int drm_memory_stats_is_zero(const struct drm_memory_stats *stats)
stats->private == 0 &&
stats->resident == 0 &&
stats->purgeable == 0 &&
+ stats->evicted == 0 &&
stats->active == 0);
}
EXPORT_SYMBOL(drm_memory_stats_is_zero);
@@ -901,6 +902,10 @@ void drm_print_memory_stats(struct drm_printer *p,
if (supported_status & DRM_GEM_OBJECT_PURGEABLE)
drm_fdinfo_print_size(p, prefix, "purgeable", region,
stats->purgeable);
+
+ if (supported_status & DRM_GEM_OBJECT_EVICTED)
+ drm_fdinfo_print_size(p, prefix, "evicted", region,
+ stats->evicted);
}
EXPORT_SYMBOL(drm_print_memory_stats);
@@ -954,6 +959,9 @@ void drm_show_memory_stats(struct drm_printer *p, struct drm_file *file)
if (s & DRM_GEM_OBJECT_PURGEABLE)
status.purgeable += add_size;
+
+ if (s & DRM_GEM_OBJECT_EVICTED)
+ status.evicted += add_size;
}
spin_unlock(&file->table_lock);
diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
index 6ee70ad65e1f..7e4cb45a52c3 100644
--- a/include/drm/drm_file.h
+++ b/include/drm/drm_file.h
@@ -500,6 +500,7 @@ void drm_send_event_timestamp_locked(struct drm_device *dev,
* @resident: Total size of GEM objects backing pages
* @purgeable: Total size of GEM objects that can be purged (resident and not active)
* @active: Total size of GEM objects active on one or more engines
+ * @evicted: Total size of GEM objects that have been evicted
*
* Used by drm_print_memory_stats()
*/
@@ -509,6 +510,7 @@ struct drm_memory_stats {
u64 resident;
u64 purgeable;
u64 active;
+ u64 evicted;
};
enum drm_gem_object_status;
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index 86f5846154f7..799588a2762a 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -53,6 +53,7 @@ struct drm_gem_object;
* @DRM_GEM_OBJECT_RESIDENT: object is resident in memory (ie. not unpinned)
* @DRM_GEM_OBJECT_PURGEABLE: object marked as purgeable by userspace
* @DRM_GEM_OBJECT_ACTIVE: object is currently used by an active submission
+ * @DRM_GEM_OBJECT_EVICTED: object is evicted and no longer pinned by driver
*
* Bitmask of status used for fdinfo memory stats, see &drm_gem_object_funcs.status
* and drm_show_fdinfo(). Note that an object can report DRM_GEM_OBJECT_PURGEABLE
@@ -67,6 +68,7 @@ enum drm_gem_object_status {
DRM_GEM_OBJECT_RESIDENT = BIT(0),
DRM_GEM_OBJECT_PURGEABLE = BIT(1),
DRM_GEM_OBJECT_ACTIVE = BIT(2),
+ DRM_GEM_OBJECT_EVICTED = BIT(3),
};
/**
--
2.54.0
^ permalink raw reply related
* [PATCH v4 0/3] Let userspace know about swapped out panthor GEM objects
From: Nicolas Frattaroli @ 2026-05-20 13:04 UTC (permalink / raw)
To: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Boris Brezillon, Steven Price, Liviu Dudau,
Jonathan Corbet, Shuah Khan, Tvrtko Ursulin
Cc: dri-devel, linux-kernel, kernel, linux-doc, Nicolas Frattaroli
Panthor has recently gained a GEM shrinker. It allows evicting memory
that backs unused GEM objects to swap.
In this series, both fdinfo and Panthor's gems debugfs are extended so
that information on evicted pages can be gathered by users through these
two methods.
---
Changes in v4:
- Change "evicted" memory type documentation to no longer explicitly
mention swap
- Link to v3: https://patch.msgid.link/20260423-panthor-bo-reclaim-observability-v3-0-60af32164a4f@collabora.com
Changes in v3:
- Add documentation for new "evicted" memory type in fdinfo
- Link to v2: https://patch.msgid.link/20260421-panthor-bo-reclaim-observability-v2-0-c9135eedfb6f@collabora.com
Changes in v2:
- Change reclaimed_count to saturate at INT_MAX
- Add "evictions" column to panthor gems debugfs which prints
reclaimed_count
- Add a patch to reduce the padding of one panthor gems debugfs column a
bit
- Link to v1: https://patch.msgid.link/20260420-panthor-bo-reclaim-observability-v1-0-a4d1a36ee84f@collabora.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: Boris Brezillon <boris.brezillon@collabora.com>
To: Steven Price <steven.price@arm.com>
To: Liviu Dudau <liviu.dudau@arm.com>
To: Jonathan Corbet <corbet@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
To: Tvrtko Ursulin <tursulin@ursulin.net>
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: kernel@collabora.com
Cc: linux-doc@vger.kernel.org
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Nicolas Frattaroli (3):
drm/fdinfo: Add "evicted" memory accounting
drm/panthor: Implement evicted status for GEM objects
drm/panthor: Reduce padding in gems debugfs for refcount
Documentation/gpu/drm-usage-stats.rst | 6 ++++++
drivers/gpu/drm/drm_file.c | 8 ++++++++
drivers/gpu/drm/panthor/panthor_gem.c | 18 ++++++++++++++----
drivers/gpu/drm/panthor/panthor_gem.h | 10 ++++++++++
include/drm/drm_file.h | 2 ++
include/drm/drm_gem.h | 2 ++
6 files changed, 42 insertions(+), 4 deletions(-)
---
base-commit: 69c95e4c529297c25503e60acba757fba24fdc95
change-id: 20260420-panthor-bo-reclaim-observability-970679c9533c
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
^ permalink raw reply
* Re: [PATCH v2 1/2] tools/mm: add a standalone GUP microbenchmark
From: Mike Rapoport @ 2026-05-20 12:58 UTC (permalink / raw)
To: Mark Brown
Cc: Sarthak Sharma, Andrew Morton, David Hildenbrand, Jonathan Corbet,
Jason Gunthorpe, John Hubbard, Peter Xu, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Shuah Khan, linux-mm, linux-kselftest, linux-kernel,
linux-doc
In-Reply-To: <67e9ecff-e532-4659-b4de-7019474af608@sirena.org.uk>
On Wed, May 20, 2026 at 12:58:32PM +0100, Mark Brown wrote:
> On Wed, May 20, 2026 at 03:45:53PM +0530, Sarthak Sharma wrote:
> > On 5/20/26 2:25 PM, Mike Rapoport wrote:
>
> > > It seems that we need to better share the common code in
> > > tools/testing/selftest.
>
> > > And adding another copy of the hugetlb detection and setup code does not
> > > seem like a great idea.
>
> > Agreed, but that was the least disruptive approach I could think of.
>
> > I am thinking of doing this now: should I move the
> > hugepage_settings.[ch] to tools/lib/ and move the read_num(),
> > write_num(), read_file() and write_file() helpers to a separate file in
these might need some adjustments because they use ksft_(), but in general
it makes sense to me.
> > tools/lib/ itself without any ksft dependency? Then both
> > tools/testing/selftests/* and tools/mm/ could share the same code.
>
> Using tools/lib sounds sensible to me - as well as the sharing it makes
> it clear that it's a library used by multiple things so avoids the
> issues we sometimes have with selftest directories referencing each
> other.
I'd make it tools/lib/mm as most of the files tools/lib/*.c are stubs for
the kernel functions.
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Xaver Hugl @ 2026-05-20 12:33 UTC (permalink / raw)
To: Christian König
Cc: Julian Orth, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Sumit Semwal, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, dri-devel,
linux-kernel, linux-media, linaro-mm-sig, linux-doc,
wayland-devel, Michel Dänzer
In-Reply-To: <53edf0b5-e733-4b96-87d7-3307275500c0@amd.com>
Am Mi., 20. Mai 2026 um 10:08 Uhr schrieb Christian König
<christian.koenig@amd.com>:
> Well I would say the other way around is a pretty common use case.
>
> In other words the compositors uses the internal GPU for composing and displaying the picture. And the client uses the external GPU for fast rendering.
Sure, but that's not what I'm talking about.
> > - the buffers from the client stay valid
>
> Buffers from the hot plugged GPU don't stay valid. Accessing CPU mappings either result in a SIGBUS or are redirected to a dummy page.
Again, not what I wrote about. The buffers are on the integrated GPU.
> > - the syncobj stays valid on the client side
> > - the syncobj becomes invalid on the compositor side
>
> Nope that's not correct. The syncobj itself stays valid even if you completely hot plug the device.
>
> It can just be that the fences inside the syncobj are terminated with an error.
What about eventfd created for a point on the syncobj?
Another (future) problem with hotplugs will be if the sync file hasn't
materialized for the timeline point when the device is hotunplugged,
since there can't be an error on the fence if there isn't one. Or
could userspace somehow set an 'artificial' fence with an error in
that case?
> > "invalid" there means either
> > - the acquire point of the client is marked as signaled, before
> > rendering on the client side is completed
> > - the acquire point of the client is never signaled. Since the
> > compositor waits for the acquire point, the Wayland surface is stuck
> > forever
>
> Both of those would be a *massive* violation of documented kernel rules for hot-plugging which could lead to random data corruption and/or deadlocks.
>
> If you see any HW driver showing behavior like that please open up a bug report and ping the relevant maintainers immediately.
If there are no error codes with syncobj yet, then to userspace, the
latter behavior is exactly what we get, isn't it?
> When a hotplug happens all operations of the device should return an -ENODEV error, even when exposed to other devices/application through syncobj or syncfile.
Okay, that at least gives us a way to fail imports somewhat
gracefully. Normally, failing to import a syncobj is a fatal error in
the Wayland protocol.
> One problem is that only syncfile allows for querying such error codes at the moment, we have patches pending to add that to syncobj as well but we lack a compositor with support for that as userspace client.
As long as the error case can be detected with an eventfd,
implementing that in KWin shouldn't be a challenge.
> Well the question here is if the device the compositor is using or the client is using is gone?
>
> If the client device is hot removed the compositor should be perfectly capable to import the syncobj.
>
> If the compositor device is gone then you don't have a device to display anything any more, so generating the next frame doesn't seem to make sense either.
>
> What could be is that you want the compositor to be kept alive even when the display device is gone to switch over to vkms or whatever so that a VNC session or other remote desktop still works.
There are two GPUs in the example I gave. The compositor can use both
for rendering (in cosmic-comp's case) or switch between them (what I'm
trying to do with KWin), or use one device for rendering, and another
for importing the syncobj.
> >>>>> 3. It removes the need to translate between syncobjs fds and handles.
> >>>>
> >>>> That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional.
> >>> Could you expand on why it's needed? For compositors, the handle is
> >>> just an intermediary thing when translating between file descriptors.
> >>
> >> Well what we could do is to add an IOCTL to directly attach an syncobj file descriptor to an eventfd.
> > That would be nice.
>
> Take a look at drm_syncobj_file_fops and how drm_syncobj_add_eventfd() is used. Adding that functionality shouldn't be more than a typing exercise.
Yeah, this patchset already adds that functionality (on the new device).
> Do I see it right that this would already solve most problems in the compositor side?
Skipping the syncobj handle step would only reduce the amounts of
ioctls the compositor does, but afaict it wouldn't solve any
compositor problems. At least not as long as it's still tied to a drm
device.
For device hotplugs, the only new thing we need for correctly handling
syncobj is a way to receive errors on the eventfd.
A device-independent way to create and use syncobj would still be
useful to us though, both to simplify the compositor and to improve
the software rendering use cases.
- Xaver
^ permalink raw reply
* Re: [PATCH net-next v2 2/2] net: ti: icssg: Add HSR and LRE PA statistics
From: Felix Maurer @ 2026-05-20 12:31 UTC (permalink / raw)
To: Luka Gejak
Cc: Jakub Kicinski, MD Danish Anwar, David S. Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan,
Roger Quadros, Andrew Lunn, Meghana Malladi, Jacob Keller,
David Carlier, Vadim Fedorenko, Kevin Hao, netdev, linux-doc,
linux-kernel, linux-arm-kernel, Vladimir Oltean
In-Reply-To: <E30AAC96-01D2-4A23-B562-126087DEB7FA@linux.dev>
Hi everyone,
On Tue, May 19, 2026 at 07:55:55AM +0200, Luka Gejak wrote:
> On May 19, 2026 3:45:06 AM GMT+02:00, Jakub Kicinski <kuba@kernel.org> wrote:
> >On Thu, 14 May 2026 13:26:05 +0530 MD Danish Anwar wrote:
> >> Add new firmware PA statistics counters for HSR and LRE to the ethtool
> >> statistics exposed by the ICSSG driver.
> >>
> >> New statistics added:
> >> - FW_HSR_FWD_CHECK_FAIL_DROP: Packets dropped on the HSR forwarding path
> >> - FW_HSR_HE_CHECK_FAIL_DROP: Packets dropped on the HSR host egress path
> >> - FW_HSR_SKIP_HOST_DUP_DISCARD_FRAMES: Frames with duplicate discard
> >> skipped
> >> - FW_LRE_CNT_UNIQUE/DUPLICATE/MULTIPLE_RX: LRE duplicate detection
> >> counters
> >> - FW_LRE_CNT_RX/TX: LRE per-port frame counters
> >> - FW_LRE_CNT_OWN_RX: Own HSR tagged frames received
> >> - FW_LRE_CNT_ERRWRONGLAN: Frames with wrong LAN identifier (PRP)
> >>
> >> Document the new HSR/LRE statistics in icssg_prueth.rst.
> >
> >To an untrained eye these stats look like stuff that could
> >be standardized across drivers.
> >
> >Luka, Felix, others on CC, do you think we should expose these
> >from HSR over netlink as "standard" offload stats different drivers
> >can plug into or not worth it?
>
> Hi Jakub,
> I think there is a case for standardizing part of this, but I would
> not standardize the whole set as-is.
>
> The LRE counters look generic enough to me, especially:
> - unique rx
> - duplicate rx
> - multiple rx
> - rx / tx
> - own rx
> - wrong LAN, PRP only
I'm very much in favor of having standardized stats for hsr hardware
offloads that the drivers can supply. The list above looks about right,
I'd add "frames with errors" and "(proxy) node table entry count" as
well and that "own rx" is HSR only.
In general, I don't think we need to standardize this ourselves but can
adapt to the counters that the SNMP MIB for IEC 62439-3 [1] already has.
It's part of the standard and IMHO we should gather these counters from
offloads (and later supply the same set from our sw implementation, but
the current netlink interface for hsr is quite messy). For reference,
the list in the MIB is (no need to fully adopt this naming):
- lreCntTx{A,B,C}: Sent frames per-port (for A,B only tagged frames)
- lreCntRx{A,B,C}: Received frames per-port (for A,B only tagged frames)
- lreCntErrWrongLan{A,B}: Received frames per-port with wrong LAN ID
(only for PRP)
- lreCntErrWrongLanC: Received frames on interlink port of HSR-PRP
RedBox with wrong LAN ID
- lreCntErrors{A,B,C}: Received frames with errors per-port
- lreCnt{,Proxy}Nodes: Nodes in the (proxy) node table
- lreCntUnique{A,B,C}: Frames only received once, per-port
- lreCntDuplicate{A,B,C}: Frames received with exactly one duplicate,
per-port
- lreCntMulti{A,B,C}: Frames received with more than one duplicate,
per-port
- lreCntOwnRx{A,B}: Frames received per-port (A,B) that originated from
this node, only for HSR rings
Note that we can not currently completely distinguish
Unique/Duplicate/Multi in the kernel implementation and their meaning is
not entirely clear to me from the MIB.
The explanations in the MIB in [1] are otherwise quite explicit for each
of the counters but we may want to adapt the meaning of "port C" to the
counters. For example, there is lreCntRx{A,B,C} for received HSR/PRP
tagged frames (by the LRE). Port A and B are clear, but for port C the
meaning is "number of frames received from the application interface of
a DANP or DANH or the number of number of frames received on the
interlink of a RedBox". IMHO, we should consider separating "application
interface" (what the kernel calls master) and the interlink port because
these two are not mutually exclusive in the kernel (nor in the NICs that
support hardware offload).
Thanks,
Felix
[1]: you can find it for example here: https://mibbrowser.online/mibdb_search.php?mib=IEC-62439-3-MIB
^ permalink raw reply
* Re: [PATCH v6 05/43] KVM: guest_memfd: Wire up kvm_get_memory_attributes() to per-gmem attributes
From: Fuad Tabba @ 2026-05-20 12:08 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, 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, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-5-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Sean Christopherson <seanjc@google.com>
>
> Implement kvm_gmem_get_memory_attributes() for guest_memfd to allow the KVM
> core and architecture code to query per-GFN memory attributes.
>
> kvm_gmem_get_memory_attributes() finds the memory slot for a given GFN and
> queries the guest_memfd file's to determine if the page is marked as
> private.
>
> If vm_memory_attributes is not enabled, there is no shared/private tracking
> at the VM level. Install the guest_memfd implementation as long as
> guest_memfd is enabled to give guest_memfd a chance to respond on
> attributes.
>
> guest_memfd should look up attributes regardless of whether this memslot is
> gmem-only since attributes are now tracked by gmem regardless of whether
> mmap() is enabled.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> Co-developed-by: Ackerley Tng <ackerleytng@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
> ---
> include/linux/kvm_host.h | 2 ++
> virt/kvm/guest_memfd.c | 31 +++++++++++++++++++++++++++++++
> virt/kvm/kvm_main.c | 3 +++
> 3 files changed, 36 insertions(+)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index c5ba2cb34e45c..28a54298d27db 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -2557,6 +2557,8 @@ bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
> struct kvm_gfn_range *range);
> #endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>
> +unsigned long kvm_gmem_get_memory_attributes(struct kvm *kvm, gfn_t gfn);
> +
> #ifdef CONFIG_KVM_GUEST_MEMFD
> int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> gfn_t gfn, kvm_pfn_t *pfn, struct page **page,
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 5011d38820d0d..f055e058a3f28 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -509,6 +509,37 @@ static int kvm_gmem_mmap(struct file *file, struct vm_area_struct *vma)
> return 0;
> }
>
> +unsigned long kvm_gmem_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
> +{
> + struct kvm_memory_slot *slot = gfn_to_memslot(kvm, gfn);
> + struct inode *inode;
> +
> + /*
> + * If this gfn has no associated memslot, there's no chance of the gfn
> + * being backed by private memory, since guest_memfd must be used for
> + * private memory, and guest_memfd must be associated with some memslot.
> + */
> + if (!slot)
> + return 0;
> +
> + CLASS(gmem_get_file, file)(slot);
> + if (!file)
> + return 0;
> +
> + inode = file_inode(file);
> +
> + /*
> + * Rely on the maple tree's internal RCU lock to ensure a
> + * stable result. This result can become stale as soon as the
> + * lock is dropped, so the caller _must_ still protect
> + * consumption of private vs. shared by checking
> + * mmu_invalidate_retry_gfn() under mmu_lock to serialize
> + * against ongoing attribute updates.
> + */
> + return kvm_gmem_get_attributes(inode, kvm_gmem_get_index(slot, gfn));
> +}
Doesn't this imply that all consumers of kvm_mem_is_private() should
validate the result using mmu_lock and the invalidation sequence?
sev_handle_rmp_fault() calls kvm_mem_is_private() without holding
mmu_lock and without any retry mechanism. Is that a problem?
Cheers,
/fuad
> +EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_gmem_get_memory_attributes);
> +
> static struct file_operations kvm_gmem_fops = {
> .mmap = kvm_gmem_mmap,
> .open = generic_file_open,
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index ee26f1d9b5fda..4139e903f756a 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2653,6 +2653,9 @@ static void kvm_init_memory_attributes(void)
> if (vm_memory_attributes)
> static_call_update(__kvm_get_memory_attributes,
> kvm_get_vm_memory_attributes);
> + else if (IS_ENABLED(CONFIG_KVM_GUEST_MEMFD))
> + static_call_update(__kvm_get_memory_attributes,
> + kvm_gmem_get_memory_attributes);
> else
> static_call_update(__kvm_get_memory_attributes,
> (void *)__static_call_return0);
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH v6 04/43] KVM: Stub in ability to disable per-VM memory attribute tracking
From: Fuad Tabba @ 2026-05-20 12:08 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, 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, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-4-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Sean Christopherson <seanjc@google.com>
>
> Introduce the basic infrastructure to allow per-VM memory attribute
> tracking to be disabled. This will be built-upon in a later patch, where a
> module param can disable per-VM memory attribute tracking.
>
> Split the Kconfig option into a base KVM_MEMORY_ATTRIBUTES and the
> existing KVM_VM_MEMORY_ATTRIBUTES. The base option provides the core
> plumbing, while the latter enables the full per-VM tracking via an xarray
> and the associated ioctls.
>
> kvm_get_memory_attributes() now performs a static call that either looks up
> kvm->mem_attr_array with CONFIG_KVM_VM_MEMORY_ATTRIBUTES is enabled, or
> just returns 0 otherwise. The static call can be patched depending on
> whether per-VM tracking is enabled by the CONFIG.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> arch/x86/include/asm/kvm_host.h | 2 +-
> include/linux/kvm_host.h | 23 ++++++++++++---------
> virt/kvm/Kconfig | 4 ++++
> virt/kvm/kvm_main.c | 44 ++++++++++++++++++++++++++++++++++++++++-
> 4 files changed, 62 insertions(+), 11 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 60b997764beef..c9aa50bcdac2d 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -2369,7 +2369,7 @@ void kvm_configure_mmu(bool enable_tdp, int tdp_forced_root_level,
> int tdp_max_root_level, int tdp_huge_page_level);
>
>
> -#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_MEMORY_ATTRIBUTES
> #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.has_private_mem)
> #endif
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 7d079f9701346..c5ba2cb34e45c 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -2528,19 +2528,15 @@ static inline bool kvm_memslot_is_gmem_only(const struct kvm_memory_slot *slot)
> return slot->flags & KVM_MEMSLOT_GMEM_ONLY;
> }
>
> -#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_MEMORY_ATTRIBUTES
> +typedef unsigned long (kvm_get_memory_attributes_t)(struct kvm *kvm, gfn_t gfn);
> +DECLARE_STATIC_CALL(__kvm_get_memory_attributes, kvm_get_memory_attributes_t);
> +
> static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
> {
> - return xa_to_value(xa_load(&kvm->mem_attr_array, gfn));
> + return static_call(__kvm_get_memory_attributes)(kvm, gfn);
> }
>
> -bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
> - unsigned long mask, unsigned long attrs);
> -bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
> - struct kvm_gfn_range *range);
> -bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
> - struct kvm_gfn_range *range);
> -
> static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> {
> return kvm_get_memory_attributes(kvm, gfn) & KVM_MEMORY_ATTRIBUTE_PRIVATE;
> @@ -2550,6 +2546,15 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> {
> return false;
> }
> +#endif
> +
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> +bool kvm_range_has_memory_attributes(struct kvm *kvm, gfn_t start, gfn_t end,
> + unsigned long mask, unsigned long attrs);
> +bool kvm_arch_pre_set_memory_attributes(struct kvm *kvm,
> + struct kvm_gfn_range *range);
> +bool kvm_arch_post_set_memory_attributes(struct kvm *kvm,
> + struct kvm_gfn_range *range);
> #endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>
> #ifdef CONFIG_KVM_GUEST_MEMFD
> diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
> index 5119cb37145fc..3fea89c45cfb4 100644
> --- a/virt/kvm/Kconfig
> +++ b/virt/kvm/Kconfig
> @@ -100,7 +100,11 @@ config KVM_ELIDE_TLB_FLUSH_IF_YOUNG
> config KVM_MMU_LOCKLESS_AGING
> bool
>
> +config KVM_MEMORY_ATTRIBUTES
> + bool
> +
> config KVM_VM_MEMORY_ATTRIBUTES
> + select KVM_MEMORY_ATTRIBUTES
> bool
>
> config KVM_GUEST_MEMFD
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index abb9cfa3eb04d..ee26f1d9b5fda 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -101,6 +101,17 @@ EXPORT_SYMBOL_FOR_KVM_INTERNAL(halt_poll_ns_shrink);
> static bool __ro_after_init allow_unsafe_mappings;
> module_param(allow_unsafe_mappings, bool, 0444);
>
> +#ifdef CONFIG_KVM_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> +static bool vm_memory_attributes = true;
> +#else
> +#define vm_memory_attributes false
> +#endif
> +DEFINE_STATIC_CALL_RET0(__kvm_get_memory_attributes, kvm_get_memory_attributes_t);
> +EXPORT_SYMBOL_FOR_KVM_INTERNAL(STATIC_CALL_KEY(__kvm_get_memory_attributes));
> +EXPORT_SYMBOL_FOR_KVM_INTERNAL(STATIC_CALL_TRAMP(__kvm_get_memory_attributes));
> +#endif
> +
> /*
> * Ordering of locks:
> *
> @@ -2418,7 +2429,7 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm,
> }
> #endif /* CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */
>
> -#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_MEMORY_ATTRIBUTES
> static u64 kvm_supported_mem_attributes(struct kvm *kvm)
> {
> #ifdef kvm_arch_has_private_mem
> @@ -2429,6 +2440,12 @@ static u64 kvm_supported_mem_attributes(struct kvm *kvm)
> return 0;
> }
>
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> +static unsigned long kvm_get_vm_memory_attributes(struct kvm *kvm, gfn_t gfn)
> +{
> + return xa_to_value(xa_load(&kvm->mem_attr_array, gfn));
> +}
> +
> /*
> * Returns true if _all_ gfns in the range [@start, @end) have attributes
> * such that the bits in @mask match @attrs.
> @@ -2625,7 +2642,24 @@ static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
>
> return kvm_vm_set_mem_attributes(kvm, start, end, attrs->attributes);
> }
> +#else /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
> +static unsigned long kvm_get_vm_memory_attributes(struct kvm *kvm, gfn_t gfn)
> +{
> + BUILD_BUG_ON(1);
> +}
> #endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
> +static void kvm_init_memory_attributes(void)
> +{
> + if (vm_memory_attributes)
> + static_call_update(__kvm_get_memory_attributes,
> + kvm_get_vm_memory_attributes);
> + else
> + static_call_update(__kvm_get_memory_attributes,
> + (void *)__static_call_return0);
> +}
> +#else /* CONFIG_KVM_MEMORY_ATTRIBUTES */
> +static void kvm_init_memory_attributes(void) { }
> +#endif /* CONFIG_KVM_MEMORY_ATTRIBUTES */
>
> struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn)
> {
> @@ -4925,6 +4959,9 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> return 1;
> #ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> case KVM_CAP_MEMORY_ATTRIBUTES:
> + if (!vm_memory_attributes)
> + return 0;
> +
> return kvm_supported_mem_attributes(kvm);
> #endif
> #ifdef CONFIG_KVM_GUEST_MEMFD
> @@ -5331,6 +5368,10 @@ static long kvm_vm_ioctl(struct file *filp,
> case KVM_SET_MEMORY_ATTRIBUTES: {
> struct kvm_memory_attributes attrs;
>
> + r = -ENOTTY;
> + if (!vm_memory_attributes)
> + goto out;
> +
> r = -EFAULT;
> if (copy_from_user(&attrs, argp, sizeof(attrs)))
> goto out;
> @@ -6527,6 +6568,7 @@ int kvm_init(unsigned vcpu_size, unsigned vcpu_align, struct module *module)
> kvm_preempt_ops.sched_in = kvm_sched_in;
> kvm_preempt_ops.sched_out = kvm_sched_out;
>
> + kvm_init_memory_attributes();
> kvm_init_debug();
>
> r = kvm_vfio_ops_init();
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH v6 03/43] KVM: Enumerate support for PRIVATE memory iff kvm_arch_has_private_mem is defined
From: Fuad Tabba @ 2026-05-20 12:08 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, 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, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-3-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Sean Christopherson <seanjc@google.com>
>
> Explicitly guard reporting support for KVM_MEMORY_ATTRIBUTE_PRIVATE based
> on kvm_arch_has_private_mem being #defined in anticipation of decoupling
> kvm_supported_mem_attributes() from CONFIG_KVM_VM_MEMORY_ATTRIBUTES.
> guest_memfd support for memory attributes will be unconditional to avoid
> yet more macros (all architectures that support guest_memfd are expected to
> use per-gmem attributes at some point), at which point enumerating support
> KVM_MEMORY_ATTRIBUTE_PRIVATE based solely on memory attributes being
> supported _somewhere_ would result in KVM over-reporting support on arm64.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> include/linux/kvm_host.h | 2 +-
> virt/kvm/kvm_main.c | 2 ++
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 7b9faa3545300..7d079f9701346 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -722,7 +722,7 @@ static inline int kvm_arch_vcpu_memslots_id(struct kvm_vcpu *vcpu)
> }
> #endif
>
> -#ifndef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> +#ifndef kvm_arch_has_private_mem
> static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
> {
> return false;
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 306153abbafa5..abb9cfa3eb04d 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -2421,8 +2421,10 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm,
> #ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static u64 kvm_supported_mem_attributes(struct kvm *kvm)
> {
> +#ifdef kvm_arch_has_private_mem
> if (!kvm || kvm_arch_has_private_mem(kvm))
> return KVM_MEMORY_ATTRIBUTE_PRIVATE;
> +#endif
>
> return 0;
> }
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH v6 02/43] KVM: Rename KVM_GENERIC_MEMORY_ATTRIBUTES to KVM_VM_MEMORY_ATTRIBUTES
From: Fuad Tabba @ 2026-05-20 12:08 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
ira.weiny, jmattson, jthoughton, michael.roth, oupton,
pankaj.gupta, qperret, rick.p.edgecombe, rientjes, shivankg,
steven.price, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, liam, Paolo Bonzini,
Sean Christopherson, 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, Baoquan He, Barry Song,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng,
Shakeel Butt, Kiryl Shutsemau, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260507-gmem-inplace-conversion-v6-2-91ab5a8b19a4@google.com>
On Thu, 7 May 2026 at 21:22, Ackerley Tng via B4 Relay
<devnull+ackerleytng.google.com@kernel.org> wrote:
>
> From: Sean Christopherson <seanjc@google.com>
>
> Rename the per-VM memory attributes Kconfig to make it explicitly about
> per-VM attributes in anticipation of adding memory attributes support to
> guest_memfd, at which point it will be possible (and desirable) to have
> memory attributes without the per-VM support, even in x86.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Cheers,
/fuad
> ---
> arch/x86/include/asm/kvm_host.h | 2 +-
> arch/x86/kvm/Kconfig | 6 +++---
> arch/x86/kvm/mmu/mmu.c | 2 +-
> arch/x86/kvm/x86.c | 2 +-
> include/linux/kvm_host.h | 8 ++++----
> include/trace/events/kvm.h | 4 ++--
> virt/kvm/Kconfig | 2 +-
> virt/kvm/kvm_main.c | 14 +++++++-------
> 8 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index c470e40a00aa4..60b997764beef 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -2369,7 +2369,7 @@ void kvm_configure_mmu(bool enable_tdp, int tdp_forced_root_level,
> int tdp_max_root_level, int tdp_huge_page_level);
>
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> #define kvm_arch_has_private_mem(kvm) ((kvm)->arch.has_private_mem)
> #endif
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index 801bf9e520db3..26f6afd51bbdc 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -84,7 +84,7 @@ config KVM_SW_PROTECTED_VM
> bool "Enable support for KVM software-protected VMs"
> depends on EXPERT
> depends on KVM_X86 && X86_64
> - select KVM_GENERIC_MEMORY_ATTRIBUTES
> + select KVM_VM_MEMORY_ATTRIBUTES
> help
> Enable support for KVM software-protected VMs. Currently, software-
> protected VMs are purely a development and testing vehicle for
> @@ -135,7 +135,7 @@ config KVM_INTEL_TDX
> bool "Intel Trust Domain Extensions (TDX) support"
> default y
> depends on INTEL_TDX_HOST
> - select KVM_GENERIC_MEMORY_ATTRIBUTES
> + select KVM_VM_MEMORY_ATTRIBUTES
> select HAVE_KVM_ARCH_GMEM_POPULATE
> help
> Provides support for launching Intel Trust Domain Extensions (TDX)
> @@ -159,7 +159,7 @@ config KVM_AMD_SEV
> depends on KVM_AMD && X86_64
> depends on CRYPTO_DEV_SP_PSP && !(KVM_AMD=y && CRYPTO_DEV_CCP_DD=m)
> select ARCH_HAS_CC_PLATFORM
> - select KVM_GENERIC_MEMORY_ATTRIBUTES
> + select KVM_VM_MEMORY_ATTRIBUTES
> select HAVE_KVM_ARCH_GMEM_PREPARE
> select HAVE_KVM_ARCH_GMEM_INVALIDATE
> select HAVE_KVM_ARCH_GMEM_POPULATE
> diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
> index 892246204435c..a80a876ab4ad6 100644
> --- a/arch/x86/kvm/mmu/mmu.c
> +++ b/arch/x86/kvm/mmu/mmu.c
> @@ -7899,7 +7899,7 @@ void kvm_mmu_pre_destroy_vm(struct kvm *kvm)
> vhost_task_stop(kvm->arch.nx_huge_page_recovery_thread);
> }
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static bool hugepage_test_mixed(struct kvm_memory_slot *slot, gfn_t gfn,
> int level)
> {
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 0a1b63c63d1a9..1560de1e95be0 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -13625,7 +13625,7 @@ static int kvm_alloc_memslot_metadata(struct kvm *kvm,
> }
> }
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> kvm_mmu_init_memslot_memory_attributes(kvm, slot);
> #endif
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 4c14aee1fb063..7b9faa3545300 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -722,7 +722,7 @@ static inline int kvm_arch_vcpu_memslots_id(struct kvm_vcpu *vcpu)
> }
> #endif
>
> -#ifndef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifndef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static inline bool kvm_arch_has_private_mem(struct kvm *kvm)
> {
> return false;
> @@ -871,7 +871,7 @@ struct kvm {
> #ifdef CONFIG_HAVE_KVM_PM_NOTIFIER
> struct notifier_block pm_notifier;
> #endif
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> /* Protected by slots_lock (for writes) and RCU (for reads) */
> struct xarray mem_attr_array;
> #endif
> @@ -2528,7 +2528,7 @@ static inline bool kvm_memslot_is_gmem_only(const struct kvm_memory_slot *slot)
> return slot->flags & KVM_MEMSLOT_GMEM_ONLY;
> }
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static inline unsigned long kvm_get_memory_attributes(struct kvm *kvm, gfn_t gfn)
> {
> return xa_to_value(xa_load(&kvm->mem_attr_array, gfn));
> @@ -2550,7 +2550,7 @@ static inline bool kvm_mem_is_private(struct kvm *kvm, gfn_t gfn)
> {
> return false;
> }
> -#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>
> #ifdef CONFIG_KVM_GUEST_MEMFD
> int kvm_gmem_get_pfn(struct kvm *kvm, struct kvm_memory_slot *slot,
> diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
> index b282e3a867696..1ba72bd73ea2f 100644
> --- a/include/trace/events/kvm.h
> +++ b/include/trace/events/kvm.h
> @@ -358,7 +358,7 @@ TRACE_EVENT(kvm_dirty_ring_exit,
> TP_printk("vcpu %d", __entry->vcpu_id)
> );
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> /*
> * @start: Starting address of guest memory range
> * @end: End address of guest memory range
> @@ -383,7 +383,7 @@ TRACE_EVENT(kvm_vm_set_mem_attributes,
> TP_printk("%#016llx -- %#016llx [0x%lx]",
> __entry->start, __entry->end, __entry->attr)
> );
> -#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>
> TRACE_EVENT(kvm_unmap_hva_range,
> TP_PROTO(unsigned long start, unsigned long end),
> diff --git a/virt/kvm/Kconfig b/virt/kvm/Kconfig
> index 794976b88c6f9..5119cb37145fc 100644
> --- a/virt/kvm/Kconfig
> +++ b/virt/kvm/Kconfig
> @@ -100,7 +100,7 @@ config KVM_ELIDE_TLB_FLUSH_IF_YOUNG
> config KVM_MMU_LOCKLESS_AGING
> bool
>
> -config KVM_GENERIC_MEMORY_ATTRIBUTES
> +config KVM_VM_MEMORY_ATTRIBUTES
> bool
>
> config KVM_GUEST_MEMFD
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index 89489996fbc1e..306153abbafa5 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -1115,7 +1115,7 @@ static struct kvm *kvm_create_vm(unsigned long type, const char *fdname)
> spin_lock_init(&kvm->mn_invalidate_lock);
> rcuwait_init(&kvm->mn_memslots_update_rcuwait);
> xa_init(&kvm->vcpu_array);
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> xa_init(&kvm->mem_attr_array);
> #endif
>
> @@ -1300,7 +1300,7 @@ static void kvm_destroy_vm(struct kvm *kvm)
> cleanup_srcu_struct(&kvm->irq_srcu);
> srcu_barrier(&kvm->srcu);
> cleanup_srcu_struct(&kvm->srcu);
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> xa_destroy(&kvm->mem_attr_array);
> #endif
> kvm_arch_free_vm(kvm);
> @@ -2418,7 +2418,7 @@ static int kvm_vm_ioctl_clear_dirty_log(struct kvm *kvm,
> }
> #endif /* CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT */
>
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> static u64 kvm_supported_mem_attributes(struct kvm *kvm)
> {
> if (!kvm || kvm_arch_has_private_mem(kvm))
> @@ -2623,7 +2623,7 @@ static int kvm_vm_ioctl_set_mem_attributes(struct kvm *kvm,
>
> return kvm_vm_set_mem_attributes(kvm, start, end, attrs->attributes);
> }
> -#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
>
> struct kvm_memory_slot *gfn_to_memslot(struct kvm *kvm, gfn_t gfn)
> {
> @@ -4921,7 +4921,7 @@ static int kvm_vm_ioctl_check_extension_generic(struct kvm *kvm, long arg)
> case KVM_CAP_SYSTEM_EVENT_DATA:
> case KVM_CAP_DEVICE_CTRL:
> return 1;
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> case KVM_CAP_MEMORY_ATTRIBUTES:
> return kvm_supported_mem_attributes(kvm);
> #endif
> @@ -5325,7 +5325,7 @@ static long kvm_vm_ioctl(struct file *filp,
> break;
> }
> #endif /* CONFIG_HAVE_KVM_IRQ_ROUTING */
> -#ifdef CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> case KVM_SET_MEMORY_ATTRIBUTES: {
> struct kvm_memory_attributes attrs;
>
> @@ -5336,7 +5336,7 @@ static long kvm_vm_ioctl(struct file *filp,
> r = kvm_vm_ioctl_set_mem_attributes(kvm, &attrs);
> break;
> }
> -#endif /* CONFIG_KVM_GENERIC_MEMORY_ATTRIBUTES */
> +#endif /* CONFIG_KVM_VM_MEMORY_ATTRIBUTES */
> case KVM_CREATE_DEVICE: {
> struct kvm_create_device cd;
>
>
> --
> 2.54.0.563.g4f69b47b94-goog
>
>
^ permalink raw reply
* Re: [PATCH mm-unstable v17 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-05-20 12:05 UTC (permalink / raw)
To: Wei Yang
Cc: linux-doc, linux-kernel, linux-mm, linux-trace-kernel, aarcange,
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, ljs, mathieu.desnoyers, matthew.brost, mhiramat,
mhocko, peterx, pfalcato, rakie.kim, raquini, rdunlap, 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: <20260512154431.jxcs632mqqatqtsw@master>
On Tue, May 12, 2026 at 9:44 AM Wei Yang <richard.weiyang@gmail.com> wrote:
>
> On Mon, May 11, 2026 at 12:58:11PM -0600, Nico Pache wrote:
> >Enable khugepaged to collapse to mTHP orders. This patch implements the
> >main scanning logic using a bitmap to track occupied pages and a stack
> >structure that allows us to find optimal collapse sizes.
> >
> >Previous to this patch, PMD collapse had 3 main phases, a light weight
> >scanning phase (mmap_read_lock) that determines a potential PMD
> >collapse, an alloc phase (mmap unlocked), then finally heavier collapse
> >phase (mmap_write_lock).
> >
> >To enabled mTHP collapse we make the following changes:
> >
> >During PMD scan phase, track occupied pages in a bitmap. When mTHP
> >orders are enabled, we remove the restriction of max_ptes_none during the
> >scan phase to avoid missing potential mTHP collapse candidates. Once we
> >have scanned the full PMD range and updated the bitmap to track occupied
> >pages, we use the bitmap to find the optimal mTHP size.
> >
> >Implement collapse_scan_bitmap() to perform binary recursion on the bitmap
> >and determine the best eligible order for the collapse. A stack structure
> >is used instead of traditional recursion to manage the search. This also
> >prevents a traditional recursive approach when the kernel stack struct is
> >limited. The algorithm recursively splits the bitmap into smaller chunks to
> >find the highest order mTHPs that satisfy the collapse criteria. We start
> >by attempting the PMD order, then moved on the consecutively lower orders
> >(mTHP collapse). The stack maintains a pair of variables (offset, order),
> >indicating the number of PTEs from the start of the PMD, and the order of
> >the potential collapse candidate.
> >
> >The algorithm for consuming the bitmap works as such:
> > 1) push (0, HPAGE_PMD_ORDER) onto the stack
> > 2) pop the stack
> > 3) check if the number of set bits in that (offset,order) pair
> > statisfy the max_ptes_none threshold for that order
> > 4) if yes, attempt collapse
> > 5) if no (or collapse fails), push two new stack items representing
> > the left and right halves of the current bitmap range, at the
> > next lower order
> > 6) repeat at step (2) until stack is empty.
> >
> >Below is a diagram representing the algorithm and stack items:
> >
> > offset mid_offset
> > | |
> > | |
> > v v
> > ____________________________________
> > | PTE Page Table |
> > --------------------------------------
> > <-------><------->
> > order-1 order-1
> >
> >mTHP collapses reject regions containing swapped out or shared pages.
> >This is because adding new entries can lead to new none pages, and these
> >may lead to constant promotion into a higher order mTHP. A similar
> >issue can occur with "max_ptes_none > HPAGE_PMD_NR/2" due to a collapse
> >introducing at least 2x the number of pages, and on a future scan will
> >satisfy the promotion condition once again. This issue is prevented via
> >the collapse_max_ptes_none() function which imposes the max_ptes_none
> >restrictions above.
> >
> >We currently only support mTHP collapse for max_ptes_none values of 0
> >and HPAGE_PMD_NR - 1. resulting in the following behavior:
> >
> > - max_ptes_none=0: Never introduce new empty pages during collapse
> > - max_ptes_none=HPAGE_PMD_NR-1: Always try collapse to the highest
> > available mTHP order
> >
> >Any other max_ptes_none value will emit a warning and skip mTHP collapse
> >attempts. There should be no behavior change for PMD collapse.
> >
> >Once we determine what mTHP sizes fits best in that PMD range a collapse
> >is attempted. A minimum collapse order of 2 is used as this is the lowest
> >order supported by anon memory as defined by THP_ORDERS_ALL_ANON.
> >
> >Currently madv_collapse is not supported and will only attempt PMD
> >collapse.
> >
> >We can also remove the check for is_khugepaged inside the PMD scan as
> >the collapse_max_ptes_none() function handles this logic now.
> >
> >Signed-off-by: Nico Pache <npache@redhat.com>
>
> [...]
>
> >+static int mthp_collapse(struct mm_struct *mm, unsigned long address,
> >+ int referenced, int unmapped, struct collapse_control *cc,
> >+ unsigned long enabled_orders)
> >+{
> >+ unsigned int nr_occupied_ptes, nr_ptes;
> >+ int max_ptes_none, collapsed = 0, stack_size = 0;
> >+ unsigned long collapse_address;
> >+ struct mthp_range range;
> >+ u16 offset;
> >+ u8 order;
> >+
> >+ collapse_mthp_stack_push(cc, &stack_size, 0, HPAGE_PMD_ORDER);
> >+
> >+ while (stack_size) {
> >+ range = collapse_mthp_stack_pop(cc, &stack_size);
> >+ order = range.order;
> >+ offset = range.offset;
> >+ nr_ptes = 1UL << order;
> >+
> >+ if (!test_bit(order, &enabled_orders))
> >+ goto next_order;
> >+
> >+ max_ptes_none = collapse_max_ptes_none(cc, NULL, order);
>
> I am thinking whether there is a behavioral change for userfaultfd_armed(vma).
>
> collapse_single_pmd()
> collapse_scan_pmd
> max_ptes_none = collapse_max_ptes_none(cc, vma)
> max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT --- (1)
> mthp_collapse
> max_ptes_none = collapse_max_ptes_none(cc, NULL) --- (2)
> collapse_huge_page(mm)
> hugepage_vma_revalidate(&vma)
> __collapse_huge_page_isolate(vma)
> max_ptes_none = collapse_max_ptes_none(cc, vma)
>
> Before mthp_collapse() introduced, userfaultfd_armed(vma) is skipped if there
> is any pte_none_or_zero() in collapse_scan_pmd().
>
> But now, max_ptes_none could be set to KHUGEPAGED_MAX_PTES_LIMIT at (1), so
> that we can scan all the pte to get the bitmap. This means
> userfaultfd_armed(vma) could continue even with pte_none_or_zero().
>
> Then in mthp_collapse(), collapse_max_ptes_none() at (2) ignores
> userfaultfd_armed(vma), which means it will continue to collapse a
> userfaultfd_armed(vma) when there is pte_none_or_zero().
>
> The good news is we will stop at __collapse_huge_page_isolate(), where we
> get collapse_max_ptes_none() with vma. But we already did a lot of work.
Good catch!
As you stated we eventually ensure we respect the uffd checks. So
there are no correctness issues, just the potential for wasted cycles.
At (1) we only do this if mTHPs are enabled. If that is the case, the
only waste that can arise is at the PMD order, as that order respects
the max_ptes_none value.
I think one approach is to gate (1) with the uffd check as well. That
way, if mTHPs are enabled and its uffd-armed, max_ptes_none will stay
at 0, and we bail early on the scan early if any none_ptes are hit.
But then we lose the ability to collapse to mTHPs that are uffd-armed,
where the PMD has none/zero-ptes and the mTHP fully has 0
non-none/zero-ptes.
ie) assume a PMD is 16 x's [xxxxxxxx00000000]
where x is a populated pte and 0 is not
If we guard this scan (1), then we will never check if its possible to
collapse to the smaller orders.
Let me know if you see a flaw in my logic, I think it's best to keep it as is?
>
> Not sure if I missed something.
>
> >+
> >+ if (max_ptes_none < 0)
> >+ return collapsed;
> >+
> >+ nr_occupied_ptes = collapse_mthp_count_present(cc, offset,
> >+ nr_ptes);
> >+
> >+ if (nr_occupied_ptes >= nr_ptes - max_ptes_none) {
> >+ int ret;
> >+
> >+ collapse_address = address + offset * PAGE_SIZE;
> >+ ret = collapse_huge_page(mm, collapse_address, referenced,
> >+ unmapped, cc, order);
> >+ if (ret == SCAN_SUCCEED) {
> >+ collapsed += nr_ptes;
> >+ continue;
> >+ }
> >+ }
> >+
> >+next_order:
> >+ if (order > KHUGEPAGED_MIN_MTHP_ORDER) {
> >+ const u8 next_order = order - 1;
> >+ const u16 mid_offset = offset + (nr_ptes / 2);
> >+
> >+ collapse_mthp_stack_push(cc, &stack_size, mid_offset,
> >+ next_order);
> >+ collapse_mthp_stack_push(cc, &stack_size, offset,
> >+ next_order);
> >+ }
> >+ }
> >+ return collapsed;
> >+}
> >+
> > static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > struct vm_area_struct *vma, unsigned long start_addr,
> > bool *lock_dropped, struct collapse_control *cc)
> > {
> >- const int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> >+ int max_ptes_none = collapse_max_ptes_none(cc, vma, HPAGE_PMD_ORDER);
> > const unsigned int max_ptes_shared = collapse_max_ptes_shared(cc, HPAGE_PMD_ORDER);
> > const unsigned int max_ptes_swap = collapse_max_ptes_swap(cc, HPAGE_PMD_ORDER);
> >+ enum tva_type tva_flags = cc->is_khugepaged ? TVA_KHUGEPAGED : TVA_FORCED_COLLAPSE;
> > pmd_t *pmd;
> >- pte_t *pte, *_pte;
> >- int none_or_zero = 0, shared = 0, referenced = 0;
> >+ pte_t *pte, *_pte, pteval;
> >+ int i;
> >+ int none_or_zero = 0, shared = 0, nr_collapsed = 0, referenced = 0;
> > enum scan_result result = SCAN_FAIL;
> > struct page *page = NULL;
> > struct folio *folio = NULL;
> > unsigned long addr;
> >+ unsigned long enabled_orders;
> > spinlock_t *ptl;
> > int node = NUMA_NO_NODE, unmapped = 0;
> >
> >@@ -1429,8 +1579,19 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > goto out;
> > }
> >
> >+ bitmap_zero(cc->mthp_bitmap, MAX_PTRS_PER_PTE);
> > memset(cc->node_load, 0, sizeof(cc->node_load));
> > nodes_clear(cc->alloc_nmask);
> >+
> >+ enabled_orders = collapse_allowable_orders(vma, vma->vm_flags, tva_flags);
>
> Would it be 0 at this point?
If your question relates to the issue you brought up above, then yes,
max_ptes_none would be 0 if it's uffd-armed. We must recheck the
uffd-armed status before modifying it to 511.
>
> >+
> >+ /*
> >+ * If PMD is the only enabled order, enforce max_ptes_none, otherwise
> >+ * scan all pages to populate the bitmap for mTHP collapse.
> >+ */
> >+ if (enabled_orders != BIT(HPAGE_PMD_ORDER))
> >+ max_ptes_none = KHUGEPAGED_MAX_PTES_LIMIT;
> >+
> > pte = pte_offset_map_lock(mm, pmd, start_addr, &ptl);
> > if (!pte) {
> > cc->progress++;
> >@@ -1438,11 +1599,13 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > goto out;
> > }
> >
> >- for (addr = start_addr, _pte = pte; _pte < pte + HPAGE_PMD_NR;
> >- _pte++, addr += PAGE_SIZE) {
> >+ for (i = 0; i < HPAGE_PMD_NR; i++) {
> >+ _pte = pte + i;
> >+ addr = start_addr + i * PAGE_SIZE;
> >+ pteval = ptep_get(_pte);
> >+
> > cc->progress++;
> >
> >- pte_t pteval = ptep_get(_pte);
> > if (pte_none_or_zero(pteval)) {
> > if (++none_or_zero > max_ptes_none) {
> > result = SCAN_EXCEED_NONE_PTE;
> >@@ -1522,6 +1685,8 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > }
> > }
> >
> >+ /* Set bit for occupied pages */
> >+ __set_bit(i, cc->mthp_bitmap);
> > /*
> > * Record which node the original page is from and save this
> > * information to cc->node_load[].
> >@@ -1580,10 +1745,11 @@ static enum scan_result collapse_scan_pmd(struct mm_struct *mm,
> > if (result == SCAN_SUCCEED) {
> > /* collapse_huge_page expects the lock to be dropped before calling */
> > mmap_read_unlock(mm);
> >- result = collapse_huge_page(mm, start_addr, referenced,
> >- unmapped, cc, HPAGE_PMD_ORDER);
> >+ nr_collapsed = mthp_collapse(mm, start_addr, referenced, unmapped,
> >+ cc, enabled_orders);
> > /* collapse_huge_page will return with the mmap_lock released */
>
> collapse_huge_page will return with mmap_lock released, but mthp_collapse()
> may not?
We are now releasing the lock before calling mthp_collapse, which
subsequently calls collapse_huge_page. Even if `collapse_huge_page` is
never called-- say, because enabled_orders is 0 (which should not
happen) and all collapse orders are skipped (never calling
collapse_huge_page)-- we still return here with the lock dropped.
I think this is sound. Let me know if you think differently.
Cheers :)
-- Nico
>
> > *lock_dropped = true;
> >+ result = nr_collapsed ? SCAN_SUCCEED : SCAN_FAIL;
> > }
> > out:
> > trace_mm_khugepaged_scan_pmd(mm, folio, referenced,
> >--
> >2.54.0
>
> --
> Wei Yang
> Help you, Help me
>
^ permalink raw reply
* Re: [PATCH v2 1/2] tools/mm: add a standalone GUP microbenchmark
From: Mark Brown @ 2026-05-20 11:58 UTC (permalink / raw)
To: Sarthak Sharma
Cc: Mike Rapoport, Andrew Morton, David Hildenbrand, Jonathan Corbet,
Jason Gunthorpe, John Hubbard, Peter Xu, Lorenzo Stoakes,
Liam R . Howlett, Vlastimil Babka, Suren Baghdasaryan,
Michal Hocko, Shuah Khan, linux-mm, linux-kselftest, linux-kernel,
linux-doc
In-Reply-To: <9382431f-3746-4477-bbef-87abb58bf180@arm.com>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
On Wed, May 20, 2026 at 03:45:53PM +0530, Sarthak Sharma wrote:
> On 5/20/26 2:25 PM, Mike Rapoport wrote:
> > It seems that we need to better share the common code in
> > tools/testing/selftest.
> > And adding another copy of the hugetlb detection and setup code does not
> > seem like a great idea.
> Agreed, but that was the least disruptive approach I could think of.
> I am thinking of doing this now: should I move the
> hugepage_settings.[ch] to tools/lib/ and move the read_num(),
> write_num(), read_file() and write_file() helpers to a separate file in
> tools/lib/ itself without any ksft dependency? Then both
> tools/testing/selftests/* and tools/mm/ could share the same code.
Using tools/lib sounds sensible to me - as well as the sharing it makes
it clear that it's a library used by multiple things so avoids the
issues we sometimes have with selftest directories referencing each
other.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] video: console: mdacon: remove this obsolete driver
From: Helge Deller @ 2026-05-20 11:45 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-doc, linux-alpha, linux-serial,
linux-fbdev, Linux DRI Development, linuxppc-dev
Cc: Jonathan Corbet, Shuah Khan, Richard Henderson, Matt Turner,
Magnus Lindholm, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Greg Kroah-Hartman,
Jiri Slaby, Nicolas Pitre
In-Reply-To: <20260520033155.17378-1-enelsonmoore@gmail.com>
On 5/20/26 05:31, Ethan Nelson-Moore wrote:
> The mdacon driver supports using ISA MDA or Hercules-compatible display
> adapters as a secondary text console. This was commonly used in the
> 1990s and earlier for debugging software which took over the primary
> display. It is highly unlikely anyone is doing so nowadays because
> serial consoles and much better methods of debugging exist.
>
> The driver is not enabled by any defconfig, nor any of the
> dozens of distro configs collected at [1]. It has been relegated to VTs
> 13-16 since commit 0b9cf3aa6b1e ("mdacon messing up default vc's - set
> default to vc13-16 again") in Linux 2.6.27 (and before Linux 2.5.53 -
> see the link in the message of the above commit). The change in 2.6.27
> was done because it was incorrectly detecting non-MDA adapters as MDA
> and taking over all VTs, rendering them unusable.
>
> Furthermore, vgacon supports using MDA/Hercules-compatible adapters as
> the primary text console, so any systems with only one of these
> adapters were already using vgacon and will not experience any loss in
> functionality from the removal of this driver.
>
> Given all of these factors, the mdacon driver is likely entirely
> unused. Remove it.
I've applied this patch to the fbdev git tree, since I also believe that
there is no use case or user left (with Linux kernels >= 7.0), which uses the mdacon.
If someone thinks we need to keep it, please speak up.
Helge
>
> [1] https://github.com/nyrahul/linux-kernel-configs/tree/f0bee86a135a0406ea427855f52702dd00d770f9
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> .../admin-guide/kernel-parameters.txt | 5 -
> arch/alpha/kernel/io.c | 2 +-
> arch/powerpc/include/asm/vga.h | 4 +-
> drivers/tty/vt/vt.c | 3 -
> drivers/video/console/Kconfig | 15 -
> drivers/video/console/Makefile | 1 -
> drivers/video/console/mdacon.c | 566 ------------------
> include/linux/console.h | 2 -
> include/linux/vt_buffer.h | 2 +-
> 9 files changed, 4 insertions(+), 596 deletions(-)
> delete mode 100644 drivers/video/console/mdacon.c
^ permalink raw reply
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Julian Orth @ 2026-05-20 11:46 UTC (permalink / raw)
To: Christian König
Cc: Michel Dänzer, Xaver Hugl, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Sumit Semwal,
Jonathan Corbet, Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman,
dri-devel, linux-kernel, linux-media, linaro-mm-sig, linux-doc,
wayland-devel
In-Reply-To: <1e94106a-f72e-447e-9885-2d2cc8f8e722@amd.com>
On Wed, May 20, 2026 at 1:21 PM Christian König
<christian.koenig@amd.com> wrote:
>
> On 5/20/26 10:13, Michel Dänzer wrote:
> > On 5/19/26 18:00, Christian König wrote:
> >> On 5/19/26 17:31, Xaver Hugl wrote:
> >>> Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König
> >>> <christian.koenig@amd.com>:
> >>>>> 1. This series makes the ability to manipulate syncobjs available
> >>>>> independently of attached hardware.
> >>>>> 2. It makes it available under a consistent path /dev/syncobj.
> >>>>
> >>>> Exactly that is a big no-go. This has to be under /dev/dri.
> >>> FWIW udmabuf is also under /dev directly, but I don't think any
> >>> compositor developer would complain about a different path.
> >>> What are the rules for that? Could this simply be put in /dev/dri/syncobj?
> >>
> >> The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
> >>
> >> But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
> >>
> >> So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.
> >
> > I'm not quite sure what you're getting at here, just to be clear though:
> >
> > While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point.
>
> Yeah I know. I'm one of the people who came up with the idea of doing wait before signal this way in the drm_syncobj.
>
> What I wanted to say is that a lot of people used the dma_fence to implement wait before signal before and got a bloody nose from that.
>
> > (It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well)
>
> This is what surprised me.
>
> The drm_syncobj implementation solved the wait before signal for the kernel, but my last feedback was that we basically just moved the issue to userspace and Wayland compositors would have quite some overhead to implement it correctly.
>
> That compositors now use eventfd to simplify that was news to me but makes totally sense in hindsight.
>
> But anyway, we need to somehow simplify the drm_syncobj -> eventfd usage in the compositor.
That is not the only usage in the compositor. Compositors use all of
the following operations on syncobjs:
- creating syncobjs
- waiting for points synchronously
- signaling points without a sync file
- querying points
- transferring sync files between points
- exporting sync files
- importing sync files
Which you can see by looking at the userspace code linked in the cover
letter. Bypassing the handle in one ioctl would gain compositors
nothing since they would still have to convert to handles and manage
their lifetime for all other ioctls.
> That requirement is perfectly justified and avoiding importing the drm_syncobj fd into any DRM driver should actually be really easy to implement.
That is what this series does.
>
> Regards,
> Christian.
^ permalink raw reply
* Re: [PATCH v5 02/13] iio: core: support 64-bit register through debugfs
From: Jonathan Cameron @ 2026-05-20 11:31 UTC (permalink / raw)
To: Rodrigo Alencar
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <unsohuo2hfsa7zzhprfpvtbatmu3guew6jpal7k2wvirpzwxfn@rjb4uz3k5dp3>
On Mon, 18 May 2026 14:56:06 +0100
Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
> On 26/05/17 06:56PM, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Medium] Silent truncation of 64-bit values when written to a 32-bit register access function.
> > --
> >
> > commit 64785a0c1416e2cf718b558aa7a2cc9ac39b2d81
> > Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > iio: core: support 64-bit register through debugfs
> >
> > This commit introduces a debugfs_reg64_access function pointer to iio_info
> > to allow 64-bit register reads and writes through debugfs. The file operation
> > callbacks are modified to prefer the 64-bit variant when available.
> >
> > > diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> > > index e587aca79b8e7..5c8404efd0a56 100644
> > > --- a/drivers/iio/industrialio-core.c
> > > +++ b/drivers/iio/industrialio-core.c
> >
> > [ ... ]
> >
> > > @@ -429,7 +439,7 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> > >
> > > buf[ret] = '\0';
> > >
> > > - ret = sscanf(buf, "%i %i", ®, &val);
> > > + ret = sscanf(buf, "%i %lli", ®, &val64);
> > >
> > > switch (ret) {
> > > case 1:
> > > @@ -437,8 +447,12 @@ static ssize_t iio_debugfs_write_reg(struct file *file,
> > > break;
> > > case 2:
> > > iio_dev_opaque->cached_reg_addr = reg;
> > > - ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> > > - val, NULL);
> > > + if (indio_dev->info->debugfs_reg64_access)
> > > + ret = indio_dev->info->debugfs_reg64_access(indio_dev, reg,
> > > + val64, NULL);
> > > + else
> > > + ret = indio_dev->info->debugfs_reg_access(indio_dev, reg,
> > > + val64, NULL);
> >
> > Could this introduce a regression where values are silently truncated if the
> > provided input exceeds 32 bits?
> >
> > Since the input is now unconditionally parsed as a 64-bit integer, falling
> > back to debugfs_reg_access (which takes an unsigned int for writeval) will
> > implicitly cast val64. If a user provides a value larger than UINT_MAX to a
> > driver that only provides the 32-bit callback, it appears the value will be
> > truncated rather than rejected with an error like -EINVAL.
>
> Maybe -EINVAL can be returned for that case indeed. For a debug interface I
> did not see that as a problem.
Agreed - I don't see this as important either way.
>
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260517-ad9910-iio-driver-v5-0-31599c88314a@analog.com?part=2
>
^ permalink raw reply
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Christian König @ 2026-05-20 11:21 UTC (permalink / raw)
To: Michel Dänzer, Xaver Hugl
Cc: Julian Orth, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Sumit Semwal, Jonathan Corbet,
Shuah Khan, Arnd Bergmann, Greg Kroah-Hartman, dri-devel,
linux-kernel, linux-media, linaro-mm-sig, linux-doc,
wayland-devel
In-Reply-To: <385a4d4f-fe22-41a7-8d4b-4dc6bc9930d3@mailbox.org>
On 5/20/26 10:13, Michel Dänzer wrote:
> On 5/19/26 18:00, Christian König wrote:
>> On 5/19/26 17:31, Xaver Hugl wrote:
>>> Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König
>>> <christian.koenig@amd.com>:
>>>>> 1. This series makes the ability to manipulate syncobjs available
>>>>> independently of attached hardware.
>>>>> 2. It makes it available under a consistent path /dev/syncobj.
>>>>
>>>> Exactly that is a big no-go. This has to be under /dev/dri.
>>> FWIW udmabuf is also under /dev directly, but I don't think any
>>> compositor developer would complain about a different path.
>>> What are the rules for that? Could this simply be put in /dev/dri/syncobj?
>>
>> The syncobj are actually the DRM specific way of doing things. The general kernel wide way is to use sync files (see drivers/dma-buf/sync_file.c).
>>
>> But there has already been tons of problems with those sync files. E.g. they doesn't support your use case at all since they don't have wait before submit behavior.
>>
>> So there are already ways to do this, but the Linux kernel so far told everybody that this is forbidden. The DRM syncobj wait before signal functionality is much better, but then basically the second try to do this.
>
> I'm not quite sure what you're getting at here, just to be clear though:
>
> While the syncobj Wayland protocol extension supports wait-before-submit behaviour at the Wayland protocol level, it doesn't need or cause wait-before-submit behaviour for DMA fences in the kernel. The usual rules apply to fences attached to syncobj timeline points. The wait-before-submit behaviour at the Wayland protocol level comes from allowing submit before a fence is attached to the acquire timeline point.
Yeah I know. I'm one of the people who came up with the idea of doing wait before signal this way in the drm_syncobj.
What I wanted to say is that a lot of people used the dma_fence to implement wait before signal before and got a bloody nose from that.
> (It took me a while to realize this distinction, before which I mistakenly thought the kernel's DMA fence rules would prohibit wait-before-submit behaviour at the Wayland protocol level as well)
This is what surprised me.
The drm_syncobj implementation solved the wait before signal for the kernel, but my last feedback was that we basically just moved the issue to userspace and Wayland compositors would have quite some overhead to implement it correctly.
That compositors now use eventfd to simplify that was news to me but makes totally sense in hindsight.
But anyway, we need to somehow simplify the drm_syncobj -> eventfd usage in the compositor. That requirement is perfectly justified and avoiding importing the drm_syncobj fd into any DRM driver should actually be really easy to implement.
Regards,
Christian.
^ permalink raw reply
* [PATCH AUTOSEL 7.0] Documentation: security-bugs: do not systematically Cc the security team
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Willy Tarreau, Greg KH, Leon Romanovsky, Jonathan Corbet,
Sasha Levin, security, workflows, linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Willy Tarreau <w@1wt.eu>
[ Upstream commit aed3c3346765e4317bb2ec6ff872e1c952e128ab ]
With the increase of automated reports, the security team is dealing
with way more messages than really needed. The reporting process works
well with most teams so there is no need to systematically involve the
security team in reports.
Let's suggest to keep it for small lists of recipients and new reporters
only. This should continue to cover the risk of lost messages while
reducing the volume from prolific reporters.
Cc: Greg KH <gregkh@linuxfoundation.org>
Cc: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Leon Romanovsky <leon@kernel.org>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260509094755.2838-2-w@1wt.eu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `Documentation/process/security-bugs`; action verb
`do not`; intent is to update security bug reporting instructions so
reporters do not always Cc the security team.
Record 1.2: Tags present: `Cc: Greg KH <gregkh@linuxfoundation.org>`,
`Cc: Leon Romanovsky <leon@kernel.org>`, `Reviewed-by: Leon Romanovsky
<leon@kernel.org>`, `Reviewed-by: Greg Kroah-Hartman
<gregkh@linuxfoundation.org>`, `Signed-off-by: Willy Tarreau
<w@1wt.eu>`, `Signed-off-by: Jonathan Corbet <corbet@lwn.net>`,
`Message-ID: <20260509094755.2838-2-w@1wt.eu>`. No `Fixes:`, no
`Reported-by:`, no `Tested-by:`, no `Cc: stable`.
Record 1.3: The body describes a process/documentation problem:
increased automated reports create more mail to the security team than
needed. Symptom is excess security-team involvement, not a kernel
runtime crash or data corruption. No affected kernel versions are named.
Record 1.4: This is not a hidden code bug fix. It is an explicit
documentation/process update that corrects now-overbroad guidance.
## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/process/security-bugs.rst`,
9 insertions and 1 deletion in the submitted patch. No functions are
modified. Scope is single-file documentation-only.
Record 2.2: Before: reports “must” be sent to maintainers with the
security team in Cc. After: reports still go to maintainers, but
security-team Cc is mandatory only for two-or-fewer recipients, advised
for early reports or specific help, and no longer necessary for
comfortable reporters sending to large teams.
Record 2.3: Bug category is documentation/process correctness. No
resource leak, race, memory safety, refcount, initialization, endian, or
hardware quirk mechanism exists.
Record 2.4: Fix quality is high for its scope: small, reviewed,
documentation-only, no runtime behavior. Regression risk is limited to
possibly changing reporter behavior; no kernel runtime regression is
possible from the diff itself.
## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the replaced sentence was introduced by
`a72b832a482372` (“Documentation: explain how to find maintainers
addresses for security reports”), first contained by `v7.0-rc7~8^2~2`.
Record 3.2: No `Fixes:` tag is present, so there is no Fixes target to
follow.
Record 3.3: Recent history of `Documentation/process/security-bugs.rst`
shows a series of security-reporting documentation updates by Willy
Tarreau, including contact/process clarifications and typo fixes. This
patch is standalone at the diff level but part of a three-patch
documentation series.
Record 3.4: The author has multiple recent commits in
`Documentation/process/security-bugs.rst`. Maintainer lookup identifies
`Security Officers <security@kernel.org>` and `Jonathan Corbet
<corbet@lwn.net>` for this file.
Record 3.5: No code dependencies or functions exist. The exact patch
depends on the newer rewritten security-bugs document layout present in
`7.0.y`; older stable branches do not contain `a72b832a482372`.
## Phase 4: Mailing List And External Research
Record 4.1: `b4 dig -c` could not be used because no candidate commit
SHA was available locally or in the prompt, and local `master`, `docs-
next`, and `all-next` searches did not find the commit object. Using the
supplied Message-ID, `b4 am` found the original submission at
`https://patch.msgid.link/20260509094755.2838-1-w@1wt.eu`.
Record 4.2: `b4 am` and the mbox show v3 of a 3-patch series, 33 thread
messages, sent to Greg KH, Leon Romanovsky, Jonathan Corbet, Shuah Khan,
`security@kernel.org`, `workflows@vger.kernel.org`, `linux-
doc@vger.kernel.org`, and `linux-kernel@vger.kernel.org`.
Record 4.3: No bug report link, syzbot report, Bugzilla report, or user
crash report exists. Lore WebFetch was blocked by Anubis, but `b4`
successfully fetched the mbox.
Record 4.4: Series context: patch 1/3 is this Cc guidance change; patch
2/3 adds security-bug/threat-model documentation; patch 3/3 clarifies
AI-assisted reports. Cover letter says v2 reworded the “when to Cc” part
based on Greg’s feedback; v3 included wording/structure feedback and
added reviews.
Record 4.5: I found no stable-specific discussion or stable nomination
in the fetched thread. Jonathan Corbet said he applied the series to
`docs-fixes` after short linux-next exposure.
## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation only.
Record 5.2: No callers; affected audience is readers of
`Documentation/process/security-bugs.rst`.
Record 5.3: No callees or side effects.
Record 5.4: Reachability is not runtime reachability. The path is
“reporter reads stable-tree documentation and follows reporting
instructions.”
Record 5.5: `rg` found the old mandatory-Cc sentence only in
`Documentation/process/security-bugs.rst`; related security-team
references remain elsewhere in the same document.
## Phase 6: Cross-Referencing And Stable Tree Analysis
Record 6.1: `a72b832a482372` is an ancestor of `stable/linux-7.0.y` but
not of local `stable/linux-5.15.y`, `stable/linux-6.1.y`,
`stable/linux-6.6.y`, `stable/linux-6.12.y`, `stable/linux-6.18.y`, or
`stable/linux-6.19.y`. So this exact buggy/obsolete sentence is
confirmed in `7.0.y`; older local stable trees have older document
layouts.
Record 6.2: `b4` reports the series base applies cleanly to the current
tree, which is `stable/linux-7.0.y`. Older stable trees would need a
different documentation backport if maintainers wanted equivalent
guidance there.
Record 6.3: No related stable fix for this exact wording was found in
local history.
## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is documentation/process, specifically security
bug reporting. Criticality is process-important, not runtime
core/driver/filesystem criticality.
Record 7.2: The file has active recent development, with several
2025-2026 security-reporting documentation updates.
## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population is documentation readers: security bug
reporters, maintainers, and the kernel security team. No running kernel
users are directly affected.
Record 8.2: Trigger is following the stable tree’s security-bug
reporting documentation. This can be done by any reporter, but it is not
a syscall or kernel execution path.
Record 8.3: Failure mode severity is low for runtime stability, but
medium for security-process efficiency: the old wording can
unnecessarily add the private security team to large-team reports.
Record 8.4: Benefit is moderate for keeping security reporting guidance
current and reducing unnecessary private-list traffic. Risk is very low
because the patch is documentation-only and reviewed.
## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: documentation-only; zero runtime
regression risk; corrects overbroad/obsolete reporting guidance;
reviewed by Leon Romanovsky and Greg Kroah-Hartman; applied by
documentation maintainer Jonathan Corbet; relevant to security reporting
workflow; clean for `7.0.y`.
Evidence against: it does not fix a kernel runtime bug, crash, security
vulnerability, corruption, or deadlock; older stable trees do not
contain the exact rewritten section, so this exact patch is mainly
applicable to `7.0.y`.
Unresolved: I could not run `b4 dig -c` without a commit SHA, and
WebFetch of lore was blocked by Anubis. The `b4` Message-ID fetch
supplied the needed thread content.
Record 9.2: Stable rules: obviously correct and reviewed: yes. Fixes
real user-visible runtime bug: no. Important
crash/security/corruption/deadlock: no. Small and contained: yes, one
documentation file. No new feature/API: yes. Applies to stable: yes for
`7.0.y`; older branches need separate handling.
Record 9.3: Exception category: documentation fix/update. This is the
reason it qualifies despite not being a runtime bug.
Record 9.4: Decision: backport where the affected documentation exists,
especially `7.0.y`. The runtime benefit is nonexistent, but the risk is
also nonexistent, and stable policy exceptions allow documentation fixes
that correct obsolete guidance.
## Verification
- Phase 1: Parsed supplied commit tags and b4 patch headers; confirmed
no `Fixes:`, `Reported-by:`, `Tested-by`, or `Cc: stable`.
- Phase 2: Read supplied diff and b4 patch; confirmed one documentation
file, 9 insertions/1 deletion, no code.
- Phase 3: Ran `git blame -L 148,152 -- Documentation/process/security-
bugs.rst`; old sentence introduced by `a72b832a482372`.
- Phase 3: Ran `git describe --contains a72b832a482372`; first contained
around `v7.0-rc7~8^2~2`.
- Phase 3: Ran file and author history commands; confirmed recent
related docs updates by Willy Tarreau.
- Phase 4: Local `git log` searches on current history, `master`, `docs-
next`, and `all-next` did not find the candidate commit object.
- Phase 4: `b4 am -o /tmp/security-bugs-b4
20260509094755.2838-2-w@1wt.eu` found a v3 3-patch series, 33
messages, and reported clean apply to current tree.
- Phase 4: `b4 mbox` saved the thread mbox; `rg` found no stable
nomination or NAK for this patch.
- Phase 4: WebFetch of lore URLs was blocked by Anubis; not used for the
final decision.
- Phase 5: `rg` over `Documentation` confirmed the exact mandatory-Cc
sentence appears in `Documentation/process/security-bugs.rst`.
- Phase 6: `git merge-base --is-ancestor a72b832a482372
stable/linux-7.0.y` returned true; checks for `5.15.y`, `6.1.y`,
`6.6.y`, `6.12.y`, `6.18.y`, and `6.19.y` returned false.
- Phase 7: `./scripts/get_maintainer.pl` identified Security Officers
and Jonathan Corbet for the file; `MAINTAINERS` confirms
`DOCUMENTATION PROCESS`, `SECURITY CONTACT`, and `STABLE BRANCH`
entries.
- Phase 8: Failure mode verified from commit text and diff only:
documentation/process burden, not runtime failure.
**YES**
Documentation/process/security-bugs.rst | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 27b028e858610..6dc525858125e 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -148,7 +148,15 @@ run additional tests. Reports where the reporter does not respond promptly
or cannot effectively discuss their findings may be abandoned if the
communication does not quickly improve.
-The report must be sent to maintainers, with the security team in ``Cc:``.
+The report must be sent to maintainers. If there are two or fewer
+recipients in your message, you must also always Cc: the Linux kernel
+security team who will ensure the message is delivered to the proper
+people, and will be able to assist small maintainer teams with processes
+they may not be familiar with. For larger teams, Cc: the Linux kernel
+security team for your first few reports or when seeking specific help,
+such as when resending a message which got no response within a week.
+Once you have become comfortable with the process for a few reports, it is
+no longer necessary to Cc: the security list when sending to large teams.
The Linux kernel security team can be contacted by email at
<security@kernel.org>. This is a private list of security officers
who will help verify the bug report and assist developers working on a fix.
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] ALSA: doc: cs35l56: Update path to HDA driver source
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Richard Fitzgerald, Takashi Iwai, Sasha Levin, david.rhodes,
perex, tiwai, corbet, linux-sound, patches, linux-doc,
linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Richard Fitzgerald <rf@opensource.cirrus.com>
[ Upstream commit 74e8409821ac8cda70bf23eb593f2c7f6e3b5a2f ]
The HDA drivers were moved to sound/hda/... so update a Documentation
reference that still pointed to the old location.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260511104148.36382-1-rf@opensource.cirrus.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Record 1.1: Subsystem `ALSA: doc: cs35l56`; action verb `Update`;
intent: correct a stale documentation path to the HDA driver source.
Record 1.2: Tags present in supplied message: `Signed-off-by: Richard
Fitzgerald <rf@opensource.cirrus.com>`, `Link: https://patch.msgid.link/
20260511104148.36382-1-rf@opensource.cirrus.com`, `Signed-off-by:
Takashi Iwai <tiwai@suse.de>`. No `Fixes:`, `Reported-by:`, `Tested-
by:`, `Reviewed-by:`, `Acked-by:`, or `Cc: stable`.
Record 1.3: The body says the HDA drivers moved to `sound/hda/...`,
leaving this documentation reference pointing at the old
`sound/pci/hda/...` location. Symptom is incorrect documentation only;
no runtime failure, crash, data corruption, or security impact is
described.
Record 1.4: This is not a hidden runtime bug fix. It is a direct
documentation correction.
## Phase 2: Diff Analysis
Record 2.1: One file changed: `Documentation/sound/codecs/cs35l56.rst`,
1 insertion and 1 deletion. No functions modified. Scope: single-file
documentation-only surgical change.
Record 2.2: Before: HDA users were pointed to
`sound/pci/hda/cs35l56_hda.c`. After: they are pointed to
`sound/hda/codecs/side-codecs/cs35l56_hda.c`.
Record 2.3: Bug category: documentation correctness fix. Verified
current tree has `sound/hda/codecs/side-codecs/cs35l56_hda.c`;
`sound/pci/hda` does not exist in this checkout.
Record 2.4: Fix quality is obvious and minimal. Regression risk is
runtime zero, but backport targeting matters: applying it to older trees
where the driver is still under `sound/pci/hda` would make the
documentation wrong.
## Phase 3: Git History Investigation
Record 3.1: `git blame` shows the stale documentation line was
introduced by `088fb4ee17fc4` (`ALSA: doc: cs35l56: Add information
about Cirrus Logic CS35L54/56/57`). The line became stale when
`6014e9021b28e` moved HDA codec drivers into `sound/hda/codecs`.
Record 3.2: No `Fixes:` tag is present, so there was no Fixes target to
follow.
Record 3.3: Recent file history shows only CS35L56 documentation
updates. Related source movement is `6014e9021b28e`, which renamed
`sound/pci/hda/cs35l56_hda.c` to `sound/hda/codecs/side-
codecs/cs35l56_hda.c`.
Record 3.4: Author Richard Fitzgerald has multiple recent CS35L56/HDA-
related commits in this subsystem, including documentation and HDA
driver fixes.
Record 3.5: Dependency identified: this patch is correct only in trees
that already contain the HDA move commit `6014e9021b28e`.
## Phase 4: Mailing List And External Research
Record 4.1: `b4 am` using message ID
`20260511104148.36382-1-rf@opensource.cirrus.com` found a single patch
submission and reported no newer revision. Direct `WebFetch` to
lore/patch.msgid.link was blocked by Anubis, but `b4` retrieved the
mbox.
Record 4.2: `b4 dig -c` could not be run for the candidate commit
because no candidate commit hash was supplied and the commit was not
found on checked named branches searched. `b4 am` verified author DKIM
signatures and the patch metadata. `b4 dig -c 6014e9021b28e -w` verified
the prerequisite move patch was an ALSA HDA series sent to `linux-sound`
and relevant HDA/Cirrus recipients.
Record 4.3: No bug report, syzbot report, crash report, or user report
is linked.
Record 4.4: Candidate is standalone as a documentation update, but
semantically depends on the prior source-tree move.
Record 4.5: Web searches and local pending branch searches found no
stable-specific discussion for this exact documentation patch.
## Phase 5: Code Semantic Analysis
Record 5.1: No functions modified; documentation text only.
Record 5.2: No callers; this is not runtime code.
Record 5.3: No callees; no allocations, locks, I/O, or side effects.
Record 5.4: No userspace-triggerable kernel execution path. Impact is
limited to readers of the documentation.
Record 5.5: Search found the old path only in
`Documentation/sound/codecs/cs35l56.rst` among `.rst` files checked.
## Phase 6: Stable Tree Analysis
Record 6.1: Tag containment shows the documentation exists from
`v6.13+`; the HDA move exists from `v6.17+`. Therefore the stale-path
documentation issue exists only in trees containing both, i.e.
approximately `v6.17+` and later.
Record 6.2: `git apply --check` confirms the patch applies cleanly to
the current `7.0.y` tree. Backport difficulty is trivial for affected
trees, but it must not be applied to trees where the HDA driver still
lives under `sound/pci/hda`.
Record 6.3: No related stable fix for this exact path correction was
found in local pending branches.
## Phase 7: Subsystem And Maintainer Context
Record 7.1: Subsystem is ALSA sound documentation for Cirrus CS35L56
HDA/SoundWire amplifiers. Criticality: peripheral/documentation, not
runtime core.
Record 7.2: Sound documentation and HDA side-codec areas are actively
maintained; recent logs show multiple CS35L56/HDA commits.
## Phase 8: Impact And Risk Assessment
Record 8.1: Affected population: developers, maintainers, integrators,
and users consulting this CS35L56 documentation in kernels where the HDA
source has moved.
Record 8.2: Trigger condition: reading the documentation. Not
triggerable as a kernel runtime fault.
Record 8.3: Failure mode: stale documentation path. Severity LOW, but
documentation fixes are explicitly acceptable stable material due zero
runtime risk.
Record 8.4: Benefit is modest but real for affected trees; risk is very
low if limited to trees with `6014e9021b28e`, but negative for older
trees where the old path is still correct.
## Phase 9: Final Synthesis
Record 9.1: Evidence for backporting: fixes an objectively wrong
documentation reference, one-line contained patch, no runtime regression
risk, applies cleanly to current `7.0.y`, documentation/comment fixes
are an accepted stable exception. Evidence against: no runtime bug, no
important crash/security/corruption impact, and it must be branch-
limited. Unresolved: exact upstream candidate commit hash was not
available locally.
Record 9.2: Stable rules: obviously correct: yes; tested: `b4` says
applies cleanly and local `git apply --check` passed; fixes a real bug:
yes, documentation bug; important runtime issue: no; small and
contained: yes, 1 line; no new feature/API: yes; applies to affected
stable trees: yes, for trees after the HDA move.
Record 9.3: Exception category: documentation fix.
Record 9.4: Decision: backport is appropriate, but only to stable trees
that already contain the HDA source move to `sound/hda/codecs/side-
codecs`. Do not apply to older stable trees where
`sound/pci/hda/cs35l56_hda.c` remains the correct path.
## Verification
- [Phase 1] Parsed supplied commit message and downloaded mbox:
confirmed subject, author, message ID, and one-line documentation
rationale.
- [Phase 2] Read `Documentation/sound/codecs/cs35l56.rst`: confirmed old
path is present.
- [Phase 2] Checked filesystem: confirmed `sound/hda/codecs/side-
codecs/cs35l56_hda.c` exists and `sound/pci/hda` does not in current
tree.
- [Phase 3] `git blame -L 35,45`: confirmed stale line came from
`088fb4ee17fc4`.
- [Phase 3] `git show 6014e9021b28e`: confirmed HDA codecs, including
`cs35l56_hda.c`, were moved from `sound/pci/hda` to
`sound/hda/codecs/side-codecs`.
- [Phase 4] `b4 am`: retrieved the patch, found one patch, no newer
revision, DKIM signed.
- [Phase 4] `b4 dig -c <msgid>`: failed because `b4 dig` requires a
commit-ish, not a message ID.
- [Phase 4] WebFetch to lore/patch.msgid.link: blocked by Anubis.
- [Phase 6] `git tag --contains`: documentation starts at `v6.13+`; HDA
move starts at `v6.17+`.
- [Phase 6] `git apply --check`: candidate patch applies cleanly to
current tree.
- [Phase 6] `git ls-tree`: `v6.6`/`v6.12` have old HDA source path and
no affected doc; `v6.18` has both affected doc and new HDA source
path.
- UNVERIFIED: Candidate final upstream commit hash, because it was not
found on searched local named branches and was not provided.
**YES**
Documentation/sound/codecs/cs35l56.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/sound/codecs/cs35l56.rst b/Documentation/sound/codecs/cs35l56.rst
index d5363b08f5152..b3f8c1c238518 100644
--- a/Documentation/sound/codecs/cs35l56.rst
+++ b/Documentation/sound/codecs/cs35l56.rst
@@ -40,7 +40,7 @@ There are two drivers in the kernel
*For systems using SoundWire*: sound/soc/codecs/cs35l56.c and associated files
-*For systems using HDA*: sound/pci/hda/cs35l56_hda.c
+*For systems using HDA*: sound/hda/codecs/side-codecs/cs35l56_hda.c
Firmware
========
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.12] Documentation: kvm: update links in the references section of AMD Memory Encryption
From: Sasha Levin @ 2026-05-20 11:19 UTC (permalink / raw)
To: patches, stable
Cc: Ninad Naik, Liam Merwick, Paolo Bonzini, Sasha Levin, corbet, kvm,
linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Ninad Naik <ninadnaik07@gmail.com>
[ Upstream commit 80f4a7b8ce7513c203562191426e4d4cc635b095 ]
Replace non-working links in the reference section with the working ones.
Signed-off-by: Ninad Naik <ninadnaik07@gmail.com>
Link: https://patch.msgid.link/20260511174302.811918-1-ninadnaik07@gmail.com/
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: Subsystem `Documentation: kvm`; action verb `update` /
body verb `Replace`; intent is to replace non-working AMD Memory
Encryption reference links with working links.
Step 1.2 Record: Tags found: `Signed-off-by: Ninad Naik
<ninadnaik07@gmail.com>`, `Link: https://patch.msgid.link/20260511174302
.811918-1-ninadnaik07@gmail.com/`, `Reviewed-by: Liam Merwick
<liam.merwick@oracle.com>`, `Signed-off-by: Paolo Bonzini
<pbonzini@redhat.com>`. No `Fixes:`, `Reported-by:`, `Tested-by:`,
`Acked-by:`, or `Cc: stable@vger.kernel.org`.
Step 1.3 Record: The commit body describes a documentation issue only:
reference links in `Documentation/virt/kvm/x86/amd-memory-
encryption.rst` no longer work as intended. The user-visible symptom is
stale/broken documentation references for AMD SEV/SEV-SNP material. No
runtime failure, crash, data corruption, or kernel version note is
described.
Step 1.4 Record: This is not a hidden runtime bug fix. It is a direct
documentation fix, which is an allowed stable exception category due to
zero runtime risk.
## Phase 2: Diff Analysis
Step 2.1 Record: One file changed: `Documentation/virt/kvm/x86/amd-
memory-encryption.rst`, 4 insertions and 4 deletions. No functions are
modified. Scope classification: single-file surgical documentation
update.
Step 2.2 Record: Before, four reference labels pointed to older AMD
URLs. After, those labels point to current AMD Technical Information
Portal URLs, and the SNP firmware ABI reference points to a current AMD
PDF path. Only the `References` section is affected.
Step 2.3 Record: Bug category is documentation correctness, specifically
stale external references. No synchronization, memory safety, reference
counting, initialization, type, logic, or hardware workaround code is
involved.
Step 2.4 Record: Fix quality is high: the diff only swaps URL strings,
preserves labels, and does not touch kernel code or public APIs.
Regression risk is effectively limited to the possibility of choosing a
less useful URL, not runtime behavior.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` on the reference section showed the white-
paper line came from `fbabc2eaef9fd7` in v6.3-rc1, the SNP firmware ABI
line came from `136d8bc931c84f` in v6.11-rc1, and older reference lines
are present in stable branches back to at least `v5.15` by direct branch
grep. Some blame output for pre-rename lines hit a boundary attribution,
so I did not rely on that boundary commit as the true source.
Step 3.2 Record: No `Fixes:` tag is present, so there is no specific
introducing commit to follow.
Step 3.3 Record: Recent file history on `origin/master` includes KVM
SEV/SNP documentation and API additions, including `20c3c4108d58f`,
`dcbcc2323c806`, `ad27ce155566f`, `dee5a47cc7a45`, and `136d8bc931c84f`.
The candidate is standalone because it only changes URL strings and does
not depend on those code/API changes to be meaningful where the same
reference lines exist.
Step 3.4 Record: `git log --author='Ninad Naik'` showed this author has
other documentation link/spelling style commits, including
`a362ae6e7e85b` for `amd-pstate` dead links and `5ed26ffe57ffc` for a
`hwmon` link. I did not verify the author as a KVM maintainer; Paolo
Bonzini committed/applied it and Liam Merwick reviewed it.
Step 3.5 Record: No code symbols or function dependencies exist. The
patch can apply standalone where the same documentation reference block
exists; older stable branches may need context/path adjustments.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c 80f4a7b8ce751` found the original patch
thread at `https://patch.msgid.link/20260511174302.811918-1-
ninadnaik07@gmail.com`. `b4 dig -a` found only v1; `b4 am -c` found no
newer revision.
Step 4.2 Record: `b4 dig -w` showed the patch was sent to KVM and docs
maintainers/lists, including Paolo Bonzini, Jonathan Corbet, Sean
Christopherson, Michael Roth, Liam Merwick, `kvm@vger.kernel.org`, and
`linux-doc@vger.kernel.org`.
Step 4.3 Record: There is no separate bug report or reporter tag. The
thread contains Liam Merwick’s `Reviewed-by` and Paolo Bonzini’s
“Applied, thanks.” I found no NAKs or concerns in the fetched thread.
Step 4.4 Record: The patch is a one-patch series. No related required
patches were identified.
Step 4.5 Record: Web search did not find stable-specific discussion for
this exact subject/hash. Direct WebFetch of lore stable search was
blocked by Anubis, so stable-list search is partially unverified.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: No functions are modified.
Step 5.2 Record: No callers exist because this is documentation.
Documentation references to this file exist from
`Documentation/virt/kvm/api.rst`, `Documentation/admin-guide/kernel-
parameters.txt`, `Documentation/virt/kvm/x86/index.rst`, and related
documentation pages.
Step 5.3 Record: No callees exist. The changed labels are consumed by
Sphinx/ReST documentation rendering.
Step 5.4 Record: No runtime call chain exists. User impact is
documentation usability for KVM SEV/SEV-SNP developers/users.
Step 5.5 Record: Similar pattern exists in prior documentation link
fixes, including `fbabc2eaef9fd7` for an AMD memory encryption white-
paper URL and `bad0524e24201` for an x86 SEV documentation URL.
## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: Stable branches contain affected references.
`stable/linux-5.15.y` and `stable/linux-6.1.y` contain the old KVM AMD
memory encryption doc with three AMD references. `stable/linux-6.6.y`
contains the three current old references. `stable/linux-6.12.y` through
`stable/linux-7.0.y` contain all four references, including the SNP
firmware ABI link.
Step 6.2 Record: Backport difficulty is clean for the current
`linux-7.0.y`-based tree: `git apply --check` succeeded. Older trees
likely need small manual adjustment: `5.15.y` uses the pre-`x86/` path,
`5.15.y`/`6.1.y` have an older white-paper URL, and `6.6.y` lacks the
SNP firmware ABI line.
Step 6.3 Record: `stable/linux-7.0.y` does not contain this candidate
commit by subject. I found prior related doc-link fixes, but not this
exact KVM reference update in stable branches checked.
## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: Subsystem is KVM x86 documentation for AMD SEV/SEV-SNP.
Criticality is peripheral for runtime kernel stability, but relevant to
KVM confidential-computing documentation users.
Step 7.2 Record: File history shows active KVM SEV/SNP documentation
churn due to recent SEV-SNP commands and API documentation. The touched
change itself is isolated documentation.
## Phase 8: Impact And Risk Assessment
Step 8.1 Record: Affected population is documentation users, especially
KVM/SEV/SEV-SNP developers and operators consulting AMD specs from
stable kernel docs.
Step 8.2 Record: Trigger condition is reading the documentation
references. It is not syscall- or runtime-triggered, and unprivileged
runtime triggering is not applicable.
Step 8.3 Record: Failure mode is stale/non-direct documentation links.
Severity is LOW for runtime stability, but valid under the
documentation-fix exception.
Step 8.4 Record: Benefit is modest but real: stable documentation points
users at current AMD references. Risk is very low: 4 URL replacements in
one `.rst` file, no code, no ABI, no behavior change. Risk-benefit ratio
is favorable because runtime regression risk is effectively zero.
## Phase 9: Final Synthesis
Step 9.1 Record: Evidence for backporting: documentation fix exception
applies; patch is tiny; reviewed; applied by KVM maintainer Paolo
Bonzini; no NAKs found; affected references exist in stable trees;
current `7.0.y` patch application check succeeds. Evidence against: no
runtime bug, no crash/security/data-loss impact, and older stable
branches need minor backport adjustment. Unresolved: lore stable search
was blocked by Anubis, so I could not fully verify stable-list
discussion.
Step 9.2 Record: Stable rules checklist: obviously correct and reviewed:
yes; fixes a real issue: yes, stale documentation references; important
runtime issue: no, but documentation fixes are an allowed exception;
small and contained: yes, 4 lines changed in one file; no new
features/APIs: yes; can apply to stable: yes for current `7.0.y`, likely
clean for `6.12.y+`, minor adjustment for older branches.
Step 9.3 Record: Exception category: documentation fix. This is
explicitly the kind of zero-runtime-risk update that can be accepted
even though it is not a runtime correctness fix.
Step 9.4 Record: Decision is YES. Backporting is appropriate for stable
trees that carry the affected documentation, with minor manual
adjustment where older branch context differs.
## Verification
- [Phase 1] `git show --format=fuller --stat --patch 80f4a7b8ce751`:
confirmed subject, tags, one-file documentation diff, and no runtime-
code changes.
- [Phase 2] Diff inspection: confirmed 4 URL replacements only in
`Documentation/virt/kvm/x86/amd-memory-encryption.rst`.
- [Phase 3] `git blame -L 652,664`: confirmed local history for the
reference block, including `fbabc2eaef9fd7` and `136d8bc931c84f`.
- [Phase 3] `git describe --contains`: confirmed `fbabc2eaef9fd7` first
appears by v6.3-rc1 and `136d8bc931c84f` by v6.11-rc1.
- [Phase 3] `git log origin/master --oneline -20 --
Documentation/virt/kvm/x86/amd-memory-encryption.rst`: confirmed
recent KVM SEV/SNP doc history and candidate placement.
- [Phase 4] `b4 dig -c 80f4a7b8ce751`: found original patch thread by
patch-id.
- [Phase 4] `b4 dig -c 80f4a7b8ce751 -a`: confirmed only v1 series.
- [Phase 4] `b4 dig -c 80f4a7b8ce751 -w`: confirmed KVM/docs maintainers
and lists were included.
- [Phase 4] `b4 mbox`/saved thread plus `rg`: confirmed `Reviewed-by:
Liam Merwick` and Paolo’s “Applied, thanks”; found no NAK/stable
request text.
- [Phase 4] WebFetch of lore/patch URLs was blocked by Anubis; b4
successfully fetched the thread.
- [Phase 5] `rg` in the doc file: confirmed changed labels are
referenced by SEV/SNP documentation text.
- [Phase 5] `rg` under `Documentation`: confirmed documentation pages
link to `amd-memory-encryption.rst`.
- [Phase 6] `git grep` across `stable/linux-5.15.y`, `6.1.y`, `6.6.y`,
`6.12.y`, `6.15.y`, `6.16.y`, `6.17.y`, `6.18.y`, `6.19.y`, and
`7.0.y`: confirmed affected old references exist and identified branch
differences.
- [Phase 6] `git diff 80f4a7b8ce751^ 80f4a7b8ce751 | git apply --check`:
confirmed clean application to the current `7.0.y`-based working tree.
- [Phase 8] URL checks with Python HEAD/WebFetch: confirmed old direct
AMD URLs no longer behave as direct PDF references in several cases,
while the new SNP ABI URL returns an AMD PDF; other new AMD TIP URLs
resolve to AMD documentation portal pages.
- UNVERIFIED: full stable mailing-list history, because direct lore
stable WebFetch was blocked by Anubis and web search found no exact
stable discussion.
**YES**
Documentation/virt/kvm/x86/amd-memory-encryption.rst | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/virt/kvm/x86/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
index b2395dd4769de..bd04a908a8dbd 100644
--- a/Documentation/virt/kvm/x86/amd-memory-encryption.rst
+++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst
@@ -656,8 +656,8 @@ References
See [white-paper]_, [api-spec]_, [amd-apm]_, [kvm-forum]_, and [snp-fw-abi]_
for more info.
-.. [white-paper] https://developer.amd.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf
-.. [api-spec] https://support.amd.com/TechDocs/55766_SEV-KM_API_Specification.pdf
-.. [amd-apm] https://support.amd.com/TechDocs/24593.pdf (section 15.34)
+.. [white-paper] https://docs.amd.com/v/u/en-US/memory-encryption-white-paper
+.. [api-spec] https://docs.amd.com/v/u/en-US/55766_PUB_3.24_SEV_API
+.. [amd-apm] https://docs.amd.com/v/u/en-US/24593_3.44_APM_Vol2 (section 15.34)
.. [kvm-forum] https://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf
-.. [snp-fw-abi] https://www.amd.com/system/files/TechDocs/56860.pdf
+.. [snp-fw-abi] https://www.amd.com/content/dam/amd/en/documents/developer/56860.pdf
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0] docs: hwmon: sy7636a: fix temperature sysfs attribute name
From: Sasha Levin @ 2026-05-20 11:18 UTC (permalink / raw)
To: patches, stable
Cc: Chen-Shi-Hong, Guenter Roeck, Sasha Levin, corbet, linux-hwmon,
linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: Chen-Shi-Hong <eric039eric@gmail.com>
[ Upstream commit 51f57607e30bee282a1d40845f89a311cbb26481 ]
The hwmon sysfs naming convention uses
temp[1-*]_input for temperature channels.
Documentation/hwmon/sy7636a-hwmon.rst currently documents
temp0_input, while the driver uses the standard hwmon
temperature channel interface.
Update the documentation to use temp1_input.
Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
Link: https://lore.kernel.org/r/20260514154108.1937-1-eric039eric@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:
## Phase 1: Commit Message Forensics
Record: Subsystem is `docs: hwmon: sy7636a`. Action verb is `fix`.
Claimed intent is to correct the documented temperature sysfs attribute
name from `temp0_input` to `temp1_input`.
Record: Tags present: `Signed-off-by: Chen-Shi-Hong
<eric039eric@gmail.com>`, `Link:
https://lore.kernel.org/r/20260514154108.1937-1-eric039eric@gmail.com`,
`Signed-off-by: Guenter Roeck <linux@roeck-us.net>`. No `Fixes:`,
`Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`, or `Cc:
stable`.
Record: The commit describes a documentation bug: the sy7636a hwmon
document names `temp0_input`, while hwmon temperature channels are named
`temp[1-*]_input`. No crash, data corruption, or runtime bug is claimed.
Record: This is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.
## Phase 2: Diff Analysis
Record: One file changed: `Documentation/hwmon/sy7636a-hwmon.rst`, 1
insertion and 1 deletion. No functions modified. Scope is a single-file
documentation-only surgical fix.
Record: Before, the document told users to read `temp0_input`. After, it
tells users to read `temp1_input`. No normal/error/init runtime path
changes.
Record: Bug category is documentation/API-description correctness.
Verified against `Documentation/hwmon/sysfs-interface.rst`, which
documents `temp[1-*]_input`, and `drivers/hwmon/hwmon.c`, where
temperature attributes use `temp%d_input` with base index `1`.
Record: Fix quality is obviously correct and minimal. Runtime regression
risk is zero because no code changes.
## Phase 3: Git History Investigation
Record: `git blame` shows `temp0_input` was introduced by
`de34a40532507` when the sy7636a hwmon driver/doc was added. Ancestry
checks show that commit is not in `v5.17` but is in `v5.18`, so the
documentation bug exists from v5.18 onward where the driver exists.
Record: No `Fixes:` tag is present, so there was no Fixes target to
follow.
Record: Related file history on `origin/master`: `51f57607e30be` doc
attribute fix, `2f88425ef590b` regulator-enable leak fix,
`68c2a8b59d231` sensor description doc fix, `80038a758b7fc` alias
addition, `5b5d8ae019543` constification, `a96f688b4e446` underline
warning fix, `de34a40532507` driver addition. This patch is standalone
for trees with the current doc context.
Record: Author history under hwmon/doc paths shows only this commit from
Chen-Shi-Hong in the checked history. Guenter Roeck, the hwmon
maintainer, committed/applied it.
Record: No functional dependencies. For older stable trees that do not
contain `68c2a8b59d231`, the exact patch context differs and needs a
trivial manual backport.
## Phase 4: Mailing List And External Research
Record: `b4 dig -c 51f57607e30be` found the original submission at
`https://patch.msgid.link/20260514154108.1937-1-eric039eric@gmail.com`.
Record: `b4 dig -a` found only v1 of a single-patch series. No newer
unapplied revision found.
Record: `b4 dig -w` showed recipients included Chen-Shi-Hong, Guenter
Roeck, Jonathan Corbet, Shuah Khan, `linux-hwmon`, `linux-doc`, and
`linux-kernel`.
Record: The b4-fetched thread contains Guenter Roeck replying “Applied.”
No NAKs, objections, or stable-specific nomination were found in that
thread. Lore `WebFetch` was blocked by Anubis, but `b4` successfully
retrieved the thread.
## Phase 5: Code Semantic Analysis
Record: No code functions are modified.
Record: Manual code tracing verified the documentation claim:
`drivers/hwmon/sy7636a-hwmon.c` registers `HWMON_CHANNEL_INFO(temp,
HWMON_T_INPUT)`. `drivers/hwmon/hwmon.c` formats temperature attributes
with `temp%d_input`, and `hwmon_attr_base()` returns `1` for temperature
sensors. Therefore the first temperature channel is `temp1_input`.
Record: Callers/callees are not applicable to the patch because it
changes documentation only. The affected “path” is users reading the
hwmon documentation.
Record: Similar pattern check found the generic hwmon documentation and
many hwmon docs use `temp1_input`, supporting the correction.
## Phase 6: Stable Tree Analysis
Record: `v5.15` does not contain `Documentation/hwmon/sy7636a-hwmon.rst`
or `drivers/hwmon/sy7636a-hwmon.c`, so the patch is not applicable
there.
Record: `v6.1`, `v6.6`, and `v6.12` contain the sy7636a driver and the
wrong `temp0_input` documentation. `v7.0` contains the wrong attribute
name with the newer “external NTC” text.
Record: The exact patch applies cleanly to the current
`stable/linux-7.0.y` checkout. It does not apply cleanly to `v6.1` or
`v6.6` because the surrounding description text differs before the later
doc description fix; a trivial one-line context-adjusted backport is
needed there.
Record: No alternate fix for this exact documentation bug was found in
local stable history.
## Phase 7: Subsystem Context
Record: Subsystem is hwmon documentation. Criticality is low for
runtime, but it documents a userspace-visible sysfs ABI path for sy7636a
hardware users.
Record: The sy7636a hwmon files have low churn and only a handful of
targeted fixes since introduction.
## Phase 8: Impact And Risk
Record: Affected population is sy7636a hardware users and anyone writing
scripts or instructions based on
`Documentation/hwmon/sy7636a-hwmon.rst`.
Record: Trigger is reading/following the documentation. If followed
literally, users look for a non-existent `temp0_input` instead of the
actual `temp1_input`.
Record: Failure severity is LOW: documentation/user guidance bug, not a
kernel crash or data corruption issue.
Record: Benefit is modest but real: correct stable documentation for a
userspace-visible hwmon attribute. Risk is effectively zero: one
documentation line, no code, no ABI change.
## Phase 9: Final Synthesis
Evidence for backporting: verified documentation is wrong; verified
driver/core generate `temp1_input`; patch is one-line documentation-
only; hwmon maintainer applied it; documentation fixes are an allowed
stable exception with no runtime regression risk.
Evidence against backporting: it is not a serious runtime bug, security
issue, crash, or data corruption fix. Older stable trees before the
sensor-description doc change need a trivial context adjustment.
Stable rules checklist: obviously correct, yes; fixes a real
documentation bug, yes; important runtime issue, no; small and
contained, yes; no new feature/API, yes; stable applicability, yes for
v7.0 cleanly and older applicable with minor backport adjustment.
Exception category: documentation fix.
Verification:
- [Phase 1] Parsed exact commit `51f57607e30be` from `origin/master` and
confirmed tags/message.
- [Phase 2] Inspected exact diff: one doc line changes `temp0_input` to
`temp1_input`.
- [Phase 3] `git blame` confirmed `temp0_input` came from
`de34a40532507`; ancestry checks place it first in v5.18.
- [Phase 4] `b4 dig` found the original patch; `b4 dig -a` showed v1
only; `b4 dig -w` showed appropriate hwmon/doc recipients; b4 mbox
showed Guenter replied “Applied.”
- [Phase 5] Read sy7636a driver and hwmon core; confirmed first
temperature channel is named `temp1_input`.
- [Phase 6] Checked `v5.15`, `v6.1`, `v6.6`, `v6.12`, and `v7.0`
content; exact patch applies to current 7.0 stable, not directly to
v6.1/v6.6 due context.
- [Phase 8] Confirmed no runtime code changes, so regression risk is
zero.
This should be backported where the sy7636a documentation exists, with
trivial context adjustment for older trees as needed.
**YES**
Documentation/hwmon/sy7636a-hwmon.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst
index 0143ce0e5db76..03d866aba6e81 100644
--- a/Documentation/hwmon/sy7636a-hwmon.rst
+++ b/Documentation/hwmon/sy7636a-hwmon.rst
@@ -22,5 +22,5 @@ The following sensors are supported
sysfs-Interface
---------------
-temp0_input
+temp1_input
- Temperature of external NTC (milli-degree C)
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.6] docs: cgroup-v1: Update charge-commit section
From: Sasha Levin @ 2026-05-20 11:18 UTC (permalink / raw)
To: patches, stable
Cc: T.J. Mercier, Tejun Heo, Sasha Levin, hannes, mkoutny, corbet,
cgroups, linux-doc, linux-kernel
In-Reply-To: <20260520111944.3424570-1-sashal@kernel.org>
From: "T.J. Mercier" <tjmercier@google.com>
[ Upstream commit d8769544bde51b0ac980d10f8fe9f9fed6c95995 ]
Commit 1d8f136a421f ("memcg/hugetlb: remove memcg hugetlb
try-commit-cancel protocol") removed mem_cgroup_commit_charge() and
mem_cgroup_cancel_charge(), but the docs still refer to those functions.
There is no longer any charge cancellation.
Update the docs to match the code.
Signed-off-by: T.J. Mercier <tjmercier@google.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Phase 1: Commit Message Forensics
Step 1.1 Record: subsystem `docs: cgroup-v1`; action verb `Update`;
intent: update `Documentation/admin-guide/cgroup-v1/memcg_test.rst` so
the charge-commit section matches current memcg code.
Step 1.2 Record: tags present: `Signed-off-by: T.J. Mercier
<tjmercier@google.com>` and `Signed-off-by: Tejun Heo <tj@kernel.org>`.
No `Fixes:`, `Reported-by:`, `Tested-by:`, `Reviewed-by:`, `Acked-by:`,
`Link:`, or `Cc: stable@vger.kernel.org` tags in the committed message.
Step 1.3 Record: the body says commit `1d8f136a421f` removed
`mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, while the
cgroup-v1 memcg docs still name them and describe cancellation.
Symptom/failure mode: incorrect documentation only. Version information:
the referenced removal commit is from 2025-01-13 in the local object
database; candidate commit is from 2026-04-30. Root cause: docs were not
updated when the code was changed.
Step 1.4 Record: this is not a hidden runtime bug fix. It is an explicit
documentation correctness fix.
## Phase 2: Diff Analysis
Step 2.1 Record: one file changed: `Documentation/admin-
guide/cgroup-v1/memcg_test.rst`, `2 insertions(+), 4 deletions(-)`. No
functions modified. Scope: single-file documentation-only surgical
change.
Step 2.2 Record: before, the section was titled `charge-commit-cancel`,
listed `mem_cgroup_commit_charge()` or `mem_cgroup_cancel_charge()`, and
described `cancel()`. After, it is titled `charge-commit`, lists
`commit_charge()`, and removes the cancellation text.
Step 2.3 Record: bug category is documentation/comment correctness.
Specific mechanism: removes stale references to APIs that are absent in
current `6.19.y`/`7.0.y` code and in `origin/master`.
Step 2.4 Record: fix quality is obviously correct for trees whose memcg
code no longer has `mem_cgroup_commit_charge()` /
`mem_cgroup_cancel_charge()`. Regression risk is zero runtime risk, but
there is a branch-selection concern: `stable/linux-6.12.y` still
contains those functions, so this exact doc update would be misleading
there.
## Phase 3: Git History Investigation
Step 3.1 Record: `git blame` before the candidate shows the stale doc
lines came from `f3f5edc5e41e` in this repository’s history. `git blame
origin/master` shows the changed lines attributed to `d8769544bde51`.
Step 3.2 Record: no `Fixes:` tag. I still inspected referenced commit
`1d8f136a421f26747e58c01281cba5bffae8d289`; it removed prototypes and
implementations for `mem_cgroup_commit_charge()`,
`mem_cgroup_cancel_charge()`, and related hugetlb try/commit/cancel
helpers.
Step 3.3 Record: recent history for `Documentation/admin-
guide/cgroup-v1/memcg_test.rst` on `origin/master` has only the file
introduction/import commit and this candidate. Related path history
shows the candidate was merged via `cgroup-for-7.1-rc2-fixes`. No
prerequisite doc series found.
Step 3.4 Record: author `T.J. Mercier` has at least one other cgroup-
related commit in `origin/master`; Tejun Heo is listed in `MAINTAINERS`
as cgroup maintainer and committed the patch.
Step 3.5 Record: no code dependencies for the patch itself. It can apply
standalone to the current `stable/linux-7.0.y` checkout. Applicability
must be gated by whether the target tree’s code has removed the old
APIs.
## Phase 4: Mailing List And External Research
Step 4.1 Record: `b4 dig -c d8769544bde51...` found the original
submission at
`https://patch.msgid.link/20260430201142.240387-1-tjmercier@google.com`.
`b4 dig -a` found only v1 of a single-patch series. The mbox contains
Tejun’s reply: “Applied to cgroup/for-7.1-fixes.” No NAKs or concerns
found in the saved thread.
Step 4.2 Record: `b4 dig -w` shows recipients included cgroup
maintainers/list and docs list: `tj@kernel.org`, `hannes@cmpxchg.org`,
`mkoutny@suse.com`, `cgroups@vger.kernel.org`, `corbet@lwn.net`,
`skhan@linuxfoundation.org`, `linux-doc@vger.kernel.org`, `linux-
kernel@vger.kernel.org`.
Step 4.3 Record: no `Reported-by` or bug-report `Link:` tags. No syzbot,
bugzilla, or user-impact bug report applies.
Step 4.4 Record: b4 found a standalone single-patch series, not part of
a multi-patch dependency chain.
Step 4.5 Record: web search did not find stable-list discussion for this
exact patch. `WebFetch` to lore/patch.msgid was blocked by Anubis, but
b4 successfully fetched the mbox.
## Phase 5: Code Semantic Analysis
Step 5.1 Record: no functions modified by the diff.
Step 5.2 Record: no callers affected by the diff. For documentation
accuracy, I verified current `stable/linux-7.0.y` code has
`commit_charge()` callers in `charge_memcg()`,
`mem_cgroup_replace_folio()`, and `mem_cgroup_migrate()`.
Step 5.3 Record: no changed callees. The relevant current code has
`commit_charge()` assigning `folio->memcg_data`, and callers also invoke
`memcg1_commit_charge()` where appropriate.
Step 5.4 Record: runtime reachability is not relevant because no
executable code changes.
Step 5.5 Record: similar stale docs pattern exists in stable branches;
however code state differs by branch. `6.19.y`/`7.0.y` have stale docs
and no old API. `6.12.y` still has `mem_cgroup_commit_charge()` and
`mem_cgroup_cancel_charge()` in code.
## Phase 6: Cross-Referencing And Stable Tree Analysis
Step 6.1 Record: buggy stale documentation exists in
`stable/linux-7.0.y`, `stable/linux-6.19.y`, `stable/linux-6.18.y`,
`stable/linux-6.6.y`, `stable/linux-6.1.y`, `stable/linux-5.15.y`, and
`stable/linux-5.10.y` by exact doc grep. I verified the old APIs are
absent in several of those trees, but `stable/linux-6.12.y` still
contains `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`,
so this exact upstream text is not universally correct for all
maintained stable lines.
Step 6.2 Record: `git apply --check` of the candidate diff succeeds on
the current `stable/linux-7.0.y` checkout. Expected backport difficulty:
clean for trees with matching doc context; branch-specific review needed
for `6.12.y`.
Step 6.3 Record: no related stable fix for this exact doc update found
by local stable branch ancestry checks or web search.
## Phase 7: Subsystem And Maintainer Context
Step 7.1 Record: subsystem is cgroup-v1 memcg documentation.
Criticality: peripheral/runtime-none; important only for documentation
correctness.
Step 7.2 Record: cgroup and memcg areas are active; recent
`origin/master` history includes multiple cgroup/mm fixes. The candidate
was applied by the cgroup maintainer.
## Phase 8: Impact And Risk Assessment
Step 8.1 Record: affected population is documentation readers and
developers/admins consulting old cgroup-v1 memcg internals. No kernel
runtime users are affected.
Step 8.2 Record: trigger condition is reading or relying on the stale
documentation. Unprivileged users cannot trigger a kernel failure
because there is no runtime behavior.
Step 8.3 Record: failure mode is incorrect documentation. Severity: LOW.
It can mislead developers/admins, but it does not fix crash, corruption,
leak, deadlock, or security behavior.
Step 8.4 Record: benefit is low but real for documentation correctness,
especially because the stable rules exception allows
documentation/comment fixes and runtime risk is zero. Risk is very low
for branches whose code matches the new text; risk is documentation-
regression risk if applied to a branch like `6.12.y` where cancellation
APIs still exist.
## Phase 9: Final Synthesis
Step 9.1 Record: evidence for backporting: tiny docs-only patch;
corrects verified stale references in current `7.0.y` and `6.19.y`;
applied by cgroup maintainer; no runtime regression risk; documentation
fixes are allowed. Evidence against: no runtime bug or user-visible
stability issue; not correct for every stable branch, specifically
verified `6.12.y` still has the old commit/cancel APIs. Unresolved: I
did not exhaustively validate every maintained stable branch’s memcg API
state.
Step 9.2 Stable rules checklist:
1. Obviously correct and tested? Yes for matching-code branches;
verified by code grep, `git diff --check`, and `git apply --check` on
`7.0.y`.
2. Fixes a real bug that affects users? It fixes incorrect
documentation, not runtime behavior.
3. Important issue? No runtime severity; LOW documentation correctness
issue.
4. Small and contained? Yes, 6-line docs-only diff in one file.
5. No new features or APIs? Yes.
6. Can apply to stable trees? Yes to at least current `7.0.y`; should
not be applied blindly to `6.12.y`.
Step 9.3 Record: exception category is documentation fix.
Step 9.4 Decision: backport is acceptable for stable trees whose memcg
implementation no longer has charge cancellation APIs. It should be
excluded from trees like `6.12.y` where the old APIs still exist. With
that branch-selection caveat, this qualifies under the documentation-fix
exception.
Verification:
- [Phase 1] Parsed candidate commit
`d8769544bde51b0ac980d10f8fe9f9fed6c95995`: only two Signed-off-by
tags, no bug/report/stable tags.
- [Phase 2] `git show --stat --patch`: confirmed one docs file, `2
insertions(+), 4 deletions(-)`.
- [Phase 3] `git show 1d8f136a421f...`: confirmed referenced commit
removed `mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`
from mainline code.
- [Phase 3] `git log origin/master --grep`: found candidate and merge
via `cgroup-for-7.1-rc2-fixes`.
- [Phase 4] `b4 dig`: found lore thread and exact patch-id match.
- [Phase 4] `b4 dig -a`: only v1 single-patch series.
- [Phase 4] `b4 dig -w`: relevant cgroup and docs maintainers/lists were
included.
- [Phase 4] Saved mbox: confirmed Tejun replied “Applied to
cgroup/for-7.1-fixes”; no NAKs or stable nomination found.
- [Phase 5] `rg`/`git grep`: confirmed current code uses
`commit_charge()` and no longer has old API names in `7.0.y`.
- [Phase 6] `git apply --check`: candidate applies cleanly to current
`7.0.y`.
- [Phase 6] Branch checks: `6.12.y` still has
`mem_cgroup_commit_charge()` and `mem_cgroup_cancel_charge()`, so this
patch must not be applied there unchanged.
- [Phase 8] Runtime impact verified as none because only
`Documentation/admin-guide/cgroup-v1/memcg_test.rst` changes.
**YES**
Documentation/admin-guide/cgroup-v1/memcg_test.rst | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v1/memcg_test.rst b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
index 9f8e27355cba5..7c7cd457cf695 100644
--- a/Documentation/admin-guide/cgroup-v1/memcg_test.rst
+++ b/Documentation/admin-guide/cgroup-v1/memcg_test.rst
@@ -47,21 +47,19 @@ Please note that implementation details can be changed.
Called when swp_entry's refcnt goes down to 0. A charge against swap
disappears.
-3. charge-commit-cancel
+3. charge-commit
=======================
Memcg pages are charged in two steps:
- mem_cgroup_try_charge()
- - mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
+ - commit_charge()
At try_charge(), there are no flags to say "this page is charged".
at this point, usage += PAGE_SIZE.
At commit(), the page is associated with the memcg.
- At cancel(), simply usage -= PAGE_SIZE.
-
Under below explanation, we assume CONFIG_SWAP=y.
4. Anonymous
--
2.53.0
^ permalink raw reply related
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