Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
Subsystems (5)
SeongJae Park
maintainercover Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
Writing 'Y' to the commit_inputs parameter of DAMON_RECLAIM and DAMON_LRU_SORT, and writing other parameters before the commit_inputs request is completely processed can cause race conditions. While the consequence can be bad, the documentation is not clearly describing that. Add clear warnings.
The issue was discovered [1,2] by sashiko.
[1] https://lore.kernel.org/[email protected]
[2] https://lore.kernel.org/[email protected]
Changes from RFC
(https://lore.kernel.org/[email protected])
- Wordsmith.
- Rebase to latest mm-new.
SeongJae Park (2):
Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates
race
Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param
updates race
Documentation/admin-guide/mm/damon/lru_sort.rst | 4 ++++ Documentation/admin-guide/mm/damon/reclaim.rst | 4 ++++ 2 files changed, 8 insertions(+)
base-commit: b761d53965a239abe1469f2e4e2d4f7d69fac9bd
Signature · 1 line
2.47.3
SeongJae Park
maintainerPATCH 1/2 Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race
DAMON_RECLAIM 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/[email protected]
--- Documentation/admin-guide/mm/damon/reclaim.rst | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/admin-guide/mm/damon/reclaim.rst +4 -0
@@ -71,6 +71,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_RECLAIM 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. + min_age -------
Signature · 1 line
2.47.3
SeongJae Park
maintainerRe: (sashiko review) [PATCH 1/2] Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race
Forwarding Sashiko review for doing discussions via mails.
# review url: https://sashiko.dev/#/patchset/[email protected] # start of sashiko.dev inline review commit 140a828ed89f6ed59d7b68f9bb0f1ec9b051eec7 Author: SeongJae Park <[email protected]>
Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race
This commit adds documentation warning users not to update DAMON reclaim module parameters while a commit_inputs request is in progress. It notes that doing so can cause undefined behavior due to races with the kdamond thread reading those parameters.
Quoted 4 lines
Documentation/admin-guide/mm/damon/reclaim.rst +0
-0
[ ... ]
Documentation/admin-guide/mm/damon/reclaim.rst of parametrs except ``enabled`` again. Once the re-reading is done, this · line 76
Quoted 7 lines
Documentation/admin-guide/mm/damon/reclaim.rst +3
-0@@ -71,6 +71,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_RECLAIM 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 acceptable to rely on documentation to prevent undefined behavior triggered by userspace?
If users write to sysfs parameters concurrently, can it still crash the kernel? For example, in damon_reclaim_apply_parameters(), the code verifies if (!damon_reclaim_mon_attrs.aggr_interval) to prevent division by zero. If a user concurrently writes 0 to the parameter via sysfs immediately after this check but before damon_reclaim_new_scheme() executes, wouldn't the subsequent .min_age_region = min_age / damon_reclaim_mon_attrs.aggr_interval calculation result in a divide-by-zero kernel panic?
Should this race be fixed in the code using synchronization primitives rather than adding a documentation warning?
# end of sashiko.dev inline review # review url: https://sashiko.dev/#/patchset/[email protected] # # hkml [1] generated a draft of this mail. It can be regenerated # using below command: # # hkml patch sashiko_dev --for_forwarding \ # [email protected] # # [1] https://github.com/sjp38/hackermail
Sent using hkml (https://github.com/sjp38/hackermail)
SeongJae Park
maintainerRe: (sashiko review) [PATCH 1/2] Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race
Quoted 40 lines · On Sun, 29 Mar 2026 08:49:36 -0700 SeongJae Park <[email protected]> wrote:
Forwarding Sashiko review for doing discussions via mails.
# review url: https://sashiko.dev/#/patchset/[email protected] # start of sashiko.dev inline review commit 140a828ed89f6ed59d7b68f9bb0f1ec9b051eec7 Author: SeongJae Park <[email protected]>Docs/admin-guide/mm/damon/reclaim: warn
commit_inputsvs param updates raceThis commit adds documentation warning users not to update DAMON reclaim module parameters while a
commit_inputsrequest is in progress. It notes that doing so can cause undefined behavior due to races with the kdamond thread reading those parameters.Quoted 4 lines
Documentation/admin-guide/mm/damon/reclaim.rst +0
-0[ ... ]
Documentation/admin-guide/mm/damon/reclaim.rst of parametrs except ``enabled`` again. Once the re-reading is done, this · line 76
Quoted 7 lines
Documentation/admin-guide/mm/damon/reclaim.rst +3
-0@@ -71,6 +71,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_RECLAIM 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 acceptable to rely on documentation to prevent undefined behavior triggered by userspace?
If users write to sysfs parameters concurrently, can it still crash the kernel? For example, in
damon_reclaim_apply_parameters(), the code verifies if (!damon_reclaim_mon_attrs.aggr_interval) to prevent division by zero. If a user concurrently writes 0 to the parameter via sysfs immediately after this check but beforedamon_reclaim_new_scheme()executes, wouldn't the subsequent .min_age_region =min_age/ damon_reclaim_mon_attrs.aggr_interval calculation result in a divide-by-zero kernel panic?
Quoted 2 lines
Should this race be fixed in the code using synchronization primitives rather than adding a documentation warning?
I answered the questions on the previous version. In short, I believe this is ok for stable kernels. For mainline, Liew's patch [1] that can also fix this issue is on the way.
[1] https://lore.kernel.org/[email protected]
Thanks,
SJ
[...]
SeongJae Park
maintainerPATCH 2/2 Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race
In reply to SeongJae ParkDAMON_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/[email protected]
--- Documentation/admin-guide/mm/damon/lru_sort.rst | 4 ++++ 1 file changed, 4 insertions(+)
Documentation/admin-guide/mm/damon/lru_sort.rst +4 -0
@@ -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 -------------
Signature · 1 line
2.47.3
SeongJae Park
maintainerRe: (sashiko review) [PATCH 2/2] Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race
Forwarding Sashiko review for doing discussions via mails.
# review url: https://sashiko.dev/#/patchset/[email protected] # start of sashiko.dev inline review commit 7f5e14b7be3b4aea36d62a6c529ef25dde22e973 Author: SeongJae Park <[email protected]>
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.
Documentation/admin-guide/mm/damon/lru_sort.rst of parametrs except ``enabled`` again. Once the re-reading is done, this · line 84
Quoted 11 lines
Documentation/admin-guide/mm/damon/lru_sort.rst +3
-0@@ -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/[email protected] # # hkml [1] generated a draft of this mail. It can be regenerated # using below command: # # hkml patch sashiko_dev --for_forwarding \ # [email protected] # # [1] https://github.com/sjp38/hackermail
Sent using hkml (https://github.com/sjp38/hackermail)
SeongJae Park
maintainerRe: (sashiko review) [PATCH 2/2] Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race
Quoted 31 lines · On Sun, 29 Mar 2026 08:49:54 -0700 SeongJae Park <[email protected]> wrote:
Forwarding Sashiko review for doing discussions via mails.
# review url: https://sashiko.dev/#/patchset/[email protected] # start of sashiko.dev inline review commit 7f5e14b7be3b4aea36d62a6c529ef25dde22e973 Author: SeongJae Park <[email protected]>Docs/admin-guide/mm/damon/lru_sort: warn
commit_inputsvs param updates raceThis commit updates the DAMON
LRU_SORTdocumentation to warn users against modifying module parameters while the kdamond thread is processing acommit_inputsrequest. It states that violating this rule can cause races and undefined behavior in the kernel.Documentation/admin-guide/mm/damon/lru_sort.rst of parametrs except ``enabled`` again. Once the re-reading is done, this · line 84
Quoted 11 lines
Documentation/admin-guide/mm/damon/lru_sort.rst +3
-0@@ -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?
Quoted 7 lines
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/[email protected]
Thanks,
SJ
[...]
SeongJae Park
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
In reply to SeongJae ParkForwarding sashiko.dev review status for this thread.
# review url: https://sashiko.dev/#/patchset/[email protected]
- [PATCH 1/2] Docs/admin-guide/mm/damon/reclaim: warn commit_inputs vs param updates race
- status: Reviewed
- review: ISSUES MAY FOUND
- [PATCH 2/2] Docs/admin-guide/mm/damon/lru_sort: warn commit_inputs vs param updates race
- status: Reviewed
- review: ISSUES MAY FOUND
# hkml [1] generated a draft of this mail. It can be regenerated # using below command: # # hkml patch sashiko_dev --thread_status --for_forwarding \ # [email protected] # # [1] https://github.com/sjp38/hackermail
Sent using hkml (https://github.com/sjp38/hackermail)
SeongJae Park
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
Quoted 10 lines · On Sun, 29 Mar 2026 08:49:16 -0700 SeongJae Park <[email protected]> wrote:
Forwarding sashiko.dev review status for this thread.
# review url: https://sashiko.dev/#/patchset/[email protected]- [PATCH 1/2] Docs/admin-guide/mm/damon/reclaim: warn
commit_inputsvs param updates race
- status: Reviewed
- review: ISSUES MAY FOUND
- [PATCH 2/2] Docs/admin-guide/mm/damon/lru_sort: warncommit_inputsvs param updates race
- status: Reviewed
- review: ISSUES MAY FOUND
TL; DR: I believe those are not issues.
Thanks,
SJ
[...]
Greg KH
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
In reply to SeongJae ParkQuoted 3 lines · SeongJae Park
Forwarding sashiko.dev review status for this thread.
# review url: https://sashiko.dev/#/patchset/[email protected]
Why are you doing this? If we want to see the review, can't we just go and look at the tool itself? sending it back to all of us feels odd, especially when it is your own patches.
confused,
greg k-h
SeongJae Park
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
+ Roman for a case he has any opinion about my sashiko usage.
Hello Greg,
Quoted 7 lines · On Sun, 29 Mar 2026 20:05:53 +0200 Greg KH <[email protected]> wrote:
Quoted 3 lines · SeongJae Park
Forwarding sashiko.dev review status for this thread.
# review url: https://sashiko.dev/#/patchset/[email protected]Why are you doing this? If we want to see the review, can't we just go and look at the tool itself?
We can. But it is bit cumbersome to opening web browser and moving my focus to there. Reading everything on the mailing tool is easier for some people like me. Like some test bots send reports are replying to patches, or we sometimes forwarding bugzilla reports to mailing lists in a form of a plain text mail.
Secondly, I have to share my opinions about the reviews, as many times AI reviews need human's opinions. There is no good way to do that on the web ui of the tool (sashiko) for now, and I think this mail based flow is the best.
And anyway I'm supposed to share at least my review of AI reviews, in mm community. If I ignore, I will only make Andrew have to reply asking that.
I used to share only my review of the AI reviews as replies, instead of forwarding AI reviews and then replies to those. But it was
1. cumbersome for me (should summarize AI review and then my review; feeling doing work twice), and
2. feeling not optimal at sharing all concerning comments with others. My summary might miss some points of AI review but other reviewers might just believe me and don't read the full review due to the additional web browser opening work. Also some other reivewers might kindly review AI reviews before I do, and save my (or their) time.
Hence I ended up to do this bit odd workflow: Forwarding the full AI review on the mailing list first, then reply my responses.
Quoted 1 line
sending it back to all of us feels odd,
If this is polluting your inbox and/or distract you, I'm so sorry for that. Please let me know if this is distracting you. Maybe I can filtering people who don't want this kind of replies out of the recipients for the forwarding mails. Or, if you have a suggestion about what need to be changed, please let me know.
Quoted 1 line
especially when it is your own patches.
Unfortuantely sashiko cannot send email on its own (yet). So I'm doing that until it can.
Quoted 2 lines
confused,
I hope my above explanation helps you.
Thanks,
SJ
[...]
Greg KH
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
Quoted 11 lines · SeongJae Park
+ Roman for a case he has any opinion about my sashiko usage.
Hello Greg,
Quoted 5 lines · On Sun, 29 Mar 2026 20:05:53 +0200 Greg KH <[email protected]> wrote:
Quoted 3 lines · SeongJae Park
Forwarding sashiko.dev review status for this thread.
# review url: https://sashiko.dev/#/patchset/[email protected]
Quoted 7 lines
Quoted 2 lines
Why are you doing this? If we want to see the review, can't we just go and look at the tool itself?
We can. But it is bit cumbersome to opening web browser and moving my focus to there. Reading everything on the mailing tool is easier for some people like me. Like some test bots send reports are replying to patches, or we sometimes forwarding bugzilla reports to mailing lists in a form of a plain text mail.
Sure, but are you going to now forward all random tool reviews that are run on your subsystem to all of these lists (your distribution cc: is quite large here)?
Quoted 3 lines
Secondly, I have to share my opinions about the reviews, as many times AI reviews need human's opinions. There is no good way to do that on the web ui of the tool (sashiko) for now, and I think this mail based flow is the best.
That is assuming that you can fix up the AI reviews, is that happening here?
Quoted 16 lines
And anyway I'm supposed to share at least my review of AI reviews, in mm community. If I ignore, I will only make Andrew have to reply asking that.
I used to share only my review of the AI reviews as replies, instead of forwarding AI reviews and then replies to those. But it was
1. cumbersome for me (should summarize AI review and then my review; feeling doing work twice), and
2. feeling not optimal at sharing all concerning comments with others. My summary might miss some points of AI review but other reviewers might just believe me and don't read the full review due to the additional web browser opening work. Also some other reivewers might kindly review AI reviews before I do, and save my (or their) time.Hence I ended up to do this bit odd workflow: Forwarding the full AI review on the mailing list first, then reply my responses.
Quoted 7 lines
Quoted 1 line
sending it back to all of us feels odd,
If this is polluting your inbox and/or distract you, I'm so sorry for that. Please let me know if this is distracting you. Maybe I can filtering people who don't want this kind of replies out of the recipients for the forwarding mails. Or, if you have a suggestion about what need to be changed, please let me know.
It just seemed odd, and might get crazy over time if this happens for all random AI tools that happen to be popping up now, right? If this is the "official" one for -mm, that's fine, but consider the distribution and intended audience a bit please.
thanks,
greg k-h
Andrew Morton
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
Quoted 2 lines · On Mon, 30 Mar 2026 07:47:54 +0200 Greg KH <[email protected]> wrote:
Quoted 2 lines
And anyway I'm supposed to share at least my review of AI reviews, in mm community. If I ignore, I will only make Andrew have to reply asking that.
Actually no. I see you're using Sashiko extensively so great, you'll hear nothing more on Sashiko-vs-DAMON from me!
SeongJae Park
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
In reply to Greg KHQuoted 15 lines · On Mon, 30 Mar 2026 07:47:54 +0200 Greg KH <[email protected]> wrote:
Quoted 14 lines · SeongJae Park
+ Roman for a case he has any opinion about my sashiko usage.
Hello Greg,
Quoted 7 lines · On Sun, 29 Mar 2026 20:05:53 +0200 Greg KH <[email protected]> wrote:
Quoted 3 lines · SeongJae Park
Forwarding sashiko.dev review status for this thread.
# review url: https://sashiko.dev/#/patchset/[email protected]Why are you doing this? If we want to see the review, can't we just go and look at the tool itself?
Quoted 8 lines
Quoted 4 lines
We can. But it is bit cumbersome to opening web browser and moving my focus to there. Reading everything on the mailing tool is easier for some people like me. Like some test bots send reports are replying to patches, or we sometimes forwarding bugzilla reports to mailing lists in a form of a plain text mail.
Sure, but are you going to now forward all random tool reviews that are run on your subsystem to all of these lists (your distribution cc: is quite large here)?
Obviously not for random tools. But if there are a few tools that (nearly) everyone agrees useful and worthy to integrate with the mailing lists workflow, I would like to.
Now it seems I was much more optimistic that others.
Quoted 7 lines
Quoted 4 lines
Secondly, I have to share my opinions about the reviews, as many times AI reviews need human's opinions. There is no good way to do that on the web ui of the tool (sashiko) for now, and I think this mail based flow is the best.
That is assuming that you can fix up the AI reviews, is that happening here?
What I mean with the required human opinions for the AI reviews are not necessarily only for fixups, but also sharing of reviews that the human and the tool are aligned.
But in this case, I was sharing the review results seems incorrect, or doesn't need deep dive at least:
https://lore.kernel.org/[email protected]
Quoted 19 lines
Quoted 19 lines
And anyway I'm supposed to share at least my review of AI reviews, in mm community. If I ignore, I will only make Andrew have to reply asking that.
I used to share only my review of the AI reviews as replies, instead of forwarding AI reviews and then replies to those. But it was
1. cumbersome for me (should summarize AI review and then my review; feeling doing work twice), and
2. feeling not optimal at sharing all concerning comments with others. My summary might miss some points of AI review but other reviewers might just believe me and don't read the full review due to the additional web browser opening work. Also some other reivewers might kindly review AI reviews before I do, and save my (or their) time.Hence I ended up to do this bit odd workflow: Forwarding the full AI review on the mailing list first, then reply my responses.
Quoted 1 line
sending it back to all of us feels odd,
Quoted 8 lines
Quoted 5 lines
If this is polluting your inbox and/or distract you, I'm so sorry for that. Please let me know if this is distracting you. Maybe I can filtering people who don't want this kind of replies out of the recipients for the forwarding mails. Or, if you have a suggestion about what need to be changed, please let me know.
It just seemed odd, and might get crazy over time if this happens for all random AI tools that happen to be popping up now, right?
As I also mentioned above, I agree. And seems in this case I was much more optimistic that others, or hallucinated ;)
Quoted 3 lines
If this is
the "official" one for -mm, that's fine, but consider the distribution and intended audience a bit please.
Andrew replied this is not such official and recommended action for mm. I once thought this could be the official one for DAMON only. But in any case, I now understand this can look crazy, odd or excessive to some people including those that I believe. I will think about a better way to use this tool, while keeping your inputs in my mind.
Thank you so much for sharing your opinions, Greg.
Thanks,
SJ
[...]
Andrew Morton
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
In reply to SeongJae ParkQuoted 10 lines · On Sun, 29 Mar 2026 12:32:26 -0700 SeongJae Park <[email protected]> wrote:
Quoted 7 lines · On Sun, 29 Mar 2026 20:05:53 +0200 Greg KH <[email protected]> wrote:
Quoted 3 lines · SeongJae Park
Forwarding sashiko.dev review status for this thread.
# review url: https://sashiko.dev/#/patchset/[email protected]Why are you doing this? If we want to see the review, can't we just go and look at the tool itself?
Quoted 8 lines
We can. But it is bit cumbersome to opening web browser and moving my focus to there. Reading everything on the mailing tool is easier for some people like me. Like some test bots send reports are replying to patches, or we sometimes forwarding bugzilla reports to mailing lists in a form of a plain text mail.
Secondly, I have to share my opinions about the reviews, as many times AI reviews need human's opinions. There is no good way to do that on the web ui of the tool (sashiko) for now, and I think this mail based flow is the best.
I do agree with Greg that it's all a bit excessive. Thanks for your your diligence, but perhaps dial it back a bit? It's OK - we're all trying to figure out how best to utilize this tool.
I view Sashiko as primarily an author tool. Sometimes I call it checkpatch++. In a better world, author would be able to sort out Sashiko issues before ever sending out the patchset. But in this world, a public send is needed to obtain that review.
So what we're presently seeing is author development activity which is unfortunately and inappropriately being conducted on a public list.
Personally, I pay only a little attention to author's Sashiko activity. Just enough to see whether I should pay more attention. If author says "oops, let me redo" then fine, I'll await the next spin. If author says "that was all nonsense" then fine, time to take a closer look.
SeongJae Park
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
Quoted 17 lines · On Mon, 30 Mar 2026 14:22:05 -0700 Andrew Morton <[email protected]>…
Quoted 15 lines · On Sun, 29 Mar 2026 12:32:26 -0700 SeongJae Park <[email protected]> wrote:
Quoted 7 lines · On Sun, 29 Mar 2026 20:05:53 +0200 Greg KH <[email protected]> wrote:
Quoted 3 lines · SeongJae Park
Forwarding sashiko.dev review status for this thread.
# review url: https://sashiko.dev/#/patchset/[email protected]Why are you doing this? If we want to see the review, can't we just go and look at the tool itself?
We can. But it is bit cumbersome to opening web browser and moving my focus to there. Reading everything on the mailing tool is easier for some people like me. Like some test bots send reports are replying to patches, or we sometimes forwarding bugzilla reports to mailing lists in a form of a plain text mail.
Quoted 7 lines
Quoted 3 lines
Secondly, I have to share my opinions about the reviews, as many times AI reviews need human's opinions. There is no good way to do that on the web ui of the tool (sashiko) for now, and I think this mail based flow is the best.
I do agree with Greg that it's all a bit excessive. Thanks for your your diligence, but perhaps dial it back a bit? It's OK - we're all trying to figure out how best to utilize this tool.
Thank you for your kind words, Andrew. I understand and admit the fact that this looks excessive.
Quoted 3 lines
I view Sashiko as primarily an author tool. Sometimes I call it checkpatch++.
Thank you for sharing your perspective. This is helpful at what you want from the use of the tool, thank you.
My view of sashiko was a human reviewer that having very odd characteristic and cannot answer to my feedback for a reason, but still being useful in many cases. Hence I wanted to help the special reviewer be able to communicate with others on the mailing list. And I was thinking anyway that's what sashiko will do, because I saw sending review as mail as one of TODO items for sashiko, from the public announcement, and I onboarded DAMON for that.
But apparently not everyone is sharing same view. My understanding of the TODO item in sashiko public announcement may also be biased. Maybe being a subsystem's sole maintainer that looking for a reviewer made such uncautiously biased perspectives.
Quoted 6 lines
In a better world, author would be able to sort out Sashiko issues before ever sending out the patchset. But in this world, a public send is needed to obtain that review.
So what we're presently seeing is author development activity which is unfortunately and inappropriately being conducted on a public list.
Makes sense. Now I understand why you and Roman were discussing having a separate mailing list for sharing the reviews via mail as a path forward, and I agree that could be a good option.
Quoted 6 lines
Personally, I pay only a little attention to author's Sashiko activity. Just enough to see whether I should pay more attention. If author says "oops, let me redo" then fine, I'll await the next spin. If author says "that was all nonsense" then fine, time to take a closer look.
Makes sense. I will try to keep sharing necessary information, but for only targetted audiences, with less traffic.
Thanks,
SJ
Re: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
In reply to Andrew MortonQuoted 5 lines · Andrew Morton
I view Sashiko as primarily an author tool. Sometimes I call it checkpatch++. In a better world, author would be able to sort out Sashiko issues before ever sending out the patchset. But in this world, a public send is needed to obtain that review.
Note that Sashiko is fully open source and the prompts are available in third_party/prompts in the git repo:
https://github.com/sashiko-dev/sashiko
So people can run it privately, although they will need to provide their own LLM credits. This also means that you can use some other LLM besides Gemini 3.1 Pro.
Cheers,
- Ted
SeongJae Park
maintainerRe: (sashiko status) [PATCH 0/2] Docs/admin-guide/mm/damon: warn commit_inputs vs other params race
Quoted 7 lines · On Tue, 31 Mar 2026 08:19:43 -0400 "Theodore Tso" <[email protected]> wrote:
Quoted 5 lines · Andrew Morton
I view Sashiko as primarily an author tool. Sometimes I call it checkpatch++. In a better world, author would be able to sort out Sashiko issues before ever sending out the patchset. But in this world, a public send is needed to obtain that review.
Quoted 7 lines
Note that Sashiko is fully open source and the prompts are available in third_party/prompts in the git repo:
https://github.com/sashiko-dev/sashiko
So people can run it privately, although they will need to provide their own LLM credits.
That's unfortunately a barrier to some people. To me, what makes sashiko special and different from other AI review tools is the fact that it is automatically reviewing nearly every kernel patch for free and publicly sharing the results.
Thanks,
SJ
[...]