From: SJ Park <sj@kernel.org>
To: Gutierrez Asier <gutierrez.asier@huawei-partners.com>
Cc: SJ Park <sj@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
damon@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [RFC PATCH 1/4] mm/damon/core: handle NULL ctx parameter in damon_call()
Date: Thu, 13 Aug 2026 08:12:29 -0700 [thread overview]
Message-ID: <20260813151230.104083-1-sj@kernel.org> (raw)
In-Reply-To: <c55a94f4-6ad2-4b60-b0ce-bf670dcc2f7b@huawei-partners.com>
On Thu, 13 Aug 2026 17:27:51 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
>
>
> On 8/13/2026 4:55 PM, SJ Park wrote:
> > Hi Asier,
> >
> >
> > Thank you for your review!
> >
> > On Thu, 13 Aug 2026 11:33:01 +0300 Gutierrez Asier <gutierrez.asier@huawei-partners.com> wrote:
> >
> >> Hi SJ,
> >>
> >> On 8/13/2026 6:49 AM, SJ Park wrote:
> >>> When NULL damon_ctx pointer parameter is passed, damon_call() could do
> >>> NULL dereference. The caller is responsible to avoid that. It is easy
> >>> to forget, and there are many damon_call() callers. Meanwhile,
> >>> damon_call() is never meant to be performance critical. It uses mutex
> >>> and completion. Add the NULL pointer check inside damon_call() so that
> >>> callers can pass the parameter without NULL checks.
> >>>
> >>> Signed-off-by: SJ Park <sj@kernel.org>
> >>> ---
> >>> mm/damon/core.c | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/mm/damon/core.c b/mm/damon/core.c
> >>> index 92631a36d7b51..5882f9c94c47f 100644
> >>> --- a/mm/damon/core.c
> >>> +++ b/mm/damon/core.c
> >>> @@ -2188,6 +2188,8 @@ int damon_kdamond_pid(struct damon_ctx *ctx)
> >>> */
> >>> int damon_call(struct damon_ctx *ctx, struct damon_call_control *control)
> >>> {
> >>> + if (!ctx)
> >>> + return -EINVAL;
> >>> if (!control->repeat)
> >>> init_completion(&control->completion);
> >>> control->canceled = false;
> >>
> >> I know that this is a minor optimization, but how about moving INIT_LIST_HEAD(&control->list)
> >> to right before list_add_tail?
> >>
> >> It doesn't make sense to initialize the list before checking call_controls_obsolete.
> >
> > I agree it might be more efficient.
> >
> > I think my intention of the code was to to keep the call_controls_lock critical
> > section minimal with access to things that really protected by the mutex.
> > Moving the simple initialization should be fine. As you mentioned, it should
> > be minor change. I'm bit concerned if it will confuse people if the list head
> > is also protected by the mutex, though. What do you think?
> Good point, I didn't think about it.
>
> Given that damon_call is not called often, I believe user experience should be
> more important than efficiency. Anyway, you have the last word.
Thank you for the quick answer, Asier. I understand you are find with keeping
this as is. Let's keep this as is for now.
Thanks,
SJ
[...]
next prev parent reply other threads:[~2026-08-13 15:12 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 3:49 [RFC PATCH 0/4] mm/damon: allow NULL or unstarted damon_ctx parameter for damon_call() SJ Park
2026-08-13 3:49 ` [RFC PATCH 1/4] mm/damon/core: handle NULL ctx parameter in damon_call() SJ Park
2026-08-13 3:58 ` sashiko-bot
2026-08-13 8:33 ` Gutierrez Asier
2026-08-13 13:55 ` SJ Park
2026-08-13 14:27 ` Gutierrez Asier
2026-08-13 15:12 ` SJ Park [this message]
2026-08-13 3:49 ` [RFC PATCH 2/4] mm/damon/core: set ctx->call_controls_obsolete in damon_new_ctx() SJ Park
2026-08-13 4:02 ` sashiko-bot
2026-08-13 4:10 ` SJ Park
2026-08-13 3:49 ` [RFC PATCH 3/4] mm/damon/reclaim: remove unnecessary damon_call() param validation SJ Park
2026-08-13 4:01 ` sashiko-bot
2026-08-13 4:11 ` SJ Park
2026-08-13 3:49 ` [RFC PATCH 4/4] mm/damon/lru_sort: " SJ Park
2026-08-13 4:04 ` sashiko-bot
2026-08-13 4:12 ` SJ Park
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260813151230.104083-1-sj@kernel.org \
--to=sj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=damon@lists.linux.dev \
--cc=gutierrez.asier@huawei-partners.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.