Re: (sashiko review) [PATCH v4 1/2] mm/damon/lru_sort: validate min_region_size to be power of 2

[Liew Rui Yan <aethernet65535@gmail.com>]

Hi SeongJae,

Thank you for your detailed explanation and for being patient with me. I
sincerely apologize for the confusion and the extra workload my unclear
communication has caused you. It was never my intention to hide context
or game the system; I simply misjudged the priorities and failed to
provide the full picture.

I want to continue contributing to DAMON. I truly enjoy working on it,
and I'm grateful for the opportunity.

On Sat, 11 Apr 2026 08:38:21 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> Thank you for sharing these.  But seems even this context is incomplete from my
> perspective...
> 
> The Real Context
> ----------------
> 
> The real start of the context is probably the question [1] that you asked on
> 2026-03-18.  At that time, we found committing wrong parameters stops DAMON
> without an user-visible error.  We agreed DAMON being killed is no problem but
> the absence of user-visible error is a minor user experience problem that
> better to be improved.  So you planned to make the user experience improvement.

You're right - that question was the real starting point. Back then, I
hadn't yet realized that an unexpectedly terminated kdamond cannot be
restarted. After that discussion, I started working on synchronous
commit patch [1].

> 
> Apparently series A is the followup of that.  The first version was posted on
> 2026-03-26, according to the changelog of this patch series.  I can show I was
> saying the patch was confusing on the thread.

Series A came from a Sashiko review [2] that appeared while I was
working on that synchronous commit patch. It [3] was a new, separate
issue.

> 
> While the review of the confusing series A was ongoing, you posted [3] the RFC
> of series B on 2026-03-31.  This patch reported one important finding: the
> silent DAMON stop is not just a minor user experience issue but a serious bug
> because it cannot be started again.

I discovered the "kdamond cannot restart" problem by accident while
testing other things. That's why I treated it as a separate issue from
Series A, not as something directly related.

> 
> And this made things much more confusing. There are multiple ways to trigger
> the issue.  Wrong addr_unit commit is just one of the ways.  We discussed the
> way to fix the real issue.  So, by looking back this, I think you should
> prioritized series B from the point, or make suer series A is only for the
> minor user experience improvement.  Or asked me what to prioritize.  You didn't
> and I missed the fact that you are also working on series A.

Here's what happened in my head, and I'm sorry I didn't say it loud at
the time:
After you advised me to slow down [4], I thought you preferred me to focus
on one series at a time. Since Series A looked closer to merge, I
decided to finish it first, then move to Series B. I should have asked
you what to prioritize instead of assuming. That was my mistake.

> 
> But you just continued posting new versions of series A.  I was wrongly
> thinking that is still the minor user experience improvement.  I still think
> the patches were implicitly saying so.  I'm not sure if it was intentional or
> not.  But definitely it was confusing me.  On 2026-04-02, I started feeling I'm
> missing some of the contexts, and asked you more clarification of user impacts
> [4] and full history [5].  You posted v3 [6] right after I asked the question,
> even without answering the question.  Only from this point it became clear
> sereis A is not just a minor user experience improvement but a critical bug
> fix.  Now I think you should clarify this can also fix one trigger point of the
> critical bug but the real fix is work in progress, and this is till only a
> minor user experience improvement.  But because you didn't, and my poor memory
> is volatile, at this point I was thinking this all the work you are doing for
> the series B-exposed bug.

Regarding your "[4][5]":
When you asked about Cc:stable@, I got excited and focused on figuring
out the Fixes tag and stable rules. When you asked if I had other
patches, I thought you meant the older "addr_unit power-of-2 validation"
patch [3] from before Series A. I didn't realize you were asking about
all my in-progress work. I'm sorry for the confusion.

> 
> In the response to the sashiko review on this thread, therefore, I was thinking
> you are thinking the wrong addr_unit commit is the only way to trigger the bug.
> I didn't want to ask you to work from the beginning to fix the entire bug, so I
> was saying fixing the real bug for all exploit points is out of the scope of
> this bug.
> 
> But now it is turned out that you were aware of the other ways to trigger the
> bug, and didn't transparentl and explicitly exposing that.

To be honest, I only knew about the 'addr_unit' trigger. I was vaguely
aware that memory allocation failures could also cause termination, but
I never reproduced them or investigated further. I should have told you
this earlier.

> 
> So I withdraw what I told on the reply to the sashiko review.  And appreciate
> sashiko developers again for giving us a chance to finding this.
> 
> Next Steps
> ----------
> 
> So, what to do?  Please prioritize series B, if you still willing to do.  It is
> ok to keep doing series A, but only as the minor user experience improvement.
> Clearly explain the whole context you are aware of.  Don't Cc stable@ for
> series A, as it is only an incomplete fix of it.  The fix of the one trigger
> point is just a side effect.

Yes, I absolutely want to continue contributing to DAMON.

I realize most of this confusion came from me misinterpreting your words
or making assumptions without asking. So this time, I want to be
explicit:
1. I will remove the Cc stable@
2. Since you suggested prioritizing Series B, would you prefer me to
   send a revised v5 of Series A now, or should I wait until Series B is
   settled to avoid more noise in your inbox?
3. I will focus on Series B starting now.

> 
> And For Future Contributions
> ----------------------------
> 
> Liew, I really appreciate your contributions.  You found and shared important
> DAMON bugs.  But apparently your communication has many rooms to improve, at
> least for poort DAMON maintainer who have to work with only limited resources
> including the poort and volatile memory.  I find I was asking clarifications to
> your mails multiple times.  I have to say it was even frustrating sometimes and
> definitely took quite amount of my resource.  Meanwhile, from my uncautiously
> biased perspective, you were only adding more traffic and confusions.

I'm very sorry for the trouble I caused. Moving forward, I will ask
before assuming, and I will make sure my intentions are clear.

> 
> This makes me disappointed and even suspect your intention...  I really hate
> myself suspecting someone.  But we are in the world of bad actors that now
> gained the power of AI.  We actually had a suspicious case from DAMON
> contributors recently, do you remember?

Yes, I remember the Josh Law case. I am not a bot. I have no intention
of gaming contributions or harming DAMON. I just want to do real work.

> 
> I want to still believe you, so I will do so.  Please feel free to keep
> contributing to DAMON as long as that's what you want to do.  But, please aware
> of the fact that DAMON maintainer has poor volatile memory and working with
> limited resource, and try to make every conversation super clear and
> transparent, from next time.

Thank you for your honesty, and for still trusting me. I will continue
contributing to DAMON. I will work hard to make my emails clear and
transparent, and I will ask questions whenever something is ambiguous,
so we can stay aligned.

> 
> [1] https://lore.kernel.org/20260318153731.97470-1-aethernet65535@gmail.com
> [2] https://lore.kernel.org/20260327062627.66426-1-aethernet65535@gmail.com
> [3] https://lore.kernel.org/20260330164347.12772-1-aethernet65535@gmail.com
> [4] https://lore.kernel.org/20260402140314.74600-1-sj@kernel.org
> [5] https://lore.kernel.org/20260402152915.75294-1-sj@kernel.org
> [6] https://lore.kernel.org/20260403052837.58063-1-aethernet65535@gmail.com

[1] https://lore.kernel.org/20260321002642.22712-1-aethernet65535@gmail.com
[2] https://lore.kernel.org/20260325025317.86571-1-sj@kernel.org
[3] https://lore.kernel.org/20260327062627.66426-1-aethernet65535@gmail.com
[4] https://lore.kernel.org/20260403161906.65008-1-sj@kernel.org

Best regards,
Rui Yan