mm/damon/sysfs: kobject_del() directories that users can create/remove

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete fix: Missing kobject_del() in sysfs directory creation error paths leads to persistent -EEXIST collisions. --

commit 1c0329e17860c383f4ab90a119f917db75ecacee
Author: SeongJae Park <[email protected]>

mm/damon/sysfs: kobject_del() target, context and kdamond dirs

On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for target, context and kdamond directories by adding kobject_del() calls.

Fixes c951cd3b8901 ("mm/damon: implement a minimal stub for sysfs-based DAMON interface")

Cc <[email protected]> # 5.18.x

mm/damon/sysfs.c static void damon_sysfs_targets_rm_dirs(struct damon_sysfs_targets *targets) · line 336

Quoted 9 lines

mm/damon/sysfs.c +1 -0

index 2e95e3bac774d..d93f7919c3ca1 100644
@@ -333,6 +333,7 @@ static void damon_sysfs_targets_rm_dirs(struct damon_sysfs_targets *targets)
 
 	for (i = 0; i < targets->nr; i++) {
 		damon_sysfs_target_rm_dirs(targets_arr[i]);
+		kobject_del(&targets_arr[i]->kobj);

[Severity: High]
This isn't a regression introduced by this patch, but while you are fixing the -EEXIST name collisions in the rm_dirs() paths, are the same kobject_del() calls also needed in the error paths of the corresponding add_dirs() functions?

For example, in damon_sysfs_targets_add_dirs():

    mm/damon/sysfs.c:damon_sysfs_targets_add_dirs() {
        ...
            err = kobject_init_and_add(&target->kobj, ...);
            if (err)
                goto out;

            err = damon_sysfs_target_add_dirs(target);
            if (err)
                goto out;
        ...
    out:
        damon_sysfs_targets_rm_dirs(targets);
        kobject_put(&target->kobj);
        return err;
    }

If damon_sysfs_target_add_dirs() fails, kobject_put() is called without kobject_del(). Does this result in a lingering directory and a persistent -EEXIST if the user retries?

Similarly, in mm/damon/sysfs-schemes.c:damos_sysfs_populate_region_dir():

    mm/damon/sysfs-schemes.c:damos_sysfs_populate_region_dir() {
        ...
        if (kobject_init_and_add(&region->kobj,
                    &damon_sysfs_scheme_region_ktype,
                    &sysfs_regions->kobj, "%d",
                    sysfs_regions->nr_regions))
            goto out;
        if (damos_sysfs_region_add_dirs(region, ctx, r))
            goto out;
        ...
        sysfs_regions->nr_regions++;
        return;

    out:
        kobject_put(&region->kobj);
    }

If this fails, it returns without incrementing sysfs_regions->nr_regions. Could the next region processed in the loop then attempt to initialize with the exact same name string, immediately hitting -EEXIST and breaking the entire region population loop?

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing explicit kobject_del() on error paths in _add_dirs loops (Incomplete Fix).
- [High] Memory leak of stats and scheme structures on the error path of damon_sysfs_scheme_add_dirs(). --

commit ba4dfdbea398b3306e96fd3662e872e97251fbe9
Author: SeongJae Park <[email protected]>

mm/damon/sysfs: kobject_del() region dirs

This commit fixes directory creation failures caused by name conflicts when CONFIG_DEBUG_KOBJECT_RELEASE is enabled. It achieves this by adding missing kobject_del() calls to the region directories removal function.

Quoted 6 lines

mm/damon/sysfs.c +0 -0

index d93f7919c3ca1..f72e1e37df9d8 100644
@@ -107,8 +107,10 @@ static void damon_sysfs_regions_rm_dirs(struct damon_sysfs_regions *regions)
 	struct damon_sysfs_region **regions_arr = regions->regions_arr;

mm/damon/sysfs.c static void damon_sysfs_regions_rm_dirs(struct damon_sysfs_regions *regions) · line 116

Quoted 10 lines

mm/damon/sysfs.c +3 -1

 	int i;
 
-	for (i = 0; i < regions->nr; i++)
+	for (i = 0; i < regions->nr; i++) {
+		kobject_del(&regions_arr[i]->kobj);
 		kobject_put(&regions_arr[i]->kobj);
+	}
 	regions->nr = 0;
 	kfree(regions_arr);
 	regions->regions_arr = NULL;

[Severity: High]
This is a pre-existing issue, but the fix for this specific bug class seems incomplete as it misses initialization error paths. If a nested initialization fails after kobject_init_and_add() succeeds, the code jumps to an error path and calls kobject_put() without first calling kobject_del().

For example, in mm/damon/sysfs.c:damon_sysfs_targets_add_dirs():

out:

        damon_sysfs_targets_rm_dirs(targets);
        kobject_put(&target->kobj);
        return err;

This same pattern occurs in damon_sysfs_contexts_add_dirs(), damon_sysfs_kdamonds_add_dirs(), damon_sysfs_probes_add_dirs(), and damon_sysfs_schemes_add_dirs().

Does this cause the directory removal to be delayed asynchronously, meaning if userspace immediately retries the operation, it fails with an -EEXIST conflict?

[Severity: High]
This is also a pre-existing issue, but there appears to be a memory leak in the error path of damon_sysfs_scheme_add_dirs() in mm/damon/sysfs-schemes.c:

        err = damon_sysfs_scheme_set_tried_regions(scheme);
        if (err)
                goto put_tried_regions_out;
        return 0;

put_tried_regions_out:

        kobject_put(&scheme->tried_regions->kobj);
        scheme->tried_regions = NULL;
put_filters_watermarks_quotas_access_pattern_out:
        kobject_put(&scheme->ops_filters->kobj);

If damon_sysfs_scheme_set_tried_regions() fails, the code jumps to put_tried_regions_out and bypasses releasing the successfully created scheme->stats kobject. Since damon_sysfs_scheme_release() only frees the scheme struct and does not explicitly clean up lingering children, both the stats memory and the parent scheme memory are kept referenced.

Could this permanently leak both the stats and its parent scheme when triggered from userspace via sysfs configuration?

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Incorrect goto ladder in damon_sysfs_scheme_add_dirs causes an uninitialized pointer dereference and a memory leak of the stats kobject.
- [Medium] Missing kobject_del() in the out: error paths of *_add_dirs() loops leads to delayed sysfs directory removal and name collisions. --

commit a283ef4fe4b682b7b66cf9b57221cb6884b386cc
Author: SeongJae Park <[email protected]>

mm/damon/sysfs-schemes: kobject_del() scheme dirs

On CONFIG_DEBUG_KOBJECT_RELEASE enabled kernel, lack of kobject_del() could cause directories creation failures due to the name conflicts. Fix those issues for scheme directories by adding kobject_del() calls.

mm/damon/sysfs-schemes.c void damon_sysfs_schemes_rm_dirs(struct damon_sysfs_schemes *schemes) · line 2692

Quoted 12 lines

mm/damon/sysfs-schemes.c +1 -0

index 329cfd0bbe9f3..37cf6edb54f17 100644
@@ -2686,6 +2686,7 @@ void damon_sysfs_schemes_rm_dirs(struct damon_sysfs_schemes *schemes)
 
 	for (i = 0; i < schemes->nr; i++) {
 		damon_sysfs_scheme_rm_dirs(schemes_arr[i]);
+		kobject_del(&schemes_arr[i]->kobj);
 		kobject_put(&schemes_arr[i]->kobj);
 	}
 	schemes->nr = 0;

[Severity: Medium]
This isn't a bug introduced by this patch, but since we are fixing delayed sysfs directory removal here, do we have the same name collision vulnerability in the error paths of our *_add_dirs() loops?

If kobject_init_and_add() succeeds for a scheme, but damon_sysfs_scheme_add_dirs() fails, the error path drops the reference without calling kobject_del():

mm/damon/sysfs-schemes.c:damon_sysfs_schemes_add_dirs() {
    ...
		err = kobject_init_and_add(&scheme->kobj,
				&damon_sysfs_scheme_ktype, &schemes->kobj,
				"%d", i);
		if (err)
			goto out;
		err = damon_sysfs_scheme_add_dirs(scheme);
		if (err)
			goto out;
    ...
out:
	damon_sysfs_schemes_rm_dirs(schemes);
	kobject_put(&scheme->kobj);
	return err;
}

Under CONFIG_DEBUG_KOBJECT_RELEASE, would the delayed kobject_release callback leave the "%d" directory around temporarily, causing -EEXIST if the user immediately retries?

The identical pattern appears to exist in damon_sysfs_targets_add_dirs(), damon_sysfs_contexts_add_dirs(), and damon_sysfs_kdamonds_add_dirs().

[Severity: High]
This is a pre-existing issue, but there appears to be an uninitialized pointer dereference and a memory leak in the goto ladder of damon_sysfs_scheme_add_dirs().

If damon_sysfs_scheme_set_tried_regions() fails, we jump to put_tried_regions_out:

mm/damon/sysfs-schemes.c:damon_sysfs_scheme_add_dirs() {
    ...
	err = damon_sysfs_scheme_set_stats(scheme);
	if (err)
		goto put_filters_watermarks_quotas_access_pattern_out;
	err = damon_sysfs_scheme_set_tried_regions(scheme);
	if (err)
		goto put_tried_regions_out;
	return 0;

put_tried_regions_out:

	kobject_put(&scheme->tried_regions->kobj);
	scheme->tried_regions = NULL;
put_filters_watermarks_quotas_access_pattern_out:
    ...
}

Because scheme is allocated via kmalloc_obj() (which wraps kmalloc and doesn't zero memory), and the failing set_tried_regions() doesn't initialize scheme->tried_regions on error, doesn't scheme->tried_regions contain an uninitialized value here? Dereferencing it would cause a panic.

Additionally, this jump target falls through to put_filters_watermarks_quotas_access_pattern_out without ever calling kobject_put(&scheme->stats->kobj), so wouldn't the successfully allocated stats kobject be permanently leaked?

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Incomplete Fix / Missing kobject_del() in sysfs directory array teardown and error paths.
- [High] Memory leak of stats object in damon_sysfs_scheme_add_dirs() error path. --

commit 30488832bf0bcf915d5cbb6c2727b7cdedd8440e
Author: SeongJae Park <[email protected]>
Subject: mm/damon/sysfs-schemes: kobject_del() scheme region dirs

This commit addresses directory creation failures due to name conflicts when CONFIG_DEBUG_KOBJECT_RELEASE is enabled. It fixes the issue by adding missing kobject_del() calls before kobject_put() for scheme region directories during removal.

Link https://lore.kernel.org/[email protected] open here

mm/damon/sysfs-schemes.c static void damon_sysfs_scheme_regions_rm_dirs( · line 337

Quoted 9 lines

mm/damon/sysfs-schemes.c +1 -0

index 37cf6edb54f17..bf08e6e1f1635 100644
@@ -334,6 +334,7 @@ static void damon_sysfs_scheme_regions_rm_dirs(
 	list_for_each_entry_safe(r, next, &regions->regions_list, list) {
 		damos_sysfs_region_rm_dirs(r);
 		list_del(&r->list);
+		kobject_del(&r->kobj);

[Severity: High]
This is a pre-existing issue, but since we are adding kobject_del() here to fix the name collision bug, could there be similar omissions in other array teardown and error paths?

For instance, looking at damos_sysfs_probes_rm_dirs() which is called just above via damos_sysfs_region_rm_dirs():

mm/damon/sysfs-schemes.c:damos_sysfs_probes_rm_dirs() {
    ...
    for (i = 0; i < probes->nr; i++)
        kobject_put(&probes_arr[i]->kobj);
    ...
}

Does this code also omit kobject_del() during probes array teardown, potentially leaving directories in sysfs during array resizing?

Similarly, in several initialization loop error paths, such as in damos_sysfs_populate_region_dir():

mm/damon/sysfs-schemes.c:damos_sysfs_populate_region_dir() {
    ...
out:
    kobject_put(&region->kobj);
}

If aborting region population, does this path fail to call kobject_del(), breaking subsequent retries by leaving the directory name occupied?

Other functions like damon_sysfs_schemes_add_dirs(), damon_sysfs_targets_add_dirs(), and damon_sysfs_contexts_add_dirs() appear to have the same out path pattern omitting kobject_del() for partially added objects. Would it make sense to update those paths as well?

mm/damon/sysfs-schemes.c static void damon_sysfs_scheme_regions_rm_dirs( · line 338

Quoted 2 lines

mm/damon/sysfs-schemes.c +0 -0

 		kobject_put(&r->kobj);

[Severity: High]
This is a pre-existing issue, but I noticed a potential memory leak in an error path nearby.

In damon_sysfs_scheme_add_dirs(), the error cleanup sequence handles dropping the tried_regions and then ops_filters:

mm/damon/sysfs-schemes.c:damon_sysfs_scheme_add_dirs() {
    ...
put_tried_regions_out:
    kobject_put(&scheme->tried_regions->kobj);
    scheme->tried_regions = NULL;
put_filters_watermarks_quotas_access_pattern_out:
    kobject_put(&scheme->ops_filters->kobj);
    ...
}

Does this error path completely omit dropping the stats kobject?

The stats kobject is initialized prior to the failed call, so wouldn't skipping kobject_put(&scheme->stats->kobj) leak it permanently?

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing Kobject Deletion on Error Path
--

commit b01a934762aa810a11a4a01efdd70c41f7274410
Author: SeongJae Park <[email protected]>

mm/damon/sysfs-schemes: kobject_del() scheme quota goal dirs

This commit adds missing kobject_del() calls to the cleanup of scheme quota goal directories. This prevents directory creation failures due to name conflicts when CONFIG_DEBUG_KOBJECT_RELEASE is enabled.

mm/damon/sysfs-schemes.c static void damos_sysfs_quota_goals_rm_dirs( · line 1471

Quoted 13 lines

mm/damon/sysfs-schemes.c +3 -1

index 300930c2c5b3f..737638be84f15 100644
@@ -1465,8 +1465,10 @@ static void damos_sysfs_quota_goals_rm_dirs(
 	struct damos_sysfs_quota_goal **goals_arr = goals->goals_arr;
 	int i;
 
-	for (i = 0; i < goals->nr; i++)
+	for (i = 0; i < goals->nr; i++) {
+		kobject_del(&goals_arr[i]->kobj);
 		kobject_put(&goals_arr[i]->kobj);
+	}

[Severity: High]
This isn't a bug introduced by this patch, but since you are fixing missing kobject_del() calls here to prevent name collisions, do the error paths in the various *_add_dirs() functions need similar fixes?

If an error occurs after a successful kobject_init_and_add(), the error paths currently call kobject_put() without kobject_del(). This can leave the sysfs directory present until the object's reference count drops to zero and the delayed release runs, potentially causing a -EEXIST failure if a user retries the operation.

For example, looking at damon_sysfs_targets_add_dirs() in mm/damon/sysfs.c:

    err = damon_sysfs_target_add_dirs(target);
    if (err)
        goto out;
    ...
out:
    damon_sysfs_targets_rm_dirs(targets);
    kobject_put(&target->kobj);
    return err;

Could this leak the sysfs directory for target->kobj?

The identical pattern appears in several other error paths:
- damon_sysfs_contexts_add_dirs() in mm/damon/sysfs.c
- damon_sysfs_kdamonds_add_dirs() in mm/damon/sysfs.c
- damon_sysfs_schemes_add_dirs() in mm/damon/sysfs-schemes.c
- damos_sysfs_populate_region_dir() in mm/damon/sysfs-schemes.c

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing kobject_del() calls on the error paths of numerous _add_dirs initialization loops, leading to delayed-release name conflicts. --

commit 635dc3a5238027dd7ff5a0100c509a12408d26da
Author: SeongJae Park <[email protected]>

mm/damon/sysfs-schemes: kobject_del() scheme action destination dirs

This commit adds kobject_del() calls to the scheme action destination directories cleanup routine. This prevents directory creation failures due to name conflicts when CONFIG_DEBUG_KOBJECT_RELEASE is enabled.

Quoted 5 lines

mm/damon/sysfs-schemes.c +0 -0

index 737638be84f15..108f6de32f8c1 100644

mm/damon/sysfs-schemes.c static void damos_sysfs_dests_rm_dirs( · line 2156

Quoted 10 lines

mm/damon/sysfs-schemes.c +3 -1

@@ -2148,8 +2148,10 @@ static void damos_sysfs_dests_rm_dirs(
 	struct damos_sysfs_dest **dests_arr = dests->dests_arr;
 	int i;
 
-	for (i = 0; i < dests->nr; i++)
+	for (i = 0; i < dests->nr; i++) {
+		kobject_del(&dests_arr[i]->kobj);
 		kobject_put(&dests_arr[i]->kobj);
+	}
 	dests->nr = 0;
 	kfree(dests_arr);

[Severity: High]
This is a pre-existing issue, but should the error paths in the various _add_dirs() functions also be updated to call kobject_del() to prevent the same name conflicts?

When kobject_init_and_add() succeeds, the kobject is added to sysfs. If a subsequent initialization step fails, the error paths call kobject_put() without calling kobject_del() first. Under CONFIG_DEBUG_KOBJECT_RELEASE, kobject_put() schedules delayed cleanup, so the sysfs directory remains visible until the delayed release completes. If the user immediately retries, kobject_init_and_add() will fail with an -EEXIST name collision.

For example, in mm/damon/sysfs.c:damon_sysfs_targets_add_dirs():

        err = kobject_init_and_add(&target->kobj, ...);
        if (err)
                goto out;

        err = damon_sysfs_target_add_dirs(target);
        if (err)
                goto out;

        ...

out:

        damon_sysfs_targets_rm_dirs(targets);
        kobject_put(&target->kobj);
        return err;

Does this series also need to add kobject_del() calls to the error paths of these functions:
- damon_sysfs_targets_add_dirs() in mm/damon/sysfs.c
- damon_sysfs_probes_add_dirs() in mm/damon/sysfs.c
- damon_sysfs_contexts_add_dirs() in mm/damon/sysfs.c
- damon_sysfs_kdamonds_add_dirs() in mm/damon/sysfs.c
- damon_sysfs_schemes_add_dirs() in mm/damon/sysfs-schemes.c
- damos_sysfs_populate_region_dir() in mm/damon/sysfs-schemes.c

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing kobject_del() in damos_sysfs_probes_rm_dirs() leading to sysfs name conflicts.
- [High] Missing kobject_del() on error paths in _add_dirs array-initialization loops causing -EEXIST name conflicts on retries. --

commit d2e0c9ec8c59c96ff7123c668d926efc99e5b382
Author: SeongJae Park <[email protected]>

mm/damon/sysfs: kobject_del() probe filter dirs

This commit adds kobject_del() calls in damon_sysfs_filters_rm_dirs() before kobject_put(). This prevents directory creation failures caused by name conflicts when CONFIG_DEBUG_KOBJECT_RELEASE is enabled.

mm/damon/sysfs.c static void damon_sysfs_filters_rm_dirs(struct damon_sysfs_filters *filters) · line 966

Quoted 13 lines

mm/damon/sysfs.c +3 -1

index f72e1e37df9d8..04725ff3d9f3c 100644
@@ -960,8 +960,10 @@ static void damon_sysfs_filters_rm_dirs(struct damon_sysfs_filters *filters)
 	struct damon_sysfs_filter **filters_arr = filters->filters_arr;
 	int i;
 
-	for (i = 0; i < filters->nr; i++)
+	for (i = 0; i < filters->nr; i++) {
+		kobject_del(&filters_arr[i]->kobj);
 		kobject_put(&filters_arr[i]->kobj);
+	}

[Severity: High]
This isn't a bug introduced by this patch, but should this fix also be applied to other similar cleanup loops?

Looking at mm/damon/sysfs-schemes.c:damos_sysfs_probes_rm_dirs():

	for (i = 0; i < probes->nr; i++)
		kobject_put(&probes_arr[i]->kobj);

This iterates over probes_arr and calls kobject_put() without kobject_del(), mirroring the exact bug this patch addresses. When damos_sysfs_probes_add_dirs() fails and calls this cleanup function, does this delay directory removal and cause a -EEXIST collision if retried?

[Severity: High]
This is a pre-existing issue, but do the error paths in the _add_dirs array initialization loops also need kobject_del() calls?

If a nested setup function fails after a successful kobject_init_and_add(), the error path drops the reference but misses a preceding kobject_del().

For example, in mm/damon/sysfs.c:damon_sysfs_targets_add_dirs():

out:

	damon_sysfs_targets_rm_dirs(targets);
	kobject_put(&target->kobj);
	return err;

If damon_sysfs_target_add_dirs() fails, the target is not yet in targets_arr. Does putting the kobject without a preceding kobject_del() leave the successfully added sysfs directory lingering, leading to -EEXIST name conflicts on retries?

Similar error paths missing kobject_del() appear in:
- mm/damon/sysfs.c:damon_sysfs_contexts_add_dirs()
- mm/damon/sysfs.c:damon_sysfs_kdamonds_add_dirs()
- mm/damon/sysfs.c:damon_sysfs_schemes_add_dirs()
- mm/damon/sysfs.c:damon_sysfs_probes_add_dirs()
- mm/damon/sysfs-schemes.c:damos_sysfs_populate_region_dir()

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] The patch adds kobject_del() to damon_sysfs_probes_rm_dirs() to fix sysfs name collisions caused by delayed kobject releases, but misses the exact same flaw on the error paths of damon_sysfs_probes_add_dirs() and multiple other array-building functions. This leaves the system vulnerable to -EEXIST failures upon retry after an error. --

commit 4a5efc2733f009261a15fd64a4d901ca19499bb5
Author: SeongJae Park <[email protected]>

mm/damon/sysfs: kobject_del() probe dirs

This commit fixes a directory creation failure caused by name conflicts when CONFIG_DEBUG_KOBJECT_RELEASE is enabled. It adds missing kobject_del() calls during the removal of probe directories.

mm/damon/sysfs.c static void damon_sysfs_probes_rm_dirs( · line 1142

Quoted 9 lines

mm/damon/sysfs.c +1 -0

index 04725ff3d9f3c..04ca0a34e1206 100644
@@ -1139,6 +1139,7 @@ static void damon_sysfs_probes_rm_dirs(
 
 	for (i = 0; i < probes->nr; i++) {
 		damon_sysfs_probe_rm_dirs(probes_arr[i]);
+		kobject_del(&probes_arr[i]->kobj);

[Severity: Medium]
This is a pre-existing issue, but it looks like the same lack of kobject_del() on error paths could cause name collisions upon retry.

For example, if damon_sysfs_probe_add_dirs() fails inside damon_sysfs_probes_add_dirs(), the error path drops the probe by calling kobject_put() without kobject_del():

mm/damon/sysfs.c:damon_sysfs_probes_add_dirs() {
    ...
		err = damon_sysfs_probe_add_dirs(probe);
		if (err) {
			kobject_put(&probe->kobj);
			damon_sysfs_probes_rm_dirs(probes);
			return err;
		}
    ...
}

Under CONFIG_DEBUG_KOBJECT_RELEASE, if userspace immediately retries the operation after an error, won't kobject_init_and_add() fail with -EEXIST due to a name collision with the lingering directory?

Should we also add synchronous sysfs deletion via kobject_del() to these similar error paths?
- mm/damon/sysfs.c:damon_sysfs_targets_add_dirs()
- mm/damon/sysfs.c:damon_sysfs_contexts_add_dirs()
- mm/damon/sysfs.c:damon_sysfs_kdamonds_add_dirs()
- mm/damon/sysfs-schemes.c:damon_sysfs_schemes_add_dirs()

DAMON sysfs interface allows users to create and remove arbitrary number of directories on sysfs, using a few files having 'nr_' prefix. For example, 'nr_kdamonds'. When the user writes a number 'N' to the files, directories having name starting from '0' to 'N - 1' are created in the same directory. The pre-existing number-named directories are removed before creating the new directories.

For the removal of the existing directories, DAMON sysfs interface use only kobject_put(). Because DAMON sysfs interface is the only kernel component that manages the directories, there is no problem in normal situations. However, if CONFIG_DEBUG_KOBJECT_RELEASE is enabled, the removal of dirs are delayed. Let's suppose a user writes a non-zero number to the 'nr_*' files while there are pre-existing number-named directories, on the config enabled kernel. DAMON sysfs interface decreases the reference counts of the existing directories and immediately creates new directories. Because the removal of the sysfs directories is delayed, it shows some pre-existing directories of the same names when it tries to create the new directories, and fails.

For example, the issue can be triggered like below:

    # grep DEBUG_KOBJECT_RELEASE /boot/config-$(uname -r)
    CONFIG_DEBUG_KOBJECT_RELEASE=y
    # ls
    nr_kdamonds
    # echo 1 > nr_kdamonds
    # echo 1 > nr_kdamonds
    bash: echo: write error: File exists
    # dmesg
    [...]
    [  300.880458] kobject: kobject_add_internal failed for 0 with -EEXIST, don't try to register things with the same name in the same directory.
    [...]

This doesn't cause catastrophic issues like kernel panics or memory corruptions. Users can work around by removing all directories first (write 0 to the nr_* files) and then create new directories after confirming the old directories are gone. But, this is definitely a bug that causes a bad user experience.

Fix the issues by calling kobject_del() before creating new directories.