[False Bug] mm/damon/core: uninitialized boolean fields in damon_new_scheme()

[False Bug] mm/damon/core: uninitialized boolean fields in damon_new_scheme()

[SJ Park]

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

Ways to handle Sashiko bug reports for DAMON (was "Re: [False Bug] mm/damon/core: uninitialized boolean fields in damon_new_scheme()")

[SJ Park]

On Sat, 24 Oct 2026 12:52:39 -0700 SJ Park <sj@kernel.org> wrote:

> 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.

I was about to keep doing this for all false positive reports.  I added a
comment on the Sashiko web ui for this report, closed it, and opened another
report that I think a false positive.  And I realized this is tedious and not
sustainable.

Actually nowadays I was taking time to think about more options.  Those include
but not limited to making more tooling and just sharing everything on the
mailing list and forget about the database.  I still find no best option.  And
I feel like I might spending too much time on this.

Maybe I'm thinking too much.  I will just do whatever I feel better to do at
the moment.  So I might share some Sashiko reports on mailing list or not.
Maybe I will start from just not sharing Sashiko reports on mailing list except
mentioning those on relevant patch descriptions including Closes: tag.  Please
don't expect any consistency in my way of Sashiko reports handling for now.


Thanks,
SJ