All of lore.kernel.org
 help / color / mirror / Atom feed
From: SeongJae Park <sj@kernel.org>
To: sashiko-bot@kernel.org
Cc: SeongJae Park <sj@kernel.org>,
	"Vineet Agarwal" <agarwal.vineet2006@gmail.com>,
	damon@lists.linux.dev
Subject: Re: [RFC PATCH] mm/damon/sysfs-schemes: fix double increment of nr_regions
Date: Tue, 12 May 2026 18:19:19 -0700	[thread overview]
Message-ID: <20260513011920.119183-1-sj@kernel.org> (raw)
In-Reply-To: <20260513000838.D0CFFC2BCB0@smtp.kernel.org>

On Wed, 13 May 2026 00:08:38 +0000 sashiko-bot@kernel.org wrote:

> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Critical] The patch fails to restore the documented 0-indexed ABI, leaving region directory names 1-indexed.

Not this patch's fault.  No real issue.

> - [Critical] Pre-existing: Use-After-Free and list corruption due to synchronous `kobject_put()` assumption.

I will work on this.

> - [Medium] Unbalanced `nr_regions` increment on `kobject_init_and_add()` failure causes a permanent state leak.

Not this patch's fault.  No real issue.

> --
> 
> commit 66d182db7d03e02c982ddd51e0ba311b2642559b
> Author: Vineet Agarwal <agarwal.vineet2006@gmail.com>
> 
> mm/damon/sysfs-schemes: fix double increment of nr_regions
> 
> This commit changes damos_sysfs_populate_region_dir() to use the already
> incremented value of nr_regions for naming new region directories,
> preventing the skipping of directory numbers.
> 
> > diff --git a/mm/damon/sysfs-schemes.c b/mm/damon/sysfs-schemes.c
> > index 622c3799db87b..5d966ac864193 100644
> > --- a/mm/damon/sysfs-schemes.c
> > +++ b/mm/damon/sysfs-schemes.c
> > @@ -2998,7 +2998,7 @@ void damos_sysfs_populate_region_dir(struct damon_sysfs_schemes *sysfs_schemes,
> >  	if (kobject_init_and_add(&region->kobj,
> >  				&damon_sysfs_scheme_region_ktype,
> >  				&sysfs_regions->kobj, "%d",
> > -				sysfs_regions->nr_regions++)) {
> > +				sysfs_regions->nr_regions)) {
> 
> Does this change the ABI from 0-indexed to 1-indexed? Since nr_regions is
> incremented just before kobject_init_and_add(), the first directory will be
> formatted with the value "1". The kernel documentation indicates these
> directories should start from 0.

Not a new behavior.  And it should be fine.  Users could reasonably deal with
it.  Refer to my first reply to the patch for more details.

> 
> >  		kobject_put(&region->kobj);
> 
> If kobject_init_and_add() fails here, we call kobject_put(&region->kobj) but
> do not decrement sysfs_regions->nr_regions. Will this permanently inflate the
> counter and cause subsequent directory names to skip numbers, since
> damon_sysfs_scheme_regions_rm_dirs() decrements the counter based on the
> remaining successfully added elements in the list?

Yes, and it is an old behavior, so nothing to blame for this patch.  Also same
to the 1-index, users should be able to reasonably handle it.

> 
> There might also be a pre-existing issue with the region list lifecycle. If
> damon_sysfs_scheme_regions_rm_dirs() iterates regions_list and calls
> kobject_put() on each region's kobj, does it assume the kobject release
> function will synchronously remove the region from the list?
> 
> If the release is delayed, for instance by external sysfs references or
> CONFIG_DEBUG_KOBJECT_RELEASE, the object could remain on regions_list. If
> damos_sysfs_populate_region_dir() then concurrently adds to regions_list
> with list_add_tail(), could the delayed release race and cause list
> corruption?
> 
> Could a subsequent call to damon_sysfs_scheme_regions_rm_dirs() traverse
> freed list nodes and call kobject_put() on zero-refcount objects if the
> release hasn't completed?

Good finding, I will work on this.


Thanks,
SJ

[...]

      reply	other threads:[~2026-05-13  1:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-11 19:12 [RFC PATCH] mm/damon/sysfs-schemes: fix double increment of nr_regions Vineet Agarwal
2026-05-12  0:45 ` SeongJae Park
2026-05-12  4:13   ` Vineet Agarwal
2026-05-13  0:08 ` sashiko-bot
2026-05-13  1:19   ` 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=20260513011920.119183-1-sj@kernel.org \
    --to=sj@kernel.org \
    --cc=agarwal.vineet2006@gmail.com \
    --cc=damon@lists.linux.dev \
    --cc=sashiko-bot@kernel.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.