DAMON development mailing list
 help / color / mirror / Atom feed
From: SJ Park <sj@kernel.org>
To: damon@lists.linux.dev
Cc: SJ Park <sj@kernel.org>
Subject: [False Bug] mm/damon/core: uninitialized boolean fields in damon_new_scheme()
Date: Sat, 24 Oct 2026 12:52:39 -0700	[thread overview]
Message-ID: <20261024195239.87431-1-sj@kernel.org> (raw)

Hello,


Sashiko reported a bug that I believe a false positive.  Sharing the report and
why I think it is false in usual mail format, to get help from more eyeballs.

Sashiko report:
https://sashiko.dev/#/bug/linux-b6222b1f-1973-4211-b3cc-048298d29abe

> In damon_new_scheme(), allocating a new Data Access Monitor (DAMON) scheme
> object without zero-initializing memory leaves the boolean control fields
> core_filters_allowed, core_filters_default_reject, and
> ops_filters_default_reject uninitialized.
> 
> Because the underlying allocator (via kmalloc_obj) does not clear memory,
> the allocated struct damos contains garbage values for any field not
> explicitly set. While most fields are initialized during creation, these
> three control fields are missed. Although they are typically populated
> later during kdamond startup,

So, no issue is really happening.

> leaving them uninitialized creates a window
> where early access through sysfs or debugfs inspection interfaces evaluates
> indeterminate state. This results in incorrect state exposure or unintended
> DAMON filtering logic if evaluated before the daemon fully initializes them.

I understand this is not a report for a real bug, but a recommendation to
initialize those fields to prevent possible future bugs.  I don't really feel
needs to do that for now.  In my opinion, doing something that not really
necessary in favor of preventing something could only confuse code readers and
hide real bugs.  We can revisit if any real bug happens.

> 
> // mm/damon/core.c:689-728
> struct damos *damon_new_scheme(struct damos_access_pattern *pattern,
> 			enum damos_action action,
> 			unsigned long apply_interval_us,
> 			struct damos_quota *quota,
> 			struct damos_watermarks *wmarks,
> 			int target_nid)
> {
> 	struct damos *scheme;
> 
> 	scheme = kmalloc_obj(*scheme);
> 	if (!scheme)
> 		return NULL;
> 	scheme->pattern = *pattern;
> 	< ... >
> 	INIT_LIST_HEAD(&scheme->core_filters);
> 	INIT_LIST_HEAD(&scheme->ops_filters);
> 	scheme->stat = (struct damos_stat){};
> 	< ... >
> 	scheme->migrate_dests = (struct damos_migrate_dests){};
> 	scheme->target_nid = target_nid;
> 
> 	return scheme;
> }


Thanks,
SJ

             reply	other threads:[~2026-10-24 19:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-24 19:52 SJ Park [this message]
2026-10-24 21:05 ` Ways to handle Sashiko bug reports for DAMON (was "Re: [False Bug] mm/damon/core: uninitialized boolean fields in damon_new_scheme()") 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=20261024195239.87431-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=damon@lists.linux.dev \
    /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