* Re: [PATCH v7 2/6] mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLE
From: Lance Yang @ 2026-05-14 13:28 UTC (permalink / raw)
To: leitao
Cc: linmiaohe, akpm, david, ljs, vbabka, rppt, surenb, mhocko, shuah,
nao.horiguchi, rostedt, mhiramat, mathieu.desnoyers, corbet,
skhan, liam, linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team, Lance Yang
In-Reply-To: <20260513-ecc_panic-v7-2-be2e578e61da@debian.org>
On Wed, May 13, 2026 at 08:39:33AM -0700, Breno Leitao wrote:
>get_any_page() collapses three different failure modes into a single
>-EIO return:
>
> * the put_page race in the !count_increased path;
> * the HWPoisonHandlable() rejection that bounces out of
> __get_hwpoison_page() with -EBUSY and exhausts shake_page() retries;
> * the HWPoisonHandlable() rejection that goes through the
> count_increased / put_page / shake_page retry loop.
>
>The first is transient (the page is racing with the allocator). The
>second can be either transient (a userspace folio briefly off LRU
>during migration/compaction) or stable (slab/vmalloc/page-table/
>kernel-stack pages). The third describes a stable kernel-owned page
>that the count_increased=true caller already held a reference on.
>
>Distinguish them on the return path: keep -EIO for both the put_page
>race and the -EBUSY-after-retries branch (shake_page() cannot drag a
>folio back from active migration, so we cannot prove the page is
>permanently kernel-owned from there), keep -EBUSY for the allocation
>race (unchanged), and return -ENOTRECOVERABLE only from the
>count_increased-true HWPoisonHandlable() rejection that exhausts its
>retries -- the caller's reference is structural evidence that the
>page is owned by the kernel.
>
>Extend the unhandlable-page pr_err() to fire for either errno and
>update the get_hwpoison_page() kerneldoc.
>
>memory_failure() still folds every negative return into
>MF_MSG_GET_HWPOISON via its existing "else if (res < 0)" branch, so
>this patch is a no-op for users of memory_failure() and only changes
>the errno that soft_offline_page() can propagate to its callers. A
>follow-up wires the new return code through memory_failure() and
>reports MF_MSG_KERNEL for the unrecoverable cases.
>
>Suggested-by: David Hildenbrand <david@kernel.org>
>Signed-off-by: Breno Leitao <leitao@debian.org>
>---
> mm/memory-failure.c | 18 +++++++++++++++---
> 1 file changed, 15 insertions(+), 3 deletions(-)
>
>diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>index 49bcfbd04d213..bae883df3ccb2 100644
>--- a/mm/memory-failure.c
>+++ b/mm/memory-failure.c
>@@ -1408,6 +1408,15 @@ static int get_any_page(struct page *p, unsigned long flags)
> shake_page(p);
> goto try_again;
> }
>+ /*
>+ * Return -EIO rather than -ENOTRECOVERABLE: this
>+ * branch is also reached for pages that are merely
>+ * off-LRU transiently (e.g. a folio in the middle
>+ * of migration or compaction), which shake_page()
>+ * cannot drag back. The caller cannot prove the
>+ * page is permanently kernel-owned from here, so
>+ * keep it on the recoverable errno.
>+ */
> ret = -EIO;
> goto out;
> }
>@@ -1427,10 +1436,10 @@ static int get_any_page(struct page *p, unsigned long flags)
> goto try_again;
> }
> put_page(p);
>- ret = -EIO;
>+ ret = -ENOTRECOVERABLE;
> }
> out:
>- if (ret == -EIO)
>+ if (ret == -EIO || ret == -ENOTRECOVERABLE)
> pr_err("%#lx: unhandlable page.\n", page_to_pfn(p));
>
> return ret;
>@@ -1487,7 +1496,10 @@ static int __get_unpoison_page(struct page *page)
> * -EIO for pages on which we can not handle memory errors,
> * -EBUSY when get_hwpoison_page() has raced with page lifecycle
> * operations like allocation and free,
>- * -EHWPOISON when the page is hwpoisoned and taken off from buddy.
>+ * -EHWPOISON when the page is hwpoisoned and taken off from buddy,
>+ * -ENOTRECOVERABLE for stable kernel-owned pages the handler
>+ * cannot recover (PG_reserved, slab, vmalloc, page tables,
>+ * kernel stacks, and similar non-LRU/non-buddy pages).
Did you test this patch series? I don't see how we ever get to
-ENOTRECOVERABLE there ...
Even with MF_COUNT_INCREASED, the first pass does:
if (flags & MF_COUNT_INCREASED)
count_increased = true;
[...]
if (PageHuge(p) || HWPoisonHandlable(p, flags)) {
ret = 1;
} else {
if (pass++ < GET_PAGE_MAX_RETRY_NUM) { <-
put_page(p);
shake_page(p);
count_increased = false;
goto try_again; <-
}
put_page(p);
ret = -ENOTRECOVERABLE;
}
Then we come back with count_increased=false:
try_again:
if (!count_increased) {
ret = __get_hwpoison_page(p, flags); <-
if (!ret) {
[...]
} else if (ret == -EBUSY) { <-
[...]
ret = -EIO;
goto out; <-
}
}
For slab/vmalloc/page-table pages, __get_hwpoison_page() returns -EBUSY:
if (!HWPoisonHandlable(&folio->page, flags))
return -EBUSY;
so they still seem to end up as -EIO ... Am I missing something?
> */
> static int get_hwpoison_page(struct page *p, unsigned long flags)
> {
>
>--
>2.53.0-Meta
>
>
^ permalink raw reply
* Re: [PATCH] driver core: Add cmdline option to force probe type
From: Jianlin Lv @ 2026-05-14 13:35 UTC (permalink / raw)
To: Greg KH
Cc: corbet, skhan, rafael, dakr, jianlv, linux-kernel, linux-doc,
driver-core
In-Reply-To: <2026051443-exuberant-important-534f@gregkh>
On Thu, May 14, 2026 at 6:16 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, May 14, 2026 at 05:49:55PM +0800, Jianlin Lv wrote:
> > From: Jianlin Lv <iecedge@gmail.com>
> >
> > Device drivers that use asynchronous probing can cause non-deterministic
> > device ordering and naming across reboots. A typical example is storage
> > drivers (like sd/nvme): asynchronous probing can lead to inconsistent disk
> > logical names after reboot. In scenarios where disk naming consistency is
> > critical, the probe type should be set to synchronous.
> >
> > This patch introduces a driver_probe kernel parameter that overrides any
> > driver's hard-coded probe type settings and allows runtime control without
> > requiring kernel recompilation:
> >
> > driver_probe=PROBE_TYPE_SYNC,nvme,sd # Force specific drivers sync
> > driver_probe=PROBE_TYPE_ASYNC,*,usb # Force all async except usb
> > driver_probe=PROBE_TYPE_SYNC,* # Force all drivers synchronous
> >
> > The implementation replaces the limited driver_async_probe parameter with
> > a more flexible interface that can force either synchronous or asynchronous
> > probing as needed.
> >
> > Signed-off-by: Jianlin Lv <iecedge@gmail.com>
> > ---
> > .../admin-guide/kernel-parameters.txt | 27 +++++--
> > drivers/base/dd.c | 71 ++++++++++++++-----
> > 2 files changed, 74 insertions(+), 24 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 4d0f545fb3ec..b43a8bd20356 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -1377,12 +1377,27 @@ Kernel parameters
> > it becomes active and is searched during signature
> > verification.
> >
> > - driver_async_probe= [KNL]
> > - List of driver names to be probed asynchronously. *
> > - matches with all driver names. If * is specified, the
> > - rest of the listed driver names are those that will NOT
> > - match the *.
> > - Format: <driver_name1>,<driver_name2>...
>
> You can not remove an existing user/kernel api, sorry, that is not
> allowed as you just broke all systems that were relying on this :(
>
Could you provide more suggestions on how to improve this patch?
If extend driver_async_probe to implement a 'force synchronous probe'
feature, that doesn’t really match the name driver_async_probe and
may feel ambiguous.
If add a new 'driver_probe' parameter while keeping driver_async_probe,
then their functionality would partially overlap.
Regards,
Jianlin
> thanks,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH] driver core: Add cmdline option to force probe type
From: Greg KH @ 2026-05-14 13:50 UTC (permalink / raw)
To: Jianlin Lv
Cc: corbet, skhan, rafael, dakr, jianlv, linux-kernel, linux-doc,
driver-core
In-Reply-To: <CAFA-uR93Wf2ALpYnnU79kruv7XO=uFePqioaEXNNEfrUtRw2xQ@mail.gmail.com>
On Thu, May 14, 2026 at 09:35:08PM +0800, Jianlin Lv wrote:
> On Thu, May 14, 2026 at 6:16 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Thu, May 14, 2026 at 05:49:55PM +0800, Jianlin Lv wrote:
> > > From: Jianlin Lv <iecedge@gmail.com>
> > >
> > > Device drivers that use asynchronous probing can cause non-deterministic
> > > device ordering and naming across reboots. A typical example is storage
> > > drivers (like sd/nvme): asynchronous probing can lead to inconsistent disk
> > > logical names after reboot. In scenarios where disk naming consistency is
> > > critical, the probe type should be set to synchronous.
> > >
> > > This patch introduces a driver_probe kernel parameter that overrides any
> > > driver's hard-coded probe type settings and allows runtime control without
> > > requiring kernel recompilation:
> > >
> > > driver_probe=PROBE_TYPE_SYNC,nvme,sd # Force specific drivers sync
> > > driver_probe=PROBE_TYPE_ASYNC,*,usb # Force all async except usb
> > > driver_probe=PROBE_TYPE_SYNC,* # Force all drivers synchronous
> > >
> > > The implementation replaces the limited driver_async_probe parameter with
> > > a more flexible interface that can force either synchronous or asynchronous
> > > probing as needed.
> > >
> > > Signed-off-by: Jianlin Lv <iecedge@gmail.com>
> > > ---
> > > .../admin-guide/kernel-parameters.txt | 27 +++++--
> > > drivers/base/dd.c | 71 ++++++++++++++-----
> > > 2 files changed, 74 insertions(+), 24 deletions(-)
> > >
> > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > index 4d0f545fb3ec..b43a8bd20356 100644
> > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > @@ -1377,12 +1377,27 @@ Kernel parameters
> > > it becomes active and is searched during signature
> > > verification.
> > >
> > > - driver_async_probe= [KNL]
> > > - List of driver names to be probed asynchronously. *
> > > - matches with all driver names. If * is specified, the
> > > - rest of the listed driver names are those that will NOT
> > > - match the *.
> > > - Format: <driver_name1>,<driver_name2>...
> >
> > You can not remove an existing user/kernel api, sorry, that is not
> > allowed as you just broke all systems that were relying on this :(
> >
> Could you provide more suggestions on how to improve this patch?
Not really, sorry, I don't think this is a change that should be done at
all. disk naming is a long-solved issue, to think that you can fix that
by doing sync/async device probing is not understanding both the issues
involved, and how we solved it already :)
Hint, never count on block device, or any device, names to be the same
across reboots. That has NEVER been guaranteed on systems built in the
past 20+ years.
Please, just use the existing solutions, no new command line option
should ever be needed here.
thanks,
greg k-h
^ permalink raw reply
* [RFC PATCH v2.1 00/28] mm/damon: introduce data attributes monitoring
From: SeongJae Park @ 2026-05-14 14:08 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Masami Hiramatsu,
Mathieu Desnoyers, Michal Hocko, Mike Rapoport, Shuah Khan,
Shuah Khan, Steven Rostedt, Suren Baghdasaryan, Vlastimil Babka,
damon, linux-doc, linux-kernel, linux-kselftest, linux-mm,
linux-trace-kernel
TL; DR
======
Extend DAMON for monitoring general data attributes other than accesses.
The short term motivation is lightweight page type (e.g., belonging
cgroup) aware monitoring. In long term, this will help extending DAMON
for multiple access events capture primitives (e.g., page faults and
PMU) and eventually pivotting DAMON to a "Data Attributes Monitoring and
Operations eNgine" in long term.
Background: High Cost of Page Level Properties Monitoring
=========================================================
DAMON is initially introduced as a Data Access MONitor. It has been
extended for not only access monitoring but also data access-aware
system operations (DAMOS). But still the monitoring part is only for
data accesses.
Data access patterns is good information, but some users need more
holistic views. Particularly, users want to show the access pattern
information together with the types of the memory. For example, users
who work for making huge pages efficiently want to know how much of
DAMON-found hot/cold regions are backed by huge pages. Users who run
multiple workloads with different cgroups want to know how much of
DAMON-found hot/cold regions belong to specific cgroups.
For the user demand, we developed a DAMOS extension for page level
properties based monitoring [1], which has landed on 6.14. Using the
feature, users can inform the page level data properties that they are
interested in, in a flexible format that uses DAMOS filters. Then,
DAMON applies the filters to each folio of the entire DAMON region and
lets users know how many bytes of memory in each DAMON region passed the
given filters.
This gives page level detailed and deterministic information to users.
But, because the operation is done at page level, the overhead is
proportional to the memory size. It was useful for test or debugging
purposes on a small number of machines. But it was obviously too heavy
to be enabled always on all machines running the real user workloads.
For real world workloads, it was recommended to use the feature with
user-space controlled sampling approaches. For example, users could do
the page level monitoring only once per hour, on randomly selected one
percent of machines of their fleet. If the runtime and the size of the
fleet is long and big enough, it should provide statistically meaningful
data.
But users are too busy to implement such controls on their own.
Data Attributes Monitoring
==========================
Extend DAMON to monitor not only data accesses, but also general data
attributes. Do the extension while keeping the main promise of DAMON,
the bounded and best-effort minimum overhead.
Allow users to specify what data attributes in addition to the data
access they want to monitor. Users can install one 'data probe' per
data attribute of their interest for this purpose. The 'data probe'
should be able to be applied to any memory, and determine if the given
memory has the appropriate data attribute. E.g., if memory of physical
address 42 belongs to cgroup A. Each 'data probe' is configured with
filters that are very similar to the DAMOS filters.
When DAMON checks if each sampling address memory of each region is
accessed since the last check, it applies data probes if registered.
Same to the number of access check-positive samples accounting
(nr_accesses), it accounts the number of each data probe-positive
samples in another per-region counters array, namely 'probe_hits'. When
DAMON resets nr_accesses every aggregation interval, it resets
'probe_hits' together.
Users can read 'probe_hits' just before the values are reset. In this
way, users can know how many hot/cold memory regions have data
attributes of their interest. E.g., 30 percent of this system's hot
memory is belonging to cgroup A, and 80 percent of the cgroup
A-belonging hot memory is backed by huge pages.
Patches Sequence
================
First eight patches implement the core feature, interface and the
working support. Patch 1 introduces data probe data structure, namely
damon_probe. Patch 2 extends damon_ctx for installing data probes.
Patch 3 introduces another data structure for filters of each data
probe, namely damon_filter. Patch 4 updates damon_ctx commit function
to handle the probes. Patch 5 extends damon_region for the per-region
per-probe positive samples counter, namely probe_hits. Patch 6 extends
damon_operations for applying probes on the underlying DAMON operations
implementation. Patch 7 updates kdamond_fn() to invoke the probes
applying callback. Patch 8 finally implements the probes support on
paddr ops.
Ten changes for user interface (patches 9-18) come next. Patches 9-13
implements sysfs directories and files for setting data probes, namely
probes directory, probe directory, filters directory, filter directory
and filter directory internal files, respectively. Patch 14 connects
the user inputs that are made via the sysfs files to DAMON core.
Following three patches (patches 15-17) implement sysfs directories and
files for showing the probe_hits to users, namely probes directory,
probe directory and hits files, respectively. Patch 18 introduces a new
tracepoint for showing the probe_hits via tracefs.
Patch 19 adds a selftest for the sysfs files.
Patches 20 and 21 documents the design and usage of the new feature,
respectively.
Seven additional patches (patches 22-28) for monitoring belonging memory
cgroup follow. Depending on the feedback, this part might be separated
to another series in future. Patch 22 defines the DAMON filter type for
the new attribute, namely DAMON_FILTER_TYPE_MEMCG. Patch 23 add the
support on paddr ops. Patch 24 updates the sysfs interface for setup of
the target memcg. Patch 25 move code for easy reuse of the filter
target memcg setup. Patch 26 connects the user input to the core layer.
Finally, patches 27 and 28 update the design and usage documents for the
memcg attribute monitoring support.
Discussions
===========
This allows the page properties monitoring with overhead that is low
enough to be enabled always on real world workloads. Because the
sampling time for access check is reused for data attributes check, the
upper-bounded and best-effort minimum overhead of DAMON is kept.
Because the sampling memory for access check is reused for data
attributes check, additional overhead is minimum.
Still DAMOS-based page level properties monitoring should be useful,
because it provides a deterministic page level information. When in
doubt of the sampling based information, running DAMOS-based one
together and comparing the results would be useful, for debugging and
tuning.
Plan for Dropping RFC tag
=========================
I'm considering renaming the tracepoint for exposing probe_hits
(damon_aggregated_v2).
Making changes for feedback from myself, humans and Sashiko should be
the major remaining work.
I'm currently hoping to drop the RFC tag by 7.2-rc1.
Future Works: Mid Term
========================
This version of implementation is limiting the maximum number of data
probes to four. I will try to find a way to remove the limit in future.
I personally think it should be enough for common use cases, though, and
therefore not giving high priority at the moment.
Future Works: Long Term
=======================
There are user requests for extending DAMON with detailed access
information, for example, per-CPUs/threads/read/writes monitoring. For
that, I was working [2] on extending DAMON to use page fault events as
another access check primitives, and making the infrastructure flexible
for future use of yet another access check primitive. Actually there is
another ongoing work [3] for extending DAMON with PMU events. The
motivation of the work is reducing the overhead, though.
In my work [2], I was introducing a new interface for access sampling
primitives control. Now I think this data probe interface can be used
for that, too. That is, data access becomes just one type of data
attribute. Also, pg_idle-confirmed access, page fault-confirmed access,
and PMU event-confirmed access will be different types of data
attributes.
The regions adjustment mechanism is currently working based on the
access information. That's because DAMON is designed for data access
monitoring. That is, data access information is the primary interest,
and therefore DAMON adjusts regions in a way that can best-present the
information.
Once data access becomes just one of data attributes, there is no reason
to think data access that special. There might be some users not
interested in access at all but want to know the location of memory of
specific type. Data probes interface will allow doing that. Further,
we could extend the interface to let users set any data attribute as the
'primary' attribute. Then, DAMON will split and merge regions in a way
that can best-present the 'primary' attributes.
DAMOS will also be extended, to specify targets based on not only the
data access pattern, but all user-registered data attributes. From this
stage, we may be able to call DAMON as a "Data Attributes Monitoring and
Operations eNgine".
[1] https://lore.kernel.org/20250106193401.109161-1-sj@kernel.org
[2] https://lore.kernel.org/20251208062943.68824-1-sj@kernel.org/
[3] https://lore.kernel.org/20260423004211.7037-1-akinobu.mita@gmail.com
Changes from RFC v2
- rfc v2: https://lore.kernel.org/20260512143645.113201-1-sj@kernel.org
- Optimize nr_probes calculation for probe_hits tracepoint.
- Use TRACE_EVENT_CONDITION() for probe_hits tracepoint.
- Rebase to latest mm-new.
Changes from RFC
- rfc: https://lore.kernel.org/all/20260426205222.93895-1-sj@kernel.org/
- Support memcg DAMON filter.
- Use per-probe probe_hits sysfs file.
- Use dynamic_array for probe_hits tracing.
- Fix filter matching field.
- Fix folio leaking in damon_pa_filter_pass().
- Move nr_regions of damon_aggregated_v2 tracepoint after end.
- Rename DAMON_TEST_TYPE_ANON to DAMON_FILTER_TYPE_ANON.
SeongJae Park (28):
mm/damon/core: introduce struct damon_probe
mm/damon/core: embed damon_probe objects in damon_ctx
mm/damon/core: introduce damon_filter
mm/damon/core: commit probes
mm/damon/core: introduce damon_region->probe_hits
mm/damon/core: introduce damon_ops->apply_probes
mm/damon/core: do data attributes monitoring
mm/damon/paddr: support data attributes monitoring
mm/damon/sysfs: implement probes dir
mm/damon/sysfs: implement probe dir
mm/damon/sysfs: implement filters directory
mm/damon/sysfs: implement filter dir
mm/damon/sysfs: implement filter dir files
mm/damon/sysfs: setup probes on DAMON core API parameters
mm/damon/sysfs-schemes: implement tried_regions/<r>/probes/
mm/damon/sysfs-schemes: implement probe dir
mm/damon/sysfs-schemes: implement probe/hits file
mm/damon: trace probe_hits
selftests/damon/sysfs.sh: test probes dir
Docs/mm/damon/design: document data attributes monitoring
Docs/admin-guide/mm/damon/usage: document data attributes monitoring
mm/damon/core: introduce DAMON_FILTER_TYPE_MEMCG
mm/damon/paddr: support DAMON_FILTER_TYPE_MEMCG
mm/damon/sysfs: add filters/<F>/path file
mm/damon/sysfs-schemes: move memcg_path_to_id() to sysfs-common
mm/damon/sysfs: setup damon_filter->memcg_id from path
Docs/mm/damon/design: update for memcg damon filter
Docs/admin-guide/mm/damon/usage: update for memcg damon filter
Documentation/admin-guide/mm/damon/usage.rst | 48 +-
Documentation/mm/damon/design.rst | 39 ++
include/linux/damon.h | 67 +++
include/trace/events/damon.h | 38 ++
mm/damon/core.c | 197 +++++++
mm/damon/paddr.c | 76 +++
mm/damon/sysfs-common.c | 41 ++
mm/damon/sysfs-common.h | 2 +
mm/damon/sysfs-schemes.c | 222 ++++++--
mm/damon/sysfs.c | 557 +++++++++++++++++++
tools/testing/selftests/damon/sysfs.sh | 48 ++
11 files changed, 1284 insertions(+), 51 deletions(-)
base-commit: 678b6bc7ce120b8c51d4e05fcb8eb0a92f9be3f6
--
2.47.3
^ permalink raw reply
* [RFC PATCH v2.1 20/28] Docs/mm/damon/design: document data attributes monitoring
From: SeongJae Park @ 2026-05-14 14:08 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260514140904.119781-1-sj@kernel.org>
Update DAMON design document for newly added data attributes monitoring
feature.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/mm/damon/design.rst | 37 +++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index fa7392b5a331d..6731c3102d0ff 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -276,6 +276,43 @@ interval``, DAMON checks if the region's size and access frequency
(``nr_accesses``) has significantly changed. If so, the counter is reset to
zero. Otherwise, the counter is increased.
+Data Attributes Monitoring
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Data access pattern is only one type of data attributes. In some use cases,
+users need to know more data attributes information. For example, users may
+need to know how much of a given hot or cold memory region is backed by
+anonymous pages, or belong to a specific cgroup. For such use case, data
+attributes monitoring feature is provided.
+
+Using the feature, users can register data attributes of their interest to the
+DAMON :ref:`context <damon_design_execution_model_and_data_structures>`. The
+registration is made by specifying a probe per attribute. Each of the probe
+specifies a rule to determine if a given memory region has the related
+attribute. The rule is constructed with multiple filters. The filters work
+same to :ref:`DAMOS filters <damon_design_damos_filters>` except the supported
+filter types. Currently only ``anon`` filter type is supported for data
+attributes monitoring.
+
+If such probes are registered, DAMON executes the probes for each region's
+sampling memory when it does the access :ref:`sampling
+<damon_design_region_based_sampling>`. The number of samples that identified
+as having the data attribute (hitting the probe) per :ref:`aggregation interval
+<damon_design_monitoring>` is accounted in a per-region per-probe counter.
+Users can therefore know how much of a given DAMON region has a specific data
+attribute by reading the per-region per-probe probe hits counter after each
+aggregation interval.
+
+This is a sampling based mechanism. Hence, it is lightweight but the output
+may include some measurement errors. The output should be used with good
+understanding of statistics.
+
+Another way to do this for higher accuracy is using :ref:`DAMOS filter
+<damon_design_damos_filters>` with ``stat`` :ref:`action
+<damon_design_damos_action>` and ``sz_ops_filter_passed`` :ref:`stat
+<damon_design_damos_stat>`. This approach provides the data attributes
+information in page level. But, because it is operated in page level, the
+overhead is proportional to the size of the memory.
Dynamic Target Space Updates Handling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2.1 21/28] Docs/admin-guide/mm/damon/usage: document data attributes monitoring
From: SeongJae Park @ 2026-05-14 14:08 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260514140904.119781-1-sj@kernel.org>
Update DAMON usage document for the newly added data attributes
monitoring feature.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 46 +++++++++++++++++---
Documentation/mm/damon/design.rst | 2 +
2 files changed, 41 insertions(+), 7 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 11c75a598393c..465bcdf89b182 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -72,6 +72,11 @@ comma (",").
│ │ │ │ │ │ intervals/sample_us,aggr_us,update_us
│ │ │ │ │ │ │ intervals_goal/access_bp,aggrs,min_sample_us,max_sample_us
│ │ │ │ │ │ nr_regions/min,max
+ │ │ │ │ │ │ :ref:`probes <damon_usage_sysfs_probes>`/nr_probes
+ │ │ │ │ │ │ │ 0/filters/nr_filters
+ │ │ │ │ │ │ │ │ │ 0/type,matching,allow
+ │ │ │ │ │ │ │ │ │ ...
+ │ │ │ │ │ │ │ │ ...
│ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets
│ │ │ │ │ │ :ref:`0 <sysfs_target>`/pid_target,obsolete_target
│ │ │ │ │ │ │ :ref:`regions <sysfs_regions>`/nr_regions
@@ -97,7 +102,10 @@ comma (",").
│ │ │ │ │ │ │ │ 0/id,weight
│ │ │ │ │ │ │ :ref:`stats <sysfs_schemes_stats>`/nr_tried,sz_tried,nr_applied,sz_applied,sz_ops_filter_passed,qt_exceeds,nr_snapshots,max_nr_snapshots
│ │ │ │ │ │ │ :ref:`tried_regions <sysfs_schemes_tried_regions>`/total_bytes
- │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed
+ │ │ │ │ │ │ │ │ 0/start,end,nr_accesses,age,sz_filter_passed,
+ │ │ │ │ │ │ │ │ │ probes
+ │ │ │ │ │ │ │ │ │ │ 0/hits
+ │ │ │ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
│ │ │ │ ...
@@ -227,8 +235,8 @@ contexts/<N>/monitoring_attrs/
Files for specifying attributes of the monitoring including required quality
and efficiency of the monitoring are in ``monitoring_attrs`` directory.
-Specifically, two directories, ``intervals`` and ``nr_regions`` exist in this
-directory.
+Specifically, two directories, ``intervals``, ``nr_regions`` and ``probes``
+exist in this directory.
Under ``intervals`` directory, three files for DAMON's sampling interval
(``sample_us``), aggregation interval (``aggr_us``), and update interval
@@ -262,6 +270,27 @@ tuning-applied current values of the two intervals can be read from the
``sample_us`` and ``aggr_us`` files after writing ``update_tuned_intervals`` to
the ``state`` file.
+.. _damon_usage_sysfs_probes:
+
+contexts/<N>/monitoring_attrs/probes/
+-------------------------------------
+
+A directory for registering :ref:`data attributes monitoring
+<damon_design_data_attrs_monitoring>` probes.
+
+In the beginning, this directory has only one file, ``nr_probes``. Writing a
+number (``N``) to the file creates the number of child directories named ``0``
+to ``N-1``. Each directory represents each monitoring probe.
+
+In each probe directory, one directory, ``filters`` exist. The directory
+contains files for installingt filters for the probe, that is used to determine
+the data attribute for the probe.
+
+In the beginning, ``filters`` directory has only one file, ``nr_filters``.
+Writing a number (``N``) to the file creates the number of child directories
+named ``0`` to ``N-1``. Each directory represents each filter and work in a
+way similar to that for :ref:`DAMOS filter <sysfs_filters>`.
+
.. _sysfs_targets:
contexts/<N>/targets/
@@ -614,10 +643,13 @@ set the ``access pattern`` as their interested pattern that they want to query.
tried_regions/<N>/
------------------
-In each region directory, you will find five files (``start``, ``end``,
-``nr_accesses``, ``age``, and ``sz_filter_passed``). Reading the files will
-show the properties of the region that corresponding DAMON-based operation
-scheme ``action`` has tried to be applied.
+In each region directory, you will find six files (``start``, ``end``,
+``nr_accesses``, ``age``, ``sz_filter_passed`` and ``probe_hits``). Reading
+the files will show the properties of the region that corresponding DAMON-based
+operation scheme ``action`` has tried to be applied.
+
+Reading ``probe_hists`` shows the number of data attributes monitoring
+probe-hit positive samples of the region.
Example
~~~~~~~
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 6731c3102d0ff..887b45cbeb716 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -276,6 +276,8 @@ interval``, DAMON checks if the region's size and access frequency
(``nr_accesses``) has significantly changed. If so, the counter is reset to
zero. Otherwise, the counter is increased.
+.. _damon_design_data_attrs_monitoring:
+
Data Attributes Monitoring
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2.1 27/28] Docs/mm/damon/design: update for memcg damon filter
From: SeongJae Park @ 2026-05-14 14:09 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260514140904.119781-1-sj@kernel.org>
Update DAMON design document for the newly added belonging memory cgroup
attribute monitoring feature.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/mm/damon/design.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/mm/damon/design.rst b/Documentation/mm/damon/design.rst
index 887b45cbeb716..a24f9f00d1837 100644
--- a/Documentation/mm/damon/design.rst
+++ b/Documentation/mm/damon/design.rst
@@ -293,8 +293,8 @@ registration is made by specifying a probe per attribute. Each of the probe
specifies a rule to determine if a given memory region has the related
attribute. The rule is constructed with multiple filters. The filters work
same to :ref:`DAMOS filters <damon_design_damos_filters>` except the supported
-filter types. Currently only ``anon`` filter type is supported for data
-attributes monitoring.
+filter types. Currently only ``anon`` and ``memcg`` filter types are supported
+for data attributes monitoring.
If such probes are registered, DAMON executes the probes for each region's
sampling memory when it does the access :ref:`sampling
--
2.47.3
^ permalink raw reply related
* [RFC PATCH v2.1 28/28] Docs/admin-guide/mm/damon/usage: update for memcg damon filter
From: SeongJae Park @ 2026-05-14 14:09 UTC (permalink / raw)
Cc: SeongJae Park, Liam R. Howlett, Andrew Morton, David Hildenbrand,
Jonathan Corbet, Lorenzo Stoakes, Michal Hocko, Mike Rapoport,
Shuah Khan, Suren Baghdasaryan, Vlastimil Babka, damon, linux-doc,
linux-kernel, linux-mm
In-Reply-To: <20260514140904.119781-1-sj@kernel.org>
Update DAMON usage document for the newly added belonging memory cgroup
attribute monitoring feature.
Signed-off-by: SeongJae Park <sj@kernel.org>
---
Documentation/admin-guide/mm/damon/usage.rst | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst
index 465bcdf89b182..84741b4cd1877 100644
--- a/Documentation/admin-guide/mm/damon/usage.rst
+++ b/Documentation/admin-guide/mm/damon/usage.rst
@@ -74,7 +74,7 @@ comma (",").
│ │ │ │ │ │ nr_regions/min,max
│ │ │ │ │ │ :ref:`probes <damon_usage_sysfs_probes>`/nr_probes
│ │ │ │ │ │ │ 0/filters/nr_filters
- │ │ │ │ │ │ │ │ │ 0/type,matching,allow
+ │ │ │ │ │ │ │ │ │ 0/type,matching,allow,path
│ │ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ :ref:`targets <sysfs_targets>`/nr_targets
@@ -289,7 +289,9 @@ the data attribute for the probe.
In the beginning, ``filters`` directory has only one file, ``nr_filters``.
Writing a number (``N``) to the file creates the number of child directories
named ``0`` to ``N-1``. Each directory represents each filter and work in a
-way similar to that for :ref:`DAMOS filter <sysfs_filters>`.
+way similar to that for :ref:`DAMOS filter <sysfs_filters>`. When the filter
+``type`` is ``memcg``, ``path`` file works the role of ``memcg_path`` for
+:ref:`DAMOS filter <sysfs_filters>`.
.. _sysfs_targets:
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] killswitch: add per-function short-circuit mitigation primitive
From: Jiri Olsa @ 2026-05-14 14:35 UTC (permalink / raw)
To: Sasha Levin
Cc: Michal Hocko, Breno Leitao, Andrew Morton, corbet, skhan,
linux-doc, linux-kernel, linux-kselftest, gregkh, akinobu.mita,
live-patching
In-Reply-To: <agIbaeBQAr-RkqYc@laps>
On Mon, May 11, 2026 at 02:09:45PM -0400, Sasha Levin wrote:
SNIP
> > > Even if I'm okay with rebooting that often (and I really really would prefer
> > > not to), this doesn't solve the issues of a larger fleet of servers that can't
> > > just reboot that often.
> > >
> > > What am I missing?
> >
> > For one, you are missing more maintainers of code modification infrastructures.
>
> Happy to add more, but I don't want to be too spammy. I'll add in the
> livepatching ML and the fault injection maintainer (I couldn't find a list).
> Please add any other folks/lists who you think might want to contribute to this
> discussion.
hi,
could you please add bpf (bpf@vger.kernel.org) to the loop?
thanks,
jirka
^ permalink raw reply
* Re: [PATCH 09/12] swap: push down setting sis->bdev into ->swap_activate
From: Darrick J. Wong @ 2026-05-14 14:37 UTC (permalink / raw)
To: Damien Le Moal
Cc: Christoph Hellwig, Andrew Morton, Chris Li, Kairui Song,
Christian Brauner, Jens Axboe, David Sterba, Theodore Ts'o,
Jaegeuk Kim, Chao Yu, Trond Myklebust, Anna Schumaker,
Namjae Jeon, Hyunchul Lee, Steve French, Paulo Alcantara,
Carlos Maiolino, Naohiro Aota, linux-xfs, linux-fsdevel,
linux-doc, linux-mm, linux-block, linux-btrfs, linux-ext4,
linux-f2fs-devel, linux-nfs, linux-cifs
In-Reply-To: <b37ca8a7-289e-45a0-8cbd-eb14d7453b97@kernel.org>
On Wed, May 13, 2026 at 04:58:37PM +0900, Damien Le Moal wrote:
> On 5/13/26 16:46, Christoph Hellwig wrote:
> > On Wed, May 13, 2026 at 04:44:53PM +0900, Damien Le Moal wrote:
> >> Hmmm... With zonefs, swap files can be created on top of conventional zone
> >> files. So enforcing "no swap on zoned device" here would break that.
> >
> > We can check that none of the extents fall onto sequential zones instead
> > of just devices.
> >
> > I still wonder why you bother with swap to zonefs at all, though.
>
> Yeah. I do not think anyone actually use that... But since it is there from the
> start, kind of stuck with it now.
Ahh, right, I forgot that zoned devices can have conventional zones
where swap would actually work. Question withdrawn.
--D
^ permalink raw reply
* Re: [PATCH v7 2/6] mm/memory-failure: surface unhandlable kernel pages as -ENOTRECOVERABLE
From: Breno Leitao @ 2026-05-14 14:37 UTC (permalink / raw)
To: Lance Yang
Cc: linmiaohe, akpm, david, ljs, vbabka, rppt, surenb, mhocko, shuah,
nao.horiguchi, rostedt, mhiramat, mathieu.desnoyers, corbet,
skhan, liam, linux-mm, linux-kernel, linux-doc, linux-kselftest,
linux-trace-kernel, kernel-team
In-Reply-To: <20260514132830.25622-1-lance.yang@linux.dev>
On Thu, May 14, 2026 at 09:28:30PM +0800, Lance Yang wrote:
>
> On Wed, May 13, 2026 at 08:39:33AM -0700, Breno Leitao wrote:
> >get_any_page() collapses three different failure modes into a single
> >-EIO return:
> >
> > * the put_page race in the !count_increased path;
> > * the HWPoisonHandlable() rejection that bounces out of
> > __get_hwpoison_page() with -EBUSY and exhausts shake_page() retries;
> > * the HWPoisonHandlable() rejection that goes through the
> > count_increased / put_page / shake_page retry loop.
> >
> >The first is transient (the page is racing with the allocator). The
> >second can be either transient (a userspace folio briefly off LRU
> >during migration/compaction) or stable (slab/vmalloc/page-table/
> >kernel-stack pages). The third describes a stable kernel-owned page
> >that the count_increased=true caller already held a reference on.
> >
> >Distinguish them on the return path: keep -EIO for both the put_page
> >race and the -EBUSY-after-retries branch (shake_page() cannot drag a
> >folio back from active migration, so we cannot prove the page is
> >permanently kernel-owned from there), keep -EBUSY for the allocation
> >race (unchanged), and return -ENOTRECOVERABLE only from the
> >count_increased-true HWPoisonHandlable() rejection that exhausts its
> >retries -- the caller's reference is structural evidence that the
> >page is owned by the kernel.
> >
> >Extend the unhandlable-page pr_err() to fire for either errno and
> >update the get_hwpoison_page() kerneldoc.
> >
> >memory_failure() still folds every negative return into
> >MF_MSG_GET_HWPOISON via its existing "else if (res < 0)" branch, so
> >this patch is a no-op for users of memory_failure() and only changes
> >the errno that soft_offline_page() can propagate to its callers. A
> >follow-up wires the new return code through memory_failure() and
> >reports MF_MSG_KERNEL for the unrecoverable cases.
> >
> >Suggested-by: David Hildenbrand <david@kernel.org>
> >Signed-off-by: Breno Leitao <leitao@debian.org>
> >---
> > mm/memory-failure.c | 18 +++++++++++++++---
> > 1 file changed, 15 insertions(+), 3 deletions(-)
> >
> >diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> >index 49bcfbd04d213..bae883df3ccb2 100644
> >--- a/mm/memory-failure.c
> >+++ b/mm/memory-failure.c
> >@@ -1408,6 +1408,15 @@ static int get_any_page(struct page *p, unsigned long flags)
> > shake_page(p);
> > goto try_again;
> > }
> >+ /*
> >+ * Return -EIO rather than -ENOTRECOVERABLE: this
> >+ * branch is also reached for pages that are merely
> >+ * off-LRU transiently (e.g. a folio in the middle
> >+ * of migration or compaction), which shake_page()
> >+ * cannot drag back. The caller cannot prove the
> >+ * page is permanently kernel-owned from here, so
> >+ * keep it on the recoverable errno.
> >+ */
> > ret = -EIO;
> > goto out;
> > }
> >@@ -1427,10 +1436,10 @@ static int get_any_page(struct page *p, unsigned long flags)
> > goto try_again;
> > }
> > put_page(p);
> >- ret = -EIO;
> >+ ret = -ENOTRECOVERABLE;
> > }
> > out:
> >- if (ret == -EIO)
> >+ if (ret == -EIO || ret == -ENOTRECOVERABLE)
> > pr_err("%#lx: unhandlable page.\n", page_to_pfn(p));
> >
> > return ret;
> >@@ -1487,7 +1496,10 @@ static int __get_unpoison_page(struct page *page)
> > * -EIO for pages on which we can not handle memory errors,
> > * -EBUSY when get_hwpoison_page() has raced with page lifecycle
> > * operations like allocation and free,
> >- * -EHWPOISON when the page is hwpoisoned and taken off from buddy.
> >+ * -EHWPOISON when the page is hwpoisoned and taken off from buddy,
> >+ * -ENOTRECOVERABLE for stable kernel-owned pages the handler
> >+ * cannot recover (PG_reserved, slab, vmalloc, page tables,
> >+ * kernel stacks, and similar non-LRU/non-buddy pages).
>
> Did you test this patch series? I don't see how we ever get to
> -ENOTRECOVERABLE there ...
Yes, I did. I am using the following test case:
https://github.com/leitao/linux/commit/cfebe84ddeab5ac34ed456331db980d57e7025dc
# RUN_DESTRUCTIVE=1 tools/testing/selftests/mm/hwpoison-panic.sh
# enabling /proc/sys/vm/panic_on_unrecoverable_memory_failure
# injecting hwpoison at phys 0x2a00000 (Kernel rodata)
# expecting kernel panic: 'Memory failure: <pfn>: unrecoverable page'
[ 501.113256] Memory failure: 0x2a00: recovery action for reserved kernel page: Ignored
[ 501.113956] Kernel panic - not syncing: Memory failure: 0x2a00: unrecoverable page
> Even with MF_COUNT_INCREASED, the first pass does:
>
> if (flags & MF_COUNT_INCREASED)
> count_increased = true;
>
> [...]
>
> if (PageHuge(p) || HWPoisonHandlable(p, flags)) {
> ret = 1;
> } else {
> if (pass++ < GET_PAGE_MAX_RETRY_NUM) { <-
> put_page(p);
> shake_page(p);
> count_increased = false;
> goto try_again; <-
> }
> put_page(p);
> ret = -ENOTRECOVERABLE;
> }
>
> Then we come back with count_increased=false:
>
> try_again:
> if (!count_increased) {
> ret = __get_hwpoison_page(p, flags); <-
> if (!ret) {
> [...]
> } else if (ret == -EBUSY) { <-
> [...]
> ret = -EIO;
> goto out; <-
> }
> }
>
> For slab/vmalloc/page-table pages, __get_hwpoison_page() returns -EBUSY:
>
> if (!HWPoisonHandlable(&folio->page, flags))
> return -EBUSY;
>
> so they still seem to end up as -EIO ... Am I missing something?
You are not, and thanks for catching this. I traced it again and the
-ENOTRECOVERABLE branch is unreachable for slab/vmalloc/page-table pages
exactly as you described. The __get_hwpoison_page() → -EBUSY → shake → retry
loop catches them first and they exit as -EIO.
The selftest I am using (link above) only validated the PageReserved
short-circuit added in patch 3, which lives in memory_failure() and never
reaches get_any_page().
I even thought about this code path, and I was not convinced we should return
-ENOTRECOVERABLE, thus I documented the following (as in this current patch)
@@ -1408,6 +1408,15 @@ static int get_any_page(struct page *p, unsigned long flags)
shake_page(p);
goto try_again;
}
+ /*
+ * Return -EIO rather than -ENOTRECOVERABLE: this
+ * branch is also reached for pages that are merely
+ * off-LRU transiently (e.g. a folio in the middle
+ * of migration or compaction), which shake_page()
+ * cannot drag back. The caller cannot prove the
+ * page is permanently kernel-owned from here, so
+ * keep it on the recoverable errno.
+ */
ret = -EIO;
^ permalink raw reply
* Re: [PATCH] driver core: Add cmdline option to force probe type
From: Jianlin Lv @ 2026-05-14 15:09 UTC (permalink / raw)
To: Greg KH
Cc: corbet, skhan, rafael, dakr, jianlv, linux-kernel, linux-doc,
driver-core
In-Reply-To: <2026051406-corridor-equation-c50e@gregkh>
On Thu, May 14, 2026 at 9:49 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Thu, May 14, 2026 at 09:35:08PM +0800, Jianlin Lv wrote:
> > On Thu, May 14, 2026 at 6:16 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Thu, May 14, 2026 at 05:49:55PM +0800, Jianlin Lv wrote:
> > > > From: Jianlin Lv <iecedge@gmail.com>
> > > >
> > > > Device drivers that use asynchronous probing can cause non-deterministic
> > > > device ordering and naming across reboots. A typical example is storage
> > > > drivers (like sd/nvme): asynchronous probing can lead to inconsistent disk
> > > > logical names after reboot. In scenarios where disk naming consistency is
> > > > critical, the probe type should be set to synchronous.
> > > >
> > > > This patch introduces a driver_probe kernel parameter that overrides any
> > > > driver's hard-coded probe type settings and allows runtime control without
> > > > requiring kernel recompilation:
> > > >
> > > > driver_probe=PROBE_TYPE_SYNC,nvme,sd # Force specific drivers sync
> > > > driver_probe=PROBE_TYPE_ASYNC,*,usb # Force all async except usb
> > > > driver_probe=PROBE_TYPE_SYNC,* # Force all drivers synchronous
> > > >
> > > > The implementation replaces the limited driver_async_probe parameter with
> > > > a more flexible interface that can force either synchronous or asynchronous
> > > > probing as needed.
> > > >
> > > > Signed-off-by: Jianlin Lv <iecedge@gmail.com>
> > > > ---
> > > > .../admin-guide/kernel-parameters.txt | 27 +++++--
> > > > drivers/base/dd.c | 71 ++++++++++++++-----
> > > > 2 files changed, 74 insertions(+), 24 deletions(-)
> > > >
> > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > > > index 4d0f545fb3ec..b43a8bd20356 100644
> > > > --- a/Documentation/admin-guide/kernel-parameters.txt
> > > > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > > > @@ -1377,12 +1377,27 @@ Kernel parameters
> > > > it becomes active and is searched during signature
> > > > verification.
> > > >
> > > > - driver_async_probe= [KNL]
> > > > - List of driver names to be probed asynchronously. *
> > > > - matches with all driver names. If * is specified, the
> > > > - rest of the listed driver names are those that will NOT
> > > > - match the *.
> > > > - Format: <driver_name1>,<driver_name2>...
> > >
> > > You can not remove an existing user/kernel api, sorry, that is not
> > > allowed as you just broke all systems that were relying on this :(
> > >
> > Could you provide more suggestions on how to improve this patch?
>
> Not really, sorry, I don't think this is a change that should be done at
> all. disk naming is a long-solved issue, to think that you can fix that
> by doing sync/async device probing is not understanding both the issues
> involved, and how we solved it already :)
Do you mean referencing disks via by-path/by-id? In our production env
they can also be unstable; this is an example I encountered before:
https://lore.kernel.org/all/CAFA-uR_jk6jCmf9DTebSVBRwtoLuXuyvf1Biq+OObqRVAOZbBw@mail.gmail.com/
I understand that device naming in the kernel can change at any time. However,
Is it necessary to provide an interface that allows users to choose
the probe mode themselves?
Currently, driver_async_probe has lower priority than the drivers’
hard-coded probe_type settings.
Could we adjust the code as follows so that driver_async_probe has the
highest priority?
static bool driver_allows_async_probing(const struct device_driver *drv)
{
+ if (cmdline_requested_async_probing(drv->name))
+ return true;
+
switch (drv->probe_type) {
case PROBE_PREFER_ASYNCHRONOUS:
return true;
@@ -876,9 +879,6 @@ static bool driver_allows_async_probing(const
struct device_driver *drv)
return false;
default:
- if (cmdline_requested_async_probing(drv->name))
- return true;
-
if (module_requested_async_probing(drv->owner))
Jianlin
>
> Hint, never count on block device, or any device, names to be the same
> across reboots. That has NEVER been guaranteed on systems built in the
> past 20+ years.
>
> Please, just use the existing solutions, no new command line option
> should ever be needed here.
>
> thanks,
>
> greg k-h
^ permalink raw reply
* [PATCH] dcache: add fs.dentry-limit sysctl with negative-first reaper
From: Horst Birthelmer @ 2026-05-14 15:13 UTC (permalink / raw)
To: Miklos Szeredi, Jonathan Corbet, Shuah Khan, Alexander Viro,
Christian Brauner, Jan Kara
Cc: linux-doc, linux-kernel, linux-fsdevel, Horst Birthelmer
From: Horst Birthelmer <hbirthelmer@ddn.com>
The dcache only shrinks under memory pressure, which is rarely reached
on machines with ample RAM, so cached negative dentries can accumulate
without bound. Give administrators a soft cap they can set,
and a background worker that prefers negative dentries when reclaiming.
Two new sysctls under /proc/sys/fs/:
dentry-limit -- soft cap on nr_dentry. 0 (default)
disables the feature; behaviour is then
identical to before.
dentry-limit-interval-ms -- pacing for the worker while still over
the cap. Default 1000, minimum 1.
When the cap is exceeded, a delayed_work runs in two phases:
1. iterate_supers() draining only negative dentries from every LRU.
Positive entries are rotated past so the walk makes progress.
DCACHE_REFERENCED is ignored here on purpose -- an admin-imposed
cap should evict even hot negatives before any positive entry.
2. If still over the cap, iterate_supers() again with the same
isolate callback the memory-pressure shrinker uses.
Signed-off-by: Horst Birthelmer <hbirthelmer@ddn.com>
---
There was a discussion at LSFMM about servers with too many cached
negative dentries.
That gave me the idea to keep the dentries in general limited
if the system administrator needs it to.
This is somewhat related to [1] where it would address the same
symptoms but in a more unobtrusive way, by just garbage collecting
the negative and then the unused cache entries.
The other effect I have seen regarding this is that FUSE
will not forget inodes (no FORGET call to the FUSE server)
even after the latest reference has been closed until much later.
In a FUSE server that mirrors the kernel cached inodes in user space
because it has to keep a lot of private data for every node
this puts an unnecessarry memory strain on that userspace entity
especially if the memory is limited for its cgroup.
[1]: https://lore.kernel.org/linux-fsdevel/20260331012925.74840-1-raven@themaw.net/
---
Documentation/admin-guide/sysctl/fs.rst | 28 +++++
fs/dcache.c | 197 ++++++++++++++++++++++++++++++++
2 files changed, 225 insertions(+)
diff --git a/Documentation/admin-guide/sysctl/fs.rst b/Documentation/admin-guide/sysctl/fs.rst
index 9b7f65c3efd8..0229aea45d85 100644
--- a/Documentation/admin-guide/sysctl/fs.rst
+++ b/Documentation/admin-guide/sysctl/fs.rst
@@ -38,6 +38,34 @@ requests. ``aio-max-nr`` allows you to change the maximum value
``aio-max-nr`` does not result in the
pre-allocation or re-sizing of any kernel data structures.
+dentry-limit
+------------
+
+Soft cap on the total number of dentries allocated system-wide (i.e. on
+``nr_dentry`` from ``dentry-state``). A value of ``0`` (the default)
+disables the feature and the dcache grows or shrinks only under memory
+pressure as before.
+
+When set to a non-zero value, a background worker is woken whenever
+the live dentry count exceeds the limit. The worker walks every
+superblock's LRU and prefers to evict negative dentries first; if it
+cannot get back under the limit using negative entries alone it falls
+back to the same LRU policy used by the memory-pressure shrinker.
+
+The limit is *soft*: allocations never fail because of it, and brief
+overshoots while the worker catches up are expected. Set the cap a
+comfortable margin above your steady-state working set.
+
+dentry-limit-interval-ms
+------------------------
+
+How often, in milliseconds, the ``dentry-limit`` worker re-runs while
+``nr_dentry`` is still above the cap. Defaults to ``1000`` (one
+second); the minimum accepted value is ``1``. Smaller values trim the
+cache more aggressively at the cost of more CPU spent walking LRUs;
+larger values let temporary spikes ride out before any work is done.
+Has no effect when ``dentry-limit`` is ``0``.
+
dentry-negative
----------------------------
diff --git a/fs/dcache.c b/fs/dcache.c
index 2c61aeea41f4..4959d2c011c0 100644
--- a/fs/dcache.c
+++ b/fs/dcache.c
@@ -144,6 +144,19 @@ static DEFINE_PER_CPU(long, nr_dentry_unused);
static DEFINE_PER_CPU(long, nr_dentry_negative);
static int dentry_negative_policy;
+/*
+ * Soft cap on the total number of dentries. When non-zero and exceeded,
+ * a background worker prunes unused dentries (preferring negative ones)
+ * until we are back under the limit. Zero (the default) disables the
+ * feature entirely; the fast path in __d_alloc() only pays the cost of
+ * a READ_ONCE and a branch in that case.
+ */
+static unsigned long sysctl_dentry_limit __read_mostly;
+static unsigned int sysctl_dentry_limit_interval_ms __read_mostly = 1000;
+static unsigned long dentry_limit_last_kick;
+
+static void dentry_limit_kick(void);
+
#if defined(CONFIG_SYSCTL) && defined(CONFIG_PROC_FS)
/* Statistics gathering. */
static struct dentry_stat_t dentry_stat = {
@@ -199,6 +212,20 @@ static int proc_nr_dentry(const struct ctl_table *table, int write, void *buffer
return proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
}
+/*
+ * Writing fs.dentry-limit should give prompt feedback to admins
+ * lowering the cap, so kick the worker on every successful write.
+ */
+static int proc_dentry_limit(const struct ctl_table *table, int write,
+ void *buffer, size_t *lenp, loff_t *ppos)
+{
+ int ret = proc_doulongvec_minmax(table, write, buffer, lenp, ppos);
+
+ if (write && !ret)
+ dentry_limit_kick();
+ return ret;
+}
+
static const struct ctl_table fs_dcache_sysctls[] = {
{
.procname = "dentry-state",
@@ -207,6 +234,21 @@ static const struct ctl_table fs_dcache_sysctls[] = {
.mode = 0444,
.proc_handler = proc_nr_dentry,
},
+ {
+ .procname = "dentry-limit",
+ .data = &sysctl_dentry_limit,
+ .maxlen = sizeof(sysctl_dentry_limit),
+ .mode = 0644,
+ .proc_handler = proc_dentry_limit,
+ },
+ {
+ .procname = "dentry-limit-interval-ms",
+ .data = &sysctl_dentry_limit_interval_ms,
+ .maxlen = sizeof(sysctl_dentry_limit_interval_ms),
+ .mode = 0644,
+ .proc_handler = proc_douintvec_minmax,
+ .extra1 = SYSCTL_ONE,
+ },
{
.procname = "dentry-negative",
.data = &dentry_negative_policy,
@@ -1325,6 +1367,160 @@ static enum lru_status dentry_lru_isolate_shrink(struct list_head *item,
return LRU_REMOVED;
}
+#define DENTRY_LIMIT_BATCH 1024UL
+
+static void dentry_limit_worker_fn(struct work_struct *work);
+static DECLARE_DELAYED_WORK(dentry_limit_work, dentry_limit_worker_fn);
+
+/*
+ * Variant of dentry_lru_isolate() that only frees negative dentries.
+ * DCACHE_REFERENCED is intentionally not honoured here: the whole point
+ * of an admin-imposed cap on negatives is that even frequently-looked-up
+ * negative entries should be evicted before any positive dentry.
+ * Positive entries are rotated to the tail so the walk continues to
+ * make progress without disturbing their LRU position.
+ */
+static enum lru_status dentry_lru_isolate_negative(struct list_head *item,
+ struct list_lru_one *lru, void *arg)
+{
+ struct list_head *freeable = arg;
+ struct dentry *dentry = container_of(item, struct dentry, d_lru);
+
+ if (!spin_trylock(&dentry->d_lock))
+ return LRU_SKIP;
+
+ /* Same handling as dentry_lru_isolate() for in-use entries. */
+ if (dentry->d_lockref.count) {
+ d_lru_isolate(lru, dentry);
+ spin_unlock(&dentry->d_lock);
+ return LRU_REMOVED;
+ }
+
+ if (!d_is_negative(dentry)) {
+ spin_unlock(&dentry->d_lock);
+ return LRU_ROTATE;
+ }
+
+ d_lru_shrink_move(lru, dentry, freeable);
+ spin_unlock(&dentry->d_lock);
+ return LRU_REMOVED;
+}
+
+struct dentry_limit_ctx {
+ long over; /* remaining dentries to evict */
+ list_lru_walk_cb isolate;
+};
+
+static void dentry_limit_prune_sb(struct super_block *sb, void *arg)
+{
+ struct dentry_limit_ctx *ctx = arg;
+ unsigned long walked = 0;
+ unsigned long budget;
+
+ if (ctx->over <= 0)
+ return;
+
+ /*
+ * Walk up to one full pass of this superblock's LRU, in
+ * DENTRY_LIMIT_BATCH-sized chunks. The loop matters mainly for
+ * phase 1: dentry_lru_isolate_negative() returns LRU_ROTATE for
+ * positive dentries, which still counts against list_lru_walk()'s
+ * nr_to_walk. A single batch can therefore finish having freed
+ * nothing when positives crowd the head of the LRU, and without
+ * the inner loop the worker would have to wait a full
+ * dentry-limit-interval-ms before retrying never reaching the
+ * negatives buried behind a long run of positives.
+ *
+ * The budget is snapshot at entry so a filesystem allocating
+ * dentries faster than we drain them can't keep us spinning here
+ * forever; freshly added dentries are picked up on the next
+ * worker invocation.
+ *
+ * Phase 2 normally exits much sooner: its isolate callback frees
+ * any non-referenced dentry, so ctx->over typically hits zero
+ * inside the first batch. The worst-case over-eviction is one
+ * batch past the cap, which is within the soft semantics of
+ * fs.dentry-limit.
+ */
+ budget = list_lru_count(&sb->s_dentry_lru);
+
+ while (ctx->over > 0 && walked < budget) {
+ LIST_HEAD(dispose);
+ unsigned long nr;
+ long freed;
+
+ nr = min(DENTRY_LIMIT_BATCH, budget - walked);
+ freed = list_lru_walk(&sb->s_dentry_lru, ctx->isolate,
+ &dispose, nr);
+ shrink_dentry_list(&dispose);
+
+ ctx->over -= freed;
+ walked += nr;
+
+ cond_resched();
+ }
+}
+
+static void dentry_limit_worker_fn(struct work_struct *work)
+{
+ struct dentry_limit_ctx ctx;
+ unsigned long limit = READ_ONCE(sysctl_dentry_limit);
+ unsigned int ms;
+ long nr;
+
+ if (!limit)
+ return;
+
+ nr = get_nr_dentry();
+ if (nr <= (long)limit)
+ return;
+
+ ctx.over = nr - (long)limit;
+
+ /* Phase 1: drain negative dentries across every superblock. */
+ ctx.isolate = dentry_lru_isolate_negative;
+ iterate_supers(dentry_limit_prune_sb, &ctx);
+
+ /* Phase 2: still over? Apply the ordinary LRU policy. */
+ if (ctx.over > 0) {
+ ctx.isolate = dentry_lru_isolate;
+ iterate_supers(dentry_limit_prune_sb, &ctx);
+ }
+
+ /*
+ * Re-arm while still above the limit. Re-read the sysctls in
+ * case the admin raised the cap or disabled the feature during
+ * the walk.
+ */
+ limit = READ_ONCE(sysctl_dentry_limit);
+ if (!limit || get_nr_dentry() <= (long)limit)
+ return;
+
+ ms = READ_ONCE(sysctl_dentry_limit_interval_ms);
+ queue_delayed_work(system_unbound_wq, &dentry_limit_work,
+ msecs_to_jiffies(ms));
+}
+
+static void dentry_limit_kick(void)
+{
+ unsigned long limit = READ_ONCE(sysctl_dentry_limit);
+ unsigned long now;
+
+ if (!limit)
+ return;
+ if (delayed_work_pending(&dentry_limit_work))
+ return;
+
+ now = jiffies;
+ if (time_before(now, READ_ONCE(dentry_limit_last_kick) + HZ / 10))
+ return;
+ WRITE_ONCE(dentry_limit_last_kick, now);
+
+ if (get_nr_dentry() <= (long)limit)
+ return;
+
+ queue_delayed_work(system_unbound_wq, &dentry_limit_work, 0);
+}
/**
* shrink_dcache_sb - shrink dcache for a superblock
@@ -1868,6 +2064,7 @@ static struct dentry *__d_alloc(struct super_block *sb, const struct qstr *name)
}
this_cpu_inc(nr_dentry);
+ dentry_limit_kick();
return dentry;
}
---
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
change-id: 20260513-limit-dentries-cache-63685729672b
Best regards,
--
Horst Birthelmer <hbirthelmer@ddn.com>
^ permalink raw reply related
* Re: [PATCH v4 02/16] vfio/pci: Preserve vfio-pci device files across Live Update
From: Pratyush Yadav @ 2026-05-14 15:24 UTC (permalink / raw)
To: Samiullah Khawaja
Cc: Vipin Sharma, David Matlack, kvm, linux-doc, linux-kernel,
linux-kselftest, linux-pci, ajayachandra, alex, amastro, ankita,
apopple, chrisl, corbet, graf, jacob.pan, jgg, jgg, jrhilke,
julianr, kevin.tian, leon, leonro, lukas, michal.winiarski, parav,
pasha.tatashin, praan, pratyush, rananta, rientjes, rodrigo.vivi,
rppt, saeedm, skhan, vivek.kasireddy, witu, yanjun.zhu, yi.l.liu
In-Reply-To: <agT9bYpXskVwW0E_@google.com>
On Wed, May 13 2026, Samiullah Khawaja wrote:
> On Tue, May 12, 2026 at 02:29:19PM -0700, Vipin Sharma wrote:
>>On Tue, May 12, 2026 at 01:59:51PM -0700, David Matlack wrote:
>>> On Mon, May 11, 2026 at 4:48 PM Vipin Sharma <vipinsh@google.com> wrote:
>>>
>>> > diff --git a/drivers/vfio/pci/Kconfig b/drivers/vfio/pci/Kconfig
>>> > index c12d614fc6c4..019de053f116 100644
>>> > --- a/drivers/vfio/pci/Kconfig
>>> > +++ b/drivers/vfio/pci/Kconfig
>>> > @@ -45,13 +45,15 @@ config VFIO_PCI_IGD
>>> >
>>> > config VFIO_PCI_LIVEUPDATE
>>> > bool "VFIO PCI support for Live Update (EXPERIMENTAL)"
>>> > - depends on PCI_LIVEUPDATE
>>> > + depends on PCI_LIVEUPDATE && VFIO_DEVICE_CDEV
>>> > help
>>> > Support for preserving devices bound to vfio-pci across a Live
>>> > Update. This option should only be enabled by developers working on
>>> > implementing this support. Once enough support has landed in the
>>> > kernel, this option will no longer be marked EXPERIMENTAL.
>>> >
>>> > + Enabling this will disable support for VFIO PCI DMA buffer.
>>> > +
>>> > If you don't know what to do here, say N.
>>> >
>>> > endif
>>> > @@ -68,7 +70,7 @@ config VFIO_PCI_ZDEV_KVM
>>> > To enable s390x KVM vfio-pci extensions, say Y.
>>> >
>>> > config VFIO_PCI_DMABUF
>>> > - def_bool y if VFIO_PCI_CORE && PCI_P2PDMA && DMA_SHARED_BUFFER
>>> > + def_bool y if VFIO_PCI_CORE && PCI_P2PDMA && DMA_SHARED_BUFFER && !VFIO_PCI_LIVEUPDATE
>>>
>>> Why does enabling VFIO_PCI_LIVEUPDATE require disabling
>>> VFIO_PCI_DMABUF? I saw the cover letter says "to keep things simple",
>>> but what specific problem does this solve or simplify?
>>
>>I should have provided more details there.
>>
>>When device is getting reset in vfio_pci_liveupdate_freeze(), we are
>>zapping userspace mapped bars, we also need to use
>>vfio_pci_dma_buf_move() to revoke dma buffer access or
>>vfio_pci_dma_buf_cleanup() combination. Cleanup takes the memory lock
>>which freeze already takes, and there are some refcounts which are
>>managed in both of these APIs. This was causing complexities with code
>>flow based on result of pci_load_saved_state(). All this was adding more
>>refactoring than I wanted in the series.
>
> Maybe we can return -EOPNOTSUPP if any dmabufs for this vfio cdev are
> exported during preserve?
Whichever way you go with, a TODO/comment would be nice to have so
someone (including future you) looking at this code knows why this
restriction exists.
--
Regards,
Pratyush Yadav
^ permalink raw reply
* [PATCH] docs: hwmon: sy7636a: fix temperature sysfs attribute name
From: Chen-Shi-Hong @ 2026-05-14 15:39 UTC (permalink / raw)
To: Guenter Roeck
Cc: Jonathan Corbet, Shuah Khan, linux-hwmon, linux-doc, linux-kernel,
Chen-Shi-Hong
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>
---
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 0143ce0e5db7..03d866aba6e8 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
* Re: [PATCH v11 4/5] platform/chrome: Protect cros_ec_device lifecycle with revocable
From: Jason Gunthorpe @ 2026-05-14 16:00 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Arnd Bergmann, Greg Kroah-Hartman, Bartosz Golaszewski,
Linus Walleij, Benson Leung, linux-kernel, chrome-platform,
driver-core, linux-doc, linux-gpio, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Shuah Khan, Laurent Pinchart,
Wolfram Sang, Johan Hovold, Paul E . McKenney
In-Reply-To: <agVCtBbqT6aZL0mx@google.com>
On Thu, May 14, 2026 at 03:34:12AM +0000, Tzung-Bi Shih wrote:
> To help me understand, could you elaborate on why the revocable mechanism
> isn't suitable here?
Stay within one driver. Create the revokable is probe, consume it
within that drivers fops/etc, destroy it on remove. Do not randomly
pass it to other drivers.
> I'm wondering because if this piece of code were to transition to
> Rust in the future, would the concerns you have also apply to using
> Revocable[1] in the Rust context for this driver?
Yes, even in rust driver local revocable objects should not be
spaghetti coded through different layers.
Jason
^ permalink raw reply
* Re: [PATCH v10 8/9] platform/chrome: Protect cros_ec_device lifecycle with revocable
From: Jason Gunthorpe @ 2026-05-14 16:02 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Arnd Bergmann, Greg Kroah-Hartman, Bartosz Golaszewski,
Linus Walleij, Benson Leung, linux-kernel, chrome-platform,
driver-core, linux-doc, linux-gpio, Rafael J. Wysocki,
Danilo Krummrich, Jonathan Corbet, Shuah Khan, Laurent Pinchart,
Wolfram Sang, Johan Hovold, Paul E . McKenney
In-Reply-To: <agVCoxuTu7l60TH-@google.com>
On Thu, May 14, 2026 at 03:33:55AM +0000, Tzung-Bi Shih wrote:
> > Given you say this is such a bug I think you really should be sending
> > a series that is patches 5 through 7 from the other series and a
> > simple rwsem instead of misc_deregister_sync() to deal with this bug
> > ASAP. No need to complicate a simple bug fix in a driver with all
> > these core changes.
>
> Apologies for missing this suggestion.
>
> For "patches 5 through 7 from the other series" I guess you're referring:
> - https://lore.kernel.org/all/20260427134659.95181-6-tzungbi@kernel.org
> - https://lore.kernel.org/all/20260427134659.95181-7-tzungbi@kernel.org
> - https://lore.kernel.org/all/20260427134659.95181-8-tzungbi@kernel.org
Yes
> Could you provide a bit more detail on the rwsem approach? I'm not
> entirely clear on what data or operations the rwsem would be protecting.
Just put a rwsem, or even scru, inside the driver's fops.
You can refactor that out to a misc or revocable later.
Jason
^ permalink raw reply
* [PATCH v2 0/3] Doc, scripts: facilitate phaseout of strlcat
From: Manuel Ebner @ 2026-05-14 16:07 UTC (permalink / raw)
To: Andy Shevchenko, Kees Cook, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Geert Uytterhoeven, David Laight, Randy Dunlap, Jani Nikula,
Heiko Carstens, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
Cc: Manuel Ebner
Thanks for all the feedback. I tried to incorporate it in this version.
The goal of this series is to facilitate the transition away from strlcat()
[v2]
add recipants
add remarks to strlcat definition in
lib/string.c
tools/include/nolibc/string.h
-> [3/3]
^ permalink raw reply
* [PATCH v2 1/3] Doc: deprecated.rst: add strlcat()
From: Manuel Ebner @ 2026-05-14 16:26 UTC (permalink / raw)
To: Andy Shevchenko, Kees Cook, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Geert Uytterhoeven, David Laight, Randy Dunlap, Jani Nikula,
Heiko Carstens, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
Cc: Manuel Ebner
In-Reply-To: <20260514160719.105084-3-manuelebner@mailbox.org>
add strlcat and alternatives
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/process/deprecated.rst | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index fed56864d036..06e802f4bbfd 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -153,6 +153,13 @@ used, and the destinations should be marked with the `__nonstring
attribute to avoid future compiler warnings. For cases still needing
NUL-padding, strtomem_pad() can be used.
+strlcat()
+---------
+strlcat() must re-scan the destination string from the beginning on each
+call (O(n^2) behavior). Alternatives are seq_buf_puts() and seq_buf_printf().
+snprintf(), scnprintf() and sysfs_emit() are possible aswell, but the adoption
+of the arguments needs to be taken care off.
+
strlcpy()
---------
strlcpy() reads the entire source buffer first (since the return value
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/3] scripts: checkpatch.pl: add warning for strlcat()
From: Manuel Ebner @ 2026-05-14 16:28 UTC (permalink / raw)
To: Andy Shevchenko, Kees Cook, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Geert Uytterhoeven, David Laight, Randy Dunlap, Jani Nikula,
Heiko Carstens, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
Cc: Manuel Ebner
In-Reply-To: <20260514160719.105084-3-manuelebner@mailbox.org>
add a warning for strlcat()
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
scripts/checkpatch.pl | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0492d6afc9a1..4c1b43ebe00d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7085,6 +7085,12 @@ sub process {
"Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
}
+# strlcat uses that should be a more supported function
+ if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
+ WARN("STRLCAT",
+ "Prefer a more supported function over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
+ }
+
# strncpy uses that should likely be strscpy or strscpy_pad
if ($line =~ /\bstrncpy\s*\(/ && !is_userspace($realfile)) {
WARN("STRNCPY",
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] Doc: deprecated.rst: add strlcat()
From: Kees Cook @ 2026-05-14 16:31 UTC (permalink / raw)
To: Manuel Ebner
Cc: Andy Shevchenko, Jonathan Corbet, Shuah Khan, Andy Whitcroft,
Joe Perches, Dwaipayan Ray, Lukas Bulwahn, Geert Uytterhoeven,
David Laight, Randy Dunlap, Jani Nikula, Heiko Carstens,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
In-Reply-To: <20260514162652.107714-2-manuelebner@mailbox.org>
On Thu, May 14, 2026 at 06:26:53PM +0200, Manuel Ebner wrote:
> add strlcat and alternatives
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Documentation/process/deprecated.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index fed56864d036..06e802f4bbfd 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -153,6 +153,13 @@ used, and the destinations should be marked with the `__nonstring
> attribute to avoid future compiler warnings. For cases still needing
> NUL-padding, strtomem_pad() can be used.
>
> +strlcat()
> +---------
> +strlcat() must re-scan the destination string from the beginning on each
> +call (O(n^2) behavior). Alternatives are seq_buf_puts() and seq_buf_printf().
> +snprintf(), scnprintf() and sysfs_emit() are possible aswell, but the adoption
> +of the arguments needs to be taken care off.
> +
How about just:
strlcat() must re-scan the destination string from the beginning on each
call (O(n^2) behavior). Use the seq_buf API or similar instead.
> strlcpy()
> ---------
> strlcpy() reads the entire source buffer first (since the return value
> --
> 2.54.0
>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v2 2/3] scripts: checkpatch.pl: add warning for strlcat()
From: Kees Cook @ 2026-05-14 16:32 UTC (permalink / raw)
To: Manuel Ebner
Cc: Andy Shevchenko, Jonathan Corbet, Shuah Khan, Andy Whitcroft,
Joe Perches, Dwaipayan Ray, Lukas Bulwahn, Geert Uytterhoeven,
David Laight, Randy Dunlap, Jani Nikula, Heiko Carstens,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
In-Reply-To: <20260514162858.107919-2-manuelebner@mailbox.org>
On Thu, May 14, 2026 at 06:28:59PM +0200, Manuel Ebner wrote:
> add a warning for strlcat()
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
Reviewed-by: Kees Cook <kees@kernel.org>
--
Kees Cook
^ permalink raw reply
* [PATCH v2 3/3] drivers: add deprecated remarks to strlcat()
From: Manuel Ebner @ 2026-05-14 16:30 UTC (permalink / raw)
To: Andy Shevchenko, Kees Cook, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Geert Uytterhoeven, David Laight, Randy Dunlap, Jani Nikula,
Heiko Carstens, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
Cc: Manuel Ebner
In-Reply-To: <20260514160719.105084-3-manuelebner@mailbox.org>
add kernel-doc comment to strlcat() function definitions
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
lib/string.c | 11 +++++++++++
tools/include/nolibc/string.h | 11 +++++++++++
2 files changed, 22 insertions(+)
diff --git a/lib/string.c b/lib/string.c
index b632c71df1a5..0a44ca5ca7e6 100644
--- a/lib/string.c
+++ b/lib/string.c
@@ -249,6 +249,17 @@ EXPORT_SYMBOL(strncat);
#endif
#ifndef __HAVE_ARCH_STRLCAT
+/**
+ * strlcat - Append a string to an existing string
+ *
+ * @dest: pointer to %NUL-terminated string to append to
+ * @src: pointer to %NUL-terminated string to append from
+ * @count: Maximum bytes available in @dest
+ *
+ * Do not use this function. Prefer building the string with
+ * formatting, via scnprintf(), seq_buf, or similar.
+ *
+ */
size_t strlcat(char *dest, const char *src, size_t count)
{
size_t dsize = strlen(dest);
diff --git a/tools/include/nolibc/string.h b/tools/include/nolibc/string.h
index 4000926f44ac..1a4b51135705 100644
--- a/tools/include/nolibc/string.h
+++ b/tools/include/nolibc/string.h
@@ -208,6 +208,17 @@ char *strndup(const char *str, size_t maxlen)
}
static __attribute__((unused))
+/**
+ * strlcat - Append a string to an existing string
+ *
+ * @dst: pointer to %NUL-terminated string to append to
+ * @src: pointer to %NUL-terminated string to append from
+ * @size: Maximum bytes available in @dst
+ *
+ * Do not use this function. Prefer building the string with
+ * formatting, via scnprintf(), seq_buf, or similar.
+ *
+ */
size_t strlcat(char *dst, const char *src, size_t size)
{
size_t len = strnlen(dst, size);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next 1/2] net: ti: icssg: Derive stats array lengths from ARRAY_SIZE
From: Jacob Keller @ 2026-05-14 16:38 UTC (permalink / raw)
To: MD Danish Anwar, David CARLIER
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, Roger Quadros,
Andrew Lunn, Meghana Malladi, Kevin Hao, Vadim Fedorenko, netdev,
linux-doc, linux-kernel, linux-arm-kernel, Vignesh Raghavendra
In-Reply-To: <e28d2931-004e-4935-a0b5-d554ece76fb2@ti.com>
On 5/13/2026 9:56 PM, MD Danish Anwar wrote:
> Hi Jacob,
>
> On 14/05/26 1:30 am, Jacob Keller wrote:
>> The way we solved this in the Intel drivers is to use a single array
>> which contains both the stat name as well as the offset from the
>> structure where the stat resides.
>>
>> The stat string code just iterates over the stat list for the strings,
>> while the stat value code iterates the array and computes the stat
>> address from the offset and size and base structure pointer. Each object
>> that has stats has its own stat array structure.
>>
>> This is probably overkill, but the advantage is that the strings and
>> their values are stored together and adding a new stat is as simple as
>> adding a new entry to that list.
>>
>> I.e.
>>
>> struct ice_stats {
>> char stat_string[ETH_GSTRING_LEN];
>> int sizeof_stat;
>> int stat_offset;
>> };
>>
>> #define ICE_STAT(_type, _name, _stat) { \
>> .stat_string = _name, \
>> .sizeof_stat = sizeof_field(_type, _stat), \
>> .stat_offset = offsetof(_type, _stat) \
>> }
>>
>> #define ICE_VSI_STAT(_name, _stat) \
>> ICE_STAT(struct ice_vsi, _name, _stat)
>> #define ICE_PF_STAT(_name, _stat) \
>> ICE_STAT(struct ice_pf, _name, _stat)
>>
>>
>> Then the stats for the individial arrays are defined like this:
>>
>> static const struct ice_stats ice_gstrings_vsi_stats[] = {
>> ICE_VSI_STAT(ICE_RX_UNICAST, eth_stats.rx_unicast),
>> ICE_VSI_STAT(ICE_TX_UNICAST, eth_stats.tx_unicast),
>> ICE_VSI_STAT(ICE_RX_MULTICAST, eth_stats.rx_multicast),
>> ICE_VSI_STAT(ICE_TX_MULTICAST, eth_stats.tx_multicast),
>> ICE_VSI_STAT(ICE_RX_BROADCAST, eth_stats.rx_broadcast),
>> ICE_VSI_STAT(ICE_TX_BROADCAST, eth_stats.tx_broadcast),
>> ...
>> };
>>
>> (Note, ICE_RX_UNICAST is a macro that defines the string value.. I don't
>> recall who changed this to macros or why vs just having the strings be
>> directly in the definition...)
>>
>
> Thanks for sharing the ice driver pattern — that's a clean design.
>
>> This is probably a lot bigger refactor to make work, and may not be
>> exactly suitable for your driver. I've considered "upgrading" these data
>
> Yes, I need to see if refactoring is applicable to ICSSG or not. I will
> look into this and send a separate patch / series in future if
> applicable. For this series I will stick with what David Carlier suggested.
>
Makes sense. No need to bloat this by more work immediately. I just
wanted to point it out.
I'd like to uplift this infrastructure into core helpers so that other
drivers can more easily benefit without duplicating the scaffolding, but
its always been a low priority task especially since the private driver
stats are somewhat of a legacy/deprecated interface. (Maintainers don't
generally like driver developers making up their own statistics...)
^ permalink raw reply
* Re: [PATCH v12 10/16] KVM: guest_memfd: Add flag to remove from direct map
From: Ackerley Tng @ 2026-05-14 16:45 UTC (permalink / raw)
To: Takahiro Itazuri, fvdl, seanjc, ljs
Cc: Liam.Howlett, agordeev, ajones, akpm, alex, andrii, aou, ast,
baolu.lu, borntraeger, bp, bpf, catalin.marinas, chenhuacai,
corbet, coxu, daniel, dave.hansen, david, derekmn, dev.jain,
eddyz87, gerald.schaefer, gor, haoluo, hca, hpa, itazur, jackabt,
jackmanb, jannh, jgg, jgross, jhubbard, jiayuan.chen, jmattson,
joey.gouly, john.fastabend, jolsa, jthoughton, kalyazin, kas,
kernel, kpsingh, kvm, kvmarm, lenb, linux-arm-kernel, linux-doc,
linux-fsdevel, linux-kernel, linux-kselftest, linux-mm, linux-pm,
linux-riscv, linux-s390, loongarch, lorenzo.stoakes, luto,
maobibo, martin.lau, maz, mhocko, mingo, mlevitsk,
nikita.kalyazin, oupton, palmer, patrick.roy, pavel, pbonzini,
peterx, peterz, pfalcato, pjw, prsampat, rafael, riel, rppt,
ryan.roberts, sdf, shijie, skhan, song, surenb, suzuki.poulose,
svens, tabba, tglx, thuth, urezki, vannapurve, vbabka, will,
willy, wu.fei9, x86, yang, yangyicong, yonghong.song, yosry,
yu-cheng.yu, yuzenghui, zhengqi.arch, zulinx86
In-Reply-To: <20260508081812.12345-1-itazur@amazon.com>
Takahiro Itazuri <itazur@amazon.com> writes:
>
> [...snip...]
>
Brought this topic up on the guest_memfd biweekly today!
>
> Agreed with both of you. I'll adopt the filemap-level approach:
>
> - Move the zap/restore hooks from guest_memfd into filemap_add_folio()
> / filemap_remove_folio().
> - Tighten AS_NO_DIRECT_MAP semantics so that, for folios in such a
> mapping, the direct map is invalid for the entire time the folio
> resides in the page cache.
> - Drop the per-folio KVM_GMEM_FOLIO_NO_DIRECT_MAP bookkeeping in
> folio->private, since the existence of the folio in the mapping is
> itself the state.
>
> On each guest memory population path,
>
> - memcpy-based population from userspace goes through the userspace
> mapping of guest_memfd, not through the kernel direct map, so the
> filemap-level invariant doesn't affect it. But this is slow, which
> is what motivated the write() syscall support.
>
> - write(): meant to speed up the userspace-memcpy case above by doing
> the copy in the kernel. I believe Brendan's __GFP_UNMAPPED/mermap
> work [1] would give us a low-overhead way to get temporary kernel
> access to an AS_NO_DIRECT_MAP. Landing mermap may take a while, but
> this series does not introduce the write() path, so mermap is not a
> blocker for now.
>
> - kvm_gmem_populate(): this is a TDX/SNP-only path, and NO_DIRECT_MAP
> is not available on those VM types —
> kvm_arch_gmem_supports_no_direct_map() returns false for
> KVM_X86_TDX_VM and KVM_X86_SNP_VM, which are its only callers
> today. So it doesn't interact with the filemap invariant IIUC.
>
I'm a little bit uncomfortable this statement since it seems to say TDX
and SNP aren't taken care of. Would just like to discuss (for
a line of sight to SNP and TDX support):
For non-in-place population where the source physical page is different
from the destination physical page,
+ TDX: the TDX module does the population and works with physical
addresses, so no issue with populate? Other parts of TDX may have
trouble though, but that can be handled later.
+ SNP: sev_gmem_post_populate() does a memcpy() after using
kmap_local_page()
Would mermap be a drop in replacement for kmap_local_page() here? Would
guest_memfd need to force a TLB flush after mermap+memcpy?
> So, unless I'm missing any path, adopting the filemap-level approach in
> this series should be fine.
>
>
> I'd like to consult with you folks on how to proceed in advance. In a
> separate reply on the cover letter thread [2], Lorenzo and Sean
> suggested that the mm pieces should go through the mm subsystem:
>
> On Tue, Apr 21, 2026 at 04:36:00PM +0000, Sean Christopherson wrote:
>> Yeah, when the time comes, the mm pieces definitely need to go through the mm
>> tree. Ideally, I think this would be merged in two separate parts, with all mm
>> changes going through the mm tree, and then the KVM changes through the KVM tree
>> using a stable topic branch/tag from Andrew.
>
> I see two reasonable paths to get there, and would appreciate your
> input on which you prefer:
>
> Path A — validate on KVM side first, then split:
> - Post v13 as a single series on the KVM list, gather feedback and
> make sure the design is acceptable to KVM reviewers.
> - Once v13 looks good ("the time comes"), do the MM/KVM split,
> rebase the MM part onto the appropriate MM branch, and post the
> MM part to linux-mm to build consensus with MM maintainers.
>
> Path B — split early and seek MM consensus in parallel:
> - With the filemap rework already in place, do the MM/KVM split
> now and post the MM part to linux-mm directly. The KVM part follows
> on top of a stable topic from MM.
>
> Which of the two would you rather see? Happy to go either way.
>
Vlastimil pointed out that there's a temporary limitation now that the
mm-tree cannot do stable branches shared between trees now.
I think it depends on how quickly you plan to refresh this series, but
Path A wouldn't be blocked by the temporary limitation.
My opinion would be to go ahead with a new revision (Path A) to fully
address comments before splitting the series. Any Reviewed-bys can be
carried over to the split series anyway :)
Alternatively you could wait till conversion lands :P Either one of us
will need to do more work for conversion wrt direct map removal.
>
> [1] https://lore.kernel.org/all/20260320-page_alloc-unmapped-v2-0-28bf1bd54f41@google.com/
> [2] https://lore.kernel.org/all/20260506080753.14517-1-itazur@amazon.com/
>
> Takahiro
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox