DAMON_LRU_SORT handles commit_inputs request inside kdamond thread,
reading the module parameters.  If the user updates the module
parameters while the kdamond thread is reading those, races can happen.
To avoid this, the commit_inputs parameter shows whether it is still in
the progress, assuming users wouldn't update parameters in the middle of
the work.  Some users might ignore that.  Add a warning about the
behavior.

The issue was discovered [1] by sashiko.

[1] https://lore.kernel.org/20260319161620.189392-2-objecting@objecting.org

Fixes: 6acfcd0d7524 ("Docs/admin-guide/damon: add a document for DAMON_LRU_SORT")
Cc: <stable@vger.kernel.org> # 6.0.x
Signed-off-by: SeongJae Park <sj@kernel.org>
---
 Documentation/admin-guide/mm/damon/lru_sort.rst | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst
index 797962a459e6..25e2f042a383 100644
--- a/Documentation/admin-guide/mm/damon/lru_sort.rst
+++ b/Documentation/admin-guide/mm/damon/lru_sort.rst
@@ -79,6 +79,10 @@ of parameters except ``enabled`` again.  Once the re-reading is done, this
 parameter is set as ``N``.  If invalid parameters are found while the
 re-reading, DAMON_LRU_SORT will be disabled.
 
+Once ``Y`` is written to this parameter, the user must not write to any
+parameters until reading ``commit_inputs`` again returns ``N``.  If users
+violate this rule, the kernel may exhibit undefined behavior.
+
 active_mem_bp
 -------------
 
-- 
2.47.3

Forwarding Sashiko review for doing discussions via mails.

# review url: https://sashiko.dev/#/patchset/20260329153052.46657-3-sj@kernel.org
# start of sashiko.dev inline review
commit 7f5e14b7be3b4aea36d62a6c529ef25dde22e973
Author: SeongJae Park <sj@kernel.org>

Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race

This commit updates the DAMON LRU_SORT documentation to warn users against
modifying module parameters while the kdamond thread is processing a
commit_inputs request. It states that violating this rule can cause races
and undefined behavior in the kernel.

Link: https://lore.kernel.org/20260319161620.189392-2-objecting@objecting.org

> diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst
> index a7dea7c75a9b..14cc6b2db897 100644
> --- a/Documentation/admin-guide/mm/damon/lru_sort.rst
> +++ b/Documentation/admin-guide/mm/damon/lru_sort.rst
> @@ -79,6 +79,10 @@ of parametrs except ``enabled`` again.  Once the re-reading is done, this
>  parameter is set as ``N``.  If invalid parameters are found while the
>  re-reading, DAMON_LRU_SORT will be disabled.
>  
> +Once ``Y`` is written to this parameter, the user must not write to any
> +parameters until reading ``commit_inputs`` again returns ``N``.  If users
> +violate this rule, the kernel may exhibit undefined behavior.

Is it safe to rely on userspace following documentation to prevent kernel
data races?

The kernel is generally expected to be robust against concurrent or unexpected
userspace inputs. Does addressing a data race with a documentation warning
leave the kernel vulnerable to crashes or instability if a user ignores this
rule?

Could this underlying race condition be resolved with proper synchronization,
such as locks or mutexes, rather than documenting the undefined behavior?


# end of sashiko.dev inline review
# review url: https://sashiko.dev/#/patchset/20260329153052.46657-3-sj@kernel.org
#
# hkml [1] generated a draft of this mail.  It can be regenerated
# using below command:
#
#     hkml patch sashiko_dev --for_forwarding \
#             20260329153052.46657-3-sj@kernel.org
#
# [1] https://github.com/sjp38/hackermail

Sent using hkml (https://github.com/sjp38/hackermail)

On Sun, 29 Mar 2026 08:49:54 -0700 SeongJae Park <sj@kernel.org> wrote:

> Forwarding Sashiko review for doing discussions via mails.
> 
> # review url: https://sashiko.dev/#/patchset/20260329153052.46657-3-sj@kernel.org
> # start of sashiko.dev inline review
> commit 7f5e14b7be3b4aea36d62a6c529ef25dde22e973
> Author: SeongJae Park <sj@kernel.org>
> 
> Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race
> 
> This commit updates the DAMON LRU_SORT documentation to warn users against
> modifying module parameters while the kdamond thread is processing a
> commit_inputs request. It states that violating this rule can cause races
> and undefined behavior in the kernel.
> 
> Link: https://lore.kernel.org/20260319161620.189392-2-objecting@objecting.org
> 
> > diff --git a/Documentation/admin-guide/mm/damon/lru_sort.rst b/Documentation/admin-guide/mm/damon/lru_sort.rst
> > index a7dea7c75a9b..14cc6b2db897 100644
> > --- a/Documentation/admin-guide/mm/damon/lru_sort.rst
> > +++ b/Documentation/admin-guide/mm/damon/lru_sort.rst
> > @@ -79,6 +79,10 @@ of parametrs except ``enabled`` again.  Once the re-reading is done, this
> >  parameter is set as ``N``.  If invalid parameters are found while the
> >  re-reading, DAMON_LRU_SORT will be disabled.
> >  
> > +Once ``Y`` is written to this parameter, the user must not write to any
> > +parameters until reading ``commit_inputs`` again returns ``N``.  If users
> > +violate this rule, the kernel may exhibit undefined behavior.
> 
> Is it safe to rely on userspace following documentation to prevent kernel
> data races?
> 
> The kernel is generally expected to be robust against concurrent or unexpected
> userspace inputs. Does addressing a data race with a documentation warning
> leave the kernel vulnerable to crashes or instability if a user ignores this
> rule?
> 
> Could this underlying race condition be resolved with proper synchronization,
> such as locks or mutexes, rather than documenting the undefined behavior?

I answered same question on the previous version of this patch.  In short, I
think this is ok for stable kernels.  For mainline, Liew's patch [1] that can
fix this issue together is on the way.

[1] https://lore.kernel.org/20260329075415.36775-1-aethernet65535@gmail.com


Thanks,
SJ

[...]