From nobody Sat Jul 25 18:05:55 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6A6C5352021; Wed, 15 Jul 2026 03:10:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085013; cv=none; b=oI89p5RqFICx2VWUIa6fdoED9c/4r72MXl6I4buQY86/nkRr8yhWiuTwDTw5mHZD8zcZ8yjX/KXMLTSrM8cQXGSvYIIPWPPtAEdklrQBfIDHWjD00jidQ9E9PtZEH5DtBZv2rYLWAivuuo5/NXnlncpSSVV6ddSESkexRKsak/8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085013; c=relaxed/simple; bh=uommVYjcgv1yUQymXHLWitvXUy8HlVyIq9wOy8obzmw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=GR3pj4huNzOdlZCpk+pdRmqzZAKkj+8fg3/pHJc/DrHZ5Ck1Jv1Ij8IcEo7KgGzc6U7lQPD9l/MJDFjixL7na6diNe84srdvZnoEh08E6lwJ7Ow+mNHJUeUygPytgKg14mfwhId054ZPDeiSm1fyROsJRP9xm+7jRRu8X/h/WDk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EJVol9+h; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EJVol9+h" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 227411F00A3D; Wed, 15 Jul 2026 03:10:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784085012; bh=Q9KjTQrAluw9j+QP6j3O8xbCeroVnCVq06v65dUktLw=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EJVol9+hnUXr2MkTGjNeeTnr9zgtGiH5lhzdGvYd5zJCaySf6cSWxfS2J3u35p82W aN7k6jW22+/k8MA0TjfYViaGj0UAvcbe6CKpmzA1dp9E3K6YhK2ZdiYbQ0X7OM0XuI dl/ev0OzfVJ8SUjSrzFznTDRFzs+1NpfgomlPcRCKQO/u+Dh8IWCUwhA5ueQLIzG6L 5paLEU0Opf1bam6u3Q2eugM68ni7424Ag6gCP5C41ySgpo22WQZ3rGKa8y344o1L8Y xvkVkSdvWNiU52kuxdqXM20DRFUDW71jWFix1mRQCU7heAgrJ2k910rqfYpb0g9ee5 cDRNSdDPvfA/Q== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v1.1 1/6] mm/damon/core: avoid infinite kdamond_merge_regions() internal loop Date: Tue, 14 Jul 2026 20:09:56 -0700 Message-ID: <20260715031002.108504-2-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260715031002.108504-1-sj@kernel.org> References: <20260715031002.108504-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamond_merge_regions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged. The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If max_thres is larger than UINT_MAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely. Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold. This issue is unlikely to occur in real world, since having the max_thres higher than UINT_MAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260709145425.96247-1-sj@kernel.org Fixes: 310d6c15e910 ("mm/damon/core: merge regions aggressively when max_nr= _regions is unmet") Cc: # 6.10.x Signed-off-by: SJ Park --- mm/damon/core.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index 6c4215cc809ec..603b102ff80f9 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3372,7 +3372,7 @@ static void kdamond_merge_regions(struct damon_ctx *c= , unsigned int threshold, =20 max_thres =3D c->attrs.aggr_interval / (c->attrs.sample_interval ? c->attrs.sample_interval : 1); - do { + while (true) { nr_regions =3D 0; damon_for_each_target(t, c) { damon_merge_regions_of(t, threshold, sz_limit, c, @@ -3380,9 +3380,14 @@ static void kdamond_merge_regions(struct damon_ctx *= c, unsigned int threshold, nr_regions +=3D damon_nr_regions(t); } count_age =3D false; - threshold =3D max(1, threshold * 2); - } while (nr_regions > c->attrs.max_nr_regions && - threshold / 2 < max_thres); + if (nr_regions <=3D c->attrs.max_nr_regions || + max_thres <=3D threshold) + break; + if (threshold < max_thres / 2) + threshold =3D max(1, threshold * 2); + else + threshold =3D max_thres; + } } =20 #ifdef CONFIG_DAMON_DEBUG_SANITY --=20 2.47.3 From nobody Sat Jul 25 18:05:55 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E7E6D36215B; Wed, 15 Jul 2026 03:10:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085014; cv=none; b=Mk2hfcWqe0sOjJGJqlOD+QdLT0nQ0+cI3nWLpERXc/fi77FtrTaxi+JaKtmrgJuH/GmRrDrHQcYTedqkf+he34+hKg24R/zACfAmii8OPaNpphqRw+B3PbboUcDFm+aLjplyJL/AKuizpMFhskjZ/3FE0xclx1k/4jZPUe8vpwk= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085014; c=relaxed/simple; bh=oa/Api2m6C6paRLqdcrPW1anhL7pYe2ZAUU7W+EEjsg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mtZgv8XsqNsbFU9U3FkTvlK40w1dmd88umaZ7rDStwam2LLPczVjYqZo3cEcDIKsiX8jkFN40iw/Q7mcwCXXrKIzkovQ/pa0GlsF4n0jeT6xXopEOrUwMXQXVAKRseOg0mat09PtZGfxxXl7RUFfmeAMG3eIt6yEkg9L0KV3IaI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hdwQejIq; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hdwQejIq" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 76D9A1F00A3E; Wed, 15 Jul 2026 03:10:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784085012; bh=Csk2Bs95SoFAJpGitaPFL2lXi5OcS5tAvUkrHnWNWRA=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=hdwQejIqjSXVn6ZOjjgrAJxWrno8uipge6ifEx+jog45KonTkm+btFthmQAKpVfGY 0lJqAjEeCtWVkb3LH5/9Rh3jnbfuu/DkUFS5DORwogllwKC71kxDCU4xDTxYtyxG/8 TwHmM9R05lRNvUclDVUams2YNzRAzh6erkKutdnASE02fLexoXyXpg7rKd8/2lOYqu DWMfD6VbNrS+gZHEUeuwMlDEWMMtwZoAkVRjTdK2XBtV9TUo8+/sZIuMXaqs/PGXUb jI6CmAHHekvsgEt0luLBay+leef/Kv8/pd601qEHt3iU61R8KZ7LNGoN8HmQXIEl5o fhuANby88ZDVQ== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, Brendan Higgins , David Gow , SeongJae Park , damon@lists.linux.dev, kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v1.1 2/6] mm/damon/tests/core-kunit: catch test failure in test_merge_regions_of() Date: Tue, 14 Jul 2026 20:09:57 -0700 Message-ID: <20260715031002.108504-3-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260715031002.108504-1-sj@kernel.org> References: <20260715031002.108504-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" KUNIT_EXPECT_EQ() does not abort the execution of test code when the expectation is not met. But damon_test_merge_regions_of() code after its initial KUNIT_EXPECT_EQ() call assumes the expectation is met. It does a per-region test with a hard-coded number of regions that is correct only if the expectation was met. As a result, __nth_region_of() could return NULL, and the test code can dereference NULL pointers. Fix the issue by catching the expectation failure and skip the per-region tests. The user impact on realistic setups should be negligible, as it is a unit test. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260710144937.26981-1-sj@kernel.org Fixes: 17ccae8bb5c9 ("mm/damon: add kunit tests") Cc: # 5.15.x Signed-off-by: SJ Park --- mm/damon/tests/core-kunit.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/mm/damon/tests/core-kunit.h b/mm/damon/tests/core-kunit.h index 485472ddebd19..eba643762132f 100644 --- a/mm/damon/tests/core-kunit.h +++ b/mm/damon/tests/core-kunit.h @@ -260,11 +260,14 @@ static void damon_test_merge_regions_of(struct kunit = *test) damon_merge_regions_of(t, 9, 9999, ctx, true); /* 0-112, 114-130, 130-156, 156-170, 170-230, 230-10170 */ KUNIT_EXPECT_EQ(test, damon_nr_regions(t), 6u); + if (damon_nr_regions(t) !=3D 6) + goto out; for (i =3D 0; i < 6; i++) { r =3D __nth_region_of(t, i); KUNIT_EXPECT_EQ(test, r->ar.start, saddrs[i]); KUNIT_EXPECT_EQ(test, r->ar.end, eaddrs[i]); } +out: damon_free_target(t); damon_destroy_ctx(ctx); } --=20 2.47.3 From nobody Sat Jul 25 18:05:55 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A3C0B37A4AF; Wed, 15 Jul 2026 03:10:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085014; cv=none; b=UJQctPVwjFY7/B4y35dTUK9QRpvdPO7+tzuOfCqTAQMHyiIkWXOEHfz8W3dLz0hgz9p+thHU0j9ig+n/CNp9ho7VDs3nmIVoX7ecqqt5Jb4Ofo6l4KvCORsBB4UkvteAQNnhhrkrQEnvMsrg0mg76e8tdifgIVgfXve7HxK2CKs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085014; c=relaxed/simple; bh=vZYyX+a12usp29MAJtKmwcAKj0175PGkEUqyahpcjCo=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=JtNzrKdcmt6tgfVbewieFYK1oZZQ9BVwuqSi+0a9pbvYZ24pYlZRtcKQzxQuxU18jp2V8ptTiZIm3PhNJI2c0CreNLt9raLRc5stBZxIVSFJQzOWxojgSDEaUJ8hH67ZvF7xbDyYlaDyGLv9rcRT3IhQcTmWs2FS3foVQStfKeo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=AzNtQ1lY; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="AzNtQ1lY" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 00CF41F00A3F; Wed, 15 Jul 2026 03:10:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784085013; bh=dZ7Hztpv9AG3ym6rD1iyRftJCr5BqjDTKMYF5vaHn/Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=AzNtQ1lY5/HLdHtijvU/aYjoir0gb4du3YuUZmu74pb5RWlPnYQaQwxROd31rSGYP sKz05Te5tg5zmZmeBsDsRzkliw2OYnSGNFOGmQHaSkyJSo1Q6yssfTEJT5CLlxMKjb KXVKVu9aD7hJAxOKJljpgcYMASoDuLCF4WgZM1cr4U3HYGzPSoNKlHwCkU6Lnsdhwb +gwJkxoxIAgr3LLj7omr2wJZlDjfcpGVuu7WtUQPilZh8GL2PqtR+b1++7D5Jpg48+ 7L7hxUBEUwEK43oiuoBTnmsmZdoObt2tDS6gFbxycoj+L6S24iDtqvcyq6DmoaRZee suTccnmomWBDQ== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, Fernand Sieber , Leonard Foerster , SeongJae Park , Shakeel Butt , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v1.1 3/6] mm/damon/vaddr: drop last same folio access check optimization Date: Tue, 14 Jul 2026 20:09:58 -0700 Message-ID: <20260715031002.108504-4-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260715031002.108504-1-sj@kernel.org> References: <20260715031002.108504-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The optimization can race when multiple kdamonds are running. Meanwhile, the impact of the optimization is quite doubtful. Just remove it. The user impact of the issue should be quite trivial. After all, the race can happen only when the user intentionally setup DAMON in the way. Even if it happens, it would be rare and only degrade the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race possibility was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory= address spaces") Cc: # 5.15.x Signed-off-by: SJ Park --- mm/damon/vaddr.c | 33 ++++++--------------------------- 1 file changed, 6 insertions(+), 27 deletions(-) diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c index d10b8042adb5b..d487b7a4a1042 100644 --- a/mm/damon/vaddr.c +++ b/mm/damon/vaddr.c @@ -383,8 +383,6 @@ static void damon_va_prepare_access_checks(struct damon= _ctx *ctx) } =20 struct damon_young_walk_private { - /* size of the folio for the access checked virtual memory address */ - unsigned long *folio_sz; bool young; }; =20 @@ -411,7 +409,6 @@ static int damon_young_pmd_entry(pmd_t *pmd, unsigned l= ong addr, mmu_notifier_test_young(walk->mm, addr)) priv->young =3D true; - *priv->folio_sz =3D HPAGE_PMD_SIZE; huge_out: spin_unlock(ptl); return 0; @@ -430,7 +427,6 @@ static int damon_young_pmd_entry(pmd_t *pmd, unsigned l= ong addr, if (pte_young(ptent) || !folio_test_idle(folio) || mmu_notifier_test_young(walk->mm, addr)) priv->young =3D true; - *priv->folio_sz =3D folio_size(folio); out: pte_unmap_unlock(pte, ptl); return 0; @@ -458,7 +454,6 @@ static int damon_young_hugetlb_entry(pte_t *pte, unsign= ed long hmask, if (pte_young(entry) || !folio_test_idle(folio) || mmu_notifier_test_young(walk->mm, addr)) priv->young =3D true; - *priv->folio_sz =3D huge_page_size(h); =20 folio_put(folio); =20 @@ -470,11 +465,9 @@ static int damon_young_hugetlb_entry(pte_t *pte, unsig= ned long hmask, #define damon_young_hugetlb_entry NULL #endif /* CONFIG_HUGETLB_PAGE */ =20 -static bool damon_va_young(struct mm_struct *mm, unsigned long addr, - unsigned long *folio_sz) +static bool damon_va_young(struct mm_struct *mm, unsigned long addr) { struct damon_young_walk_private arg =3D { - .folio_sz =3D folio_sz, .young =3D false, }; =20 @@ -494,28 +487,17 @@ static bool damon_va_young(struct mm_struct *mm, unsi= gned long addr, * r the region to be checked */ static void __damon_va_check_access(struct mm_struct *mm, - struct damon_region *r, bool same_target) + struct damon_region *r) { - static unsigned long last_addr; - static unsigned long last_folio_sz =3D PAGE_SIZE; - static bool last_accessed; + bool accessed; =20 if (!mm) { damon_update_region_access_rate(r, false); return; } =20 - /* If the region is in the last checked page, reuse the result */ - if (same_target && (ALIGN_DOWN(last_addr, last_folio_sz) =3D=3D - ALIGN_DOWN(r->sampling_addr, last_folio_sz))) { - damon_update_region_access_rate(r, last_accessed); - return; - } - - last_accessed =3D damon_va_young(mm, r->sampling_addr, &last_folio_sz); - damon_update_region_access_rate(r, last_accessed); - - last_addr =3D r->sampling_addr; + accessed =3D damon_va_young(mm, r->sampling_addr); + damon_update_region_access_rate(r, accessed); } =20 static unsigned int damon_va_check_accesses(struct damon_ctx *ctx) @@ -524,15 +506,12 @@ static unsigned int damon_va_check_accesses(struct da= mon_ctx *ctx) struct mm_struct *mm; struct damon_region *r; unsigned int max_nr_accesses =3D 0; - bool same_target; =20 damon_for_each_target(t, ctx) { mm =3D damon_get_mm(t); - same_target =3D false; damon_for_each_region(r, t) { - __damon_va_check_access(mm, r, same_target); + __damon_va_check_access(mm, r); max_nr_accesses =3D max(r->nr_accesses, max_nr_accesses); - same_target =3D true; } if (mm) mmput(mm); --=20 2.47.3 From nobody Sat Jul 25 18:05:55 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C021F38B7B0; Wed, 15 Jul 2026 03:10:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085015; cv=none; b=SbTH5TwLY00fSZvoz86+egUiIPmehadgRnjj+D2av10tQhj3rZyGxdsLp3id6po64Eb65lH0WstkP42lz9oGF5Tv5rgBsig16ULIh9s26H4VaKGjDHTZAz/N5HpIl21PCvL2hcu5eLPhHnzn4vzwg8VBgmPIUJH3HULEAUrjA2w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085015; c=relaxed/simple; bh=5ScejZ7WR20mP7M32rQjyj8bSoc3hvLkckL0qcqy7ww=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=HkdClye5V+LOEyCY53SoNLPH3pJNUQLvlxQm49/Rf1GMHxbnSQP3IDpWJyqzDJBXnXuhiB09wRHkQHt5aQ3FXYmYpnnrtD9nTxr/xP2frTnU3hY0t7tDWX98/NdsEAlRT006nmJ0J8yNogwQn+Zg28/VOC//COur1G1r2udQJTU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YudR2/bT; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="YudR2/bT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 71E8A1F00AC4; Wed, 15 Jul 2026 03:10:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784085013; bh=MTFa+hpzXfcfyF1zP3rvNz2Fhu2Cffg36gE6sioOaYQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=YudR2/bTwWI1q0jPRkBPsypksgdoLG99nsOcGAc2rvgKmzRrDGJ8Y4vCjweAbYhfF 71mbB3KVaTx8nG5+eejlb3GQMK7sUXBkQz7gHem0imzFpOVUI2qOldKO6sGBqlqjbv zFhaqe0Yv/FDxWZnPNK9/cpvNQ1xD0HKEm/EwQ+9RSJTadu1WvkKCq+vL1Nh+2P1F2 bCyKySHFh6RhNV35zRnTe8tQ4yXA0pXbR8Mg3Tf4xam45pTE52UV2F75sDwjJjPqsR dr6FprrgXxA3NDVFBpFg+/DSYhSANBXjxIChDE/gueZNE+uVu+dVf63UkqdU32R/LE mUte1/XW+dS9w== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v1.1 4/6] mm/damon/paddr: drop last same folio access check reuse optimization Date: Tue, 14 Jul 2026 20:09:59 -0700 Message-ID: <20260715031002.108504-5-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260715031002.108504-1-sj@kernel.org> References: <20260715031002.108504-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" It can race when multiple kdamonds are being used. The problem from the race is doubtful, but the gain from the optimization is also doubtful. Simply drop the optimization in favor of code simplicity. The user impact is doubtfully trivial. After all, this kind of interference can happen only by intentional user setup. Even if it happens, it will be rare, and the consequence is degradation of the best-effort monitoring results. No critical consequences like kernel panic or memory corruption happen. The race was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260621204050.10993-1-sj@kernel.org Fixes: a28397beb55b ("mm/damon: implement primitives for physical address s= pace monitoring") Cc: # 5.16.x Signed-off-by: SJ Park --- mm/damon/paddr.c | 20 ++++---------------- 1 file changed, 4 insertions(+), 16 deletions(-) diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c index b85f88a7a38f4..e4f98d67461f5 100644 --- a/mm/damon/paddr.c +++ b/mm/damon/paddr.c @@ -65,7 +65,7 @@ static void damon_pa_prepare_access_checks(struct damon_c= tx *ctx) } } =20 -static bool damon_pa_young(phys_addr_t paddr, unsigned long *folio_sz) +static bool damon_pa_young(phys_addr_t paddr) { struct folio *folio =3D damon_get_folio(PHYS_PFN(paddr)); bool accessed; @@ -74,7 +74,6 @@ static bool damon_pa_young(phys_addr_t paddr, unsigned lo= ng *folio_sz) return false; =20 accessed =3D damon_folio_young(folio); - *folio_sz =3D folio_size(folio); folio_put(folio); return accessed; } @@ -82,23 +81,12 @@ static bool damon_pa_young(phys_addr_t paddr, unsigned = long *folio_sz) static void __damon_pa_check_access(struct damon_region *r, unsigned long addr_unit) { - static phys_addr_t last_addr; - static unsigned long last_folio_sz =3D PAGE_SIZE; - static bool last_accessed; + bool accessed; phys_addr_t sampling_addr =3D damon_pa_phys_addr( r->sampling_addr, addr_unit); =20 - /* If the region is in the last checked page, reuse the result */ - if (ALIGN_DOWN(last_addr, last_folio_sz) =3D=3D - ALIGN_DOWN(sampling_addr, last_folio_sz)) { - damon_update_region_access_rate(r, last_accessed); - return; - } - - last_accessed =3D damon_pa_young(sampling_addr, &last_folio_sz); - damon_update_region_access_rate(r, last_accessed); - - last_addr =3D sampling_addr; + accessed =3D damon_pa_young(sampling_addr); + damon_update_region_access_rate(r, accessed); } =20 static unsigned int damon_pa_check_accesses(struct damon_ctx *ctx) --=20 2.47.3 From nobody Sat Jul 25 18:05:55 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3B2493AB27F; Wed, 15 Jul 2026 03:10:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085016; cv=none; b=SnrR9bkifgDnLIKRRItH7s4/Bsz/qEm1Oh5nO8WiPPuxhIKJn+Lz04z1HBFbkHrultaDhTljXxuM7KceSq+mNvjInS8lK8EMNNzSV61S5TzhETWkm4yV926W//k0MiZpeq+JwwX8Jmoopraxn3hb+zcJxu6ofm0QEVjTh6qOoTA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085016; c=relaxed/simple; bh=nD/7BLwhckJ2VrbOKHww4GOUnGL9WSDMxtLvVNd99/c=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=FadhbZdUJfW0dV815mjBIfdeFXkZaMeVFhYylYKSfrNnifzVDMWVqaAELtidfMGhRpzebxlj50jEZKoSVxxnoR5yj5g7bSqQOZNUxooTntLP8++MaPbfc6A1RCkM9XlZKDBn2V1vWr8LLXrXkVPdwxGZZzfHY4+J0AfEBTflYCA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EMMF0rtj; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="EMMF0rtj" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C9AAE1F00A3A; Wed, 15 Jul 2026 03:10:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784085014; bh=OZlM1xLtscWm6r5E9re97Un+lNNnhMeBCpTniJTuHyU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=EMMF0rtjKzOj0NNvQBnEZPkh8CNIg1ZQIhxvDGhbBTy52EkzBm+3e/8x2Gnzj6Nsf 6JdD3stcnyBiFwEMkFGMjBoB8/1rpHvUZEJIp8GfgSDkdu5qbhFDbhc1rFv6FIDUdb I0oASfLvYVVqGqRlhbySFBlqa/S6A2xwZtSa6v3RHhl7Z5R/2OkdsSuCpphyhzhK5A oZMVmL7hEPWSPhDuJInt53pgNVmyltHbjgSiDItpav0q/hMrlqnE4f0tjzEmPrIPp4 THGzI+Km+xtK61uFANf0yvaKZxb+YJpaqcz4xaUzCegDhRuAzJfyxmTiN76AGEoGiK I5wFy6TESpYIQ== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, Quanmin Yan , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v1.1 5/6] mm/damon/sysfs: read addr_unit only once in damon_sysfs_apply_inputs() Date: Tue, 14 Jul 2026 20:10:00 -0700 Message-ID: <20260715031002.108504-6-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260715031002.108504-1-sj@kernel.org> References: <20260715031002.108504-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" damon_sysfs_apply_inputs() reads addr_unit twice. It could race with addr_unit_store(). As a result, the min_region_sz could wrongly be set up. Read it once. The user impact is trivial. Sane users ain't update the parameter in parallel. Even if it happens, the DAMON core layer handles the wrong min_region_sz (!is_power_of_2()). Even if somehow the race ended up making a min_region_sz that is different from the user's intention but still valid, only monitoring itself runs differently than expected. No critical consequences like kernel panic or memory corruption happen. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260714142950.100711-1-sj@kernel.org Fixes: 540a2aebc657 ("mm/damon/sysfs: implement addr_unit file under contex= t dir") Cc: # 6.18.x Signed-off-by: SJ Park --- mm/damon/sysfs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c index b5fe036f78015..65a502c7746c0 100644 --- a/mm/damon/sysfs.c +++ b/mm/damon/sysfs.c @@ -2099,11 +2099,11 @@ static int damon_sysfs_apply_inputs(struct damon_ct= x *ctx, err =3D damon_select_ops(ctx, sys_ctx->ops_id); if (err) return err; - ctx->addr_unit =3D sys_ctx->addr_unit; + ctx->addr_unit =3D READ_ONCE(sys_ctx->addr_unit); /* addr_unit is respected by only DAMON_OPS_PADDR */ if (sys_ctx->ops_id =3D=3D DAMON_OPS_PADDR) ctx->min_region_sz =3D max( - DAMON_MIN_REGION_SZ / sys_ctx->addr_unit, 1); + DAMON_MIN_REGION_SZ / ctx->addr_unit, 1); ctx->pause =3D sys_ctx->pause; err =3D damon_sysfs_set_attrs(ctx, sys_ctx->attrs); if (err) --=20 2.47.3 From nobody Sat Jul 25 18:05:55 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 786BE3ACA70; Wed, 15 Jul 2026 03:10:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085015; cv=none; b=iEDvYWt06b2HbNO1alMfjkebSIMEh2Suq6QGh/gAhoMTbPZcdS+t/3NtAwyJl35SgsWjn/RdblTIferzjRerLKhTbBz1dqXgl1ueI3RR7n4wisMkZTd9kNkrxOgsYqFQOv8Ngy/OG1M+mRtTHeJw7nHV0hSIW7tr2X6/1L7TVPo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784085015; c=relaxed/simple; bh=8EAZYoQVxXJWP2LY9Eji3Og75kTEnJ3aHhWisdL4r9s=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Nb7C65SwJEezuxK+PnPhoVXgft3qb+tQoPGiPsfowOGrIpTzuWe5NfGYauq9luUlUGLyMY8FqVa9E38j9wuo7Ugwe/NglPzmXUfglTGqTnJDdjCb5Zqs+s6d6SP6mH2nmGu+J68r3HhSf0I8DfnTw/uzjv+/qA730Ec8Bg9gUEY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ApGedlzt; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ApGedlzt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 312081F000E9; Wed, 15 Jul 2026 03:10:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784085014; bh=r5eHq92k38jxsVe2qYUSBxPPKXWBRjXR/oltUI6KEm4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ApGedlzt4TB8XMMtRUBW5laM9bbzhhkdz8thJzqOnktxgQs//OWRRMHJ5FgccyqmJ k7/H/bjiH0ndpsKb09xLw9h25j/Rg6BmTsKDAAwLsCJaWdkn3lFo2Arz68emF1zzWK ta3Q9h7L8icauUyQJmW+2XPi8PT8zPIOxqSp9WtPjwHpt3QQxmZogxn9fcxgit5Br9 o4WczTRKgDtfGAyVG1D0Sjz0bZGKSvRi13FFlFONO3rmh+olvMNgURIw878AEYi9K8 AOIessjPfXioxFtpiFsSnbGhezs+/1XXTQqfHMBvZagOS77+INLoc/Q22y9J4A36UE ixzE/qKTRlp+w== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v1.1 6/6] mm/damon/sysfs: read ops_id only once in damon_sysfs_apply_inputs() Date: Tue, 14 Jul 2026 20:10:01 -0700 Message-ID: <20260715031002.108504-7-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260715031002.108504-1-sj@kernel.org> References: <20260715031002.108504-1-sj@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" damon_sysfs_apply_inputs() reads ops_id twice. It could race with ops_id_store(). As a result, the min_region_sz could wrongly be set up. Read it once. The user impact is trivial. Sane users ain't update the parameter in parallel. Even if it happens, the DAMON core layer handles the wrong min_region_sz (!is_power_of_2()). Even if somehow the race ended up making a min_region_sz that is different from the user's intention but still valid, only monitoring itself runs differently than expected. No critical consequences like kernel panic or memory corruption happen The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260703172417.95426-1-sj@kernel.org Fixes: 8d009da32f13 ("mm/damon/sysfs: set damon_ctx->min_sz_region only for= paddr use case") Cc: # 6.18.x Signed-off-by: SJ Park --- mm/damon/sysfs.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mm/damon/sysfs.c b/mm/damon/sysfs.c index 65a502c7746c0..d777411f851c8 100644 --- a/mm/damon/sysfs.c +++ b/mm/damon/sysfs.c @@ -2094,14 +2094,16 @@ static inline bool damon_sysfs_kdamond_running( static int damon_sysfs_apply_inputs(struct damon_ctx *ctx, struct damon_sysfs_context *sys_ctx) { + enum damon_ops_id ops_id; int err; =20 - err =3D damon_select_ops(ctx, sys_ctx->ops_id); + ops_id =3D READ_ONCE(sys_ctx->ops_id); + err =3D damon_select_ops(ctx, ops_id); if (err) return err; ctx->addr_unit =3D READ_ONCE(sys_ctx->addr_unit); /* addr_unit is respected by only DAMON_OPS_PADDR */ - if (sys_ctx->ops_id =3D=3D DAMON_OPS_PADDR) + if (ops_id =3D=3D DAMON_OPS_PADDR) ctx->min_region_sz =3D max( DAMON_MIN_REGION_SZ / ctx->addr_unit, 1); ctx->pause =3D sys_ctx->pause; --=20 2.47.3