linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: SeongJae Park <sj@kernel.org>,
	damon@lists.linux.dev, kernel-team@meta.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 0/7] mm/damon: define and use DAMON initialization check function
Date: Mon, 15 Sep 2025 22:54:57 -0700	[thread overview]
Message-ID: <20250916055458.118498-1-sj@kernel.org> (raw)
In-Reply-To: <20250915213312.12892156442f3a795a0a01f5@linux-foundation.org>

On Mon, 15 Sep 2025 21:33:12 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Mon, 15 Sep 2025 20:35:04 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> > If DAMON is tried to be used by its API callers when it is not yet
> > successfully initialized, the callers could be crashed.  Such issues
> > actually happened and were fixed [1].  DAMON API callers are therefore
> > having their own hacks for seeing if it is safe to use DAMON or not.
> > Those built on an untreliable assumption that DAMON should be ready to
> > be used on module init time.  DAMON initialization could fail if
> > KMEM_CACHE() fails, though.
> 
> Wait.  Is there any realistic expectation that KMEM_CACHE() will fail
> when DAMON uses it?

Not really.  The commit message is saying just a theoretical and unlikely
possibility.

> We do have the convention of assuming that
> __init-time allocations do not fail.  If they do, an oops or panic is
> an acceptable response.
> 
> Are these problems actually real-world demonstrable things, or has
> someone been playing with fault injection or, ...?

I don't have a way to demonstrate it.  The commit message was only for
discussing a theoretical and unlikely case.  Maybe it was better to just not
mention.

> 
> > Also those are basically duplications that
> > make their maintenance difficult.
> 
> Unclear.  This means that the client hacks are no longer necessary after
> these changes?

You're correct.

Sorry for the poor cover letter message.  If I have to post a new version of
this patch series, I would update the cover letter message as below.  Does it
look better?  If so, could you please update the cover letter part of the
commit on the mm tree?

"""
DAMON is initialized in subsystem initialization time, by damon_init().  If
DAMON API functions are called before the initialization, the system could
crash.  Actually such issues happened and were fixed [1] in the past.  For the
fix, DAMON API callers have updated to check if DAMON is initialized or not,
using their own hacks.  The hacks are unnecessarily duplicated on every DAMON
API callers and therefore it would be difficult to reliably maintain in the
long term.

Make it reliable and easy to maintain.  For this, implement a new DAMON core
layer API function that returns if DAMON is successfully initialized.  If it
returns true, it means DAMON API functions are safe to be used.  After the
introduction of the new API, update DAMON API callers to use the new function
instead of their own hacks.

[1] https://lore.kernel.org/20250909022238.2989-1-sj@kernel.org
"""

As always, please let me know if there is anything I can help.


Thanks,
SJ


      reply	other threads:[~2025-09-16  5:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-16  3:35 SeongJae Park
2025-09-16  3:35 ` [PATCH 1/7] mm/damon/core: implement damon_initialized() function SeongJae Park
2025-09-16  3:35 ` [PATCH 2/7] mm/damon/stat: use damon_initialized() SeongJae Park
2025-09-16  3:35 ` [PATCH 3/7] mm/damon/reclaim: " SeongJae Park
2025-09-16  3:35 ` [PATCH 4/7] mm/damon/lru_sort: " SeongJae Park
2025-09-16  3:35 ` [PATCH 5/7] samples/damon/wsse: " SeongJae Park
2025-09-16  3:35 ` [PATCH 6/7] samples/damon/prcl: " SeongJae Park
2025-09-16  3:35 ` [PATCH 7/7] samples/damon/mtier: " SeongJae Park
2025-09-16  4:33 ` [PATCH 0/7] mm/damon: define and use DAMON initialization check function Andrew Morton
2025-09-16  5:54   ` SeongJae Park [this message]

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=20250916055458.118498-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=damon@lists.linux.dev \
    --cc=kernel-team@meta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox