Re: (sashiko review) [PATCH 2/2] Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race

[SeongJae Park]

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

> Forwarding Sashiko review for doing discussions via mails.
> 
> # review url: https://sashiko.dev/#/patchset/20260329153052.46657-3-sj@xxxxxxxxxx
> # start of sashiko.dev inline review
> commit 7f5e14b7be3b4aea36d62a6c529ef25dde22e973
> Author: SeongJae Park <sj@xxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxx
> 
> > 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@xxxxxxxxx


Thanks,
SJ

[...]