linux-kernel - Re: [PATCH 0/7] mm/damon: define and use DAMON initialization check function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250916055458.118498-1-sj@kernel.org>
Date: Mon, 15 Sep 2025 22:54:57 -0700
From: SeongJae Park <sj@...nel.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: SeongJae Park <sj@...nel.org>,
	damon@...ts.linux.dev,
	kernel-team@...a.com,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
Subject: Re: [PATCH 0/7] mm/damon: define and use DAMON initialization check function

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

> On Mon, 15 Sep 2025 20:35:04 -0700 SeongJae Park <sj@...nel.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