mm-damon-sysfs-schemes-read-sysfs_filter-addr_range-only-once.patch removed from -mm tree

The quilt patch titled

     Subject: mm/damon/sysfs-schemes: read sysfs_filter->addr_range only once

has been removed from the -mm tree. Its filename was
mm-damon-sysfs-schemes-read-sysfs_filter-addr_range-only-once.patch

This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

------------------------------------------------------
From: SJ Park <[email protected]>
Subject: mm/damon/sysfs-schemes: read sysfs_filter->addr_range only once
Date: Mon, 14 Sep 2026 07:23:18 -0700

Patch series "mm/damon: move damos filter range arguments validation to core".

DAMOS filter range arguments are being validated in the DAMON sysfs interface. Some of those have minor time-of-check to time-of-use (TOCTOU) bugs. In future, other callers might have duplicated validations with similar bugs.

Fix the bugs and further refactor the code to move the validation to the core layer. Also add kunit test cases for the validations.

Patches 1 and 2 fix the existing TOCTOU bugs. Patches 3 and 4 adds the validation in the core layer. Patch 5 drops the replicated validation in DAMON sysfs interface. Patch 6 further cleanup the code. Patches 7 and 8 extends kunit tests to test the validation.

This patch (of 8):

DAMON sysfs interface reads the user-provided address range arguments for addr type DAMOS filter twice. Once for validation, and once again for assignments to the variable that will be passed to the core layer. If the user updates the argument in parallel, an invalid address range could be passed to the core layer. Avoid it by doing the assignments first, and then validating the assigned variables before passing those to the core layer.

User impact of the bug should be trivial. From the core layer's perspective, the invalid address range is not really invalid. It just works as having a weird address range. No critical issues such as a crash or a leak could happen. And sane users ain't do such parallel arguments update anyway. If they do, such racy behavior is arguably somewhat expected and deserved. That said, there is no reason to keep such races.

---

 mm/damon/sysfs-schemes.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

@@ -2831,12 +2831,12 @@ static int damon_sysfs_add_scheme_filter
 				return err;
 			}
 		} else if (filter->type == DAMOS_FILTER_TYPE_ADDR) {
-			if (sysfs_filter->addr_range.end <
-					sysfs_filter->addr_range.start) {
+			filter->addr_range = sysfs_filter->addr_range;
+			if (filter->addr_range.end <
+					filter->addr_range.start) {
 				damos_destroy_filter(filter);
 				return -EINVAL;
 			}
-			filter->addr_range = sysfs_filter->addr_range;
 		} else if (filter->type == DAMOS_FILTER_TYPE_TARGET) {
 			filter->target_idx = sysfs_filter->target_idx;
 		} else if (filter->type == DAMOS_FILTER_TYPE_HUGEPAGE_SIZE) {

_

Patches currently in -mm which might be from [email protected] are

mm-damon-core-introduce-damos_quota_goal-complement.patch mm-damon-core-add-complement-argument-to-damos_new_quota_goal.patch mm-damon-sysfs-schemes-support-quota-goal-complement-flag.patch mm-damon-tests-core-kunit-test-quota_goal-complement-commit.patch selftests-damon-sysfssh-test-quota-goal-complement-flag-file.patch docs-mm-damon-design-document-damos-quota-goal-complement-flag.patch docs-admin-guide-mm-damon-usage-update-for-quota-goal-complement-file.patch docs-abi-damon-update-for-quota-goal-metric-complement-sysfs-file.patch