From nobody Sat Sep 26 12:26:28 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 EBBDD383333; Tue, 1 Sep 2026 13:18:58 +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=1788268741; cv=none; b=rAL13M/b/fiovYTFCn96nS2yMEKozF8NT3q8OsSz0W9w/HOMoqXvtJAK+AV3L3cw/hWRSNn27u7axfB9hWGG2u2gJ4mOcCjoZMFq4MKKoNmD0ayxPFsH0gnH2mb7lcDLosKYD9QFJUp+0QeAHhi/khZjkHumfrspR0Qg688OPWM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788268741; c=relaxed/simple; bh=N1KBGs6KkVkV/x2mLI1/4fnLqUNGtZ17HUviv2uk9kc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MKoppCvR4apAAFd2O3NmnNqxtpSqDCt9Y0kD1BemJsOn+FGjyArdPO4sERvbLmb/CFoou4fEZwQphnYE6sZY3XBX9uKGzdWb0ZtIn6eRhVrDbrqYJcADNEqmdnHW/312mn5PVugyareE7ok4Pu1HpPNa5A5dLRaSRMbp2uXnd70= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ImCXP+vL; 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="ImCXP+vL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97BB21F00A3E; Tue, 1 Sep 2026 13:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788268738; bh=GOwz6J3a1XnteJ/KkvbDIvrqBi7xM/5c9ntF246FqLk=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ImCXP+vLdIt+iBu9YhsGSFkDJzHMPqdAqvr1BGs2r9lzIHNWddp/ldzgzxqepVC7A 2LsHoK3DeY3UZppt+5reS8KRckSjTSfrSFZsl3+z3oVIU6HmQfUsERKoNVn00SSqQS thSg0yttFoUN9fDERmEMcsZoKyK8+rTI/JDQ+lCcZc3qL0APgOeBGri9kdng0STkdT e78a61s2obsl2fuCLIfFgHWvU9OhmKQo5k9wK1A4WVn1gPMRhv9upfk+kBSYH3U/ZO 3CVedT1y6R8cchECkrprWBo6Tm/MA4EkIbREbDyAoW1JqD3ZBZ6wCEoBwELIcob3Nw IVChnrKHCBBzQ== 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 1/8] mm/damon/core: skip applying scheme if region split for quota fails Date: Tue, 1 Sep 2026 06:18:42 -0700 Message-ID: <20260901131850.98037-2-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260901131850.98037-1-sj@kernel.org> References: <20260901131850.98037-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" damos_apply_scheme() splits a region and apply the action to the subregion if it is needed for not violating the quota. The split operation (damon_split_region_at()) could fail for allocation failure. In the case, the quota could be violated. From the user's perspective, DAMOS becomes more aggressive than expected under the extreme situation. Handle the failure. The user impact is not critical. The failure of damon_split_region_at() is unlikely since it is arguably too small to fail. Also DAMOS being aggressive is limited to the single region. Users can set min_nr_regions to set the maximum size of each region. If it is reasonably set, the transient overhead shouldn't be critical. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260718171523.87547-1-sj@kernel.org Fixes: 2b8a248d5873 ("mm/damon/schemes: implement size quota for schemes ap= plication speed control") Cc: # 5.16.x Signed-off-by: SJ Park --- mm/damon/core.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index 3f89cfdf5f022..a6fdb3068262d 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2604,7 +2604,8 @@ static void damos_apply_scheme(struct damon_ctx *c, s= truct damon_target *t, c->min_region_sz); if (!sz) goto update_stat; - damon_split_region_at(t, r, sz); + if (damon_split_region_at(t, r, sz)) + goto update_stat; } if (damos_core_filter_out(c, t, r, s)) return; --=20 2.47.3 From nobody Sat Sep 26 12:26:28 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 A669B2F3C3E; Tue, 1 Sep 2026 13:18:59 +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=1788268740; cv=none; b=D562Vat9Ke46L4Ep78u9CraDtz/CU1cVS+Ch5B0NZ+2JuWoEcCEW53AvQIo6fKh8aff0a83TAtZKD82kPw/n7HuAFLSQ4BdsKmtfNHg0NNpMHaMPy7cxKqIKDwfoDiE6apBGl2XAmaHhLiT5kOpalQ3PAQGpHueyJF2LZbKRbNA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788268740; c=relaxed/simple; bh=35/yin/QF8t3Kqfg+UAOrsmVX85pqU2Iyl2wuXO5t+0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=bPC9fUrj2s2tWTxBx1RfG1GsljjCemYPNpgEOA0X7hBmeMu6CGkH12f7/4azetGNNXVDoi6caIP6vZcBC56PERQ/4XYaTmlIiO6Fn00+HYedH9OPKp/Dfs47xY6SCpHjca3wtpLEWly5wm7eY0CN/fXLlQ791M9MTu8AQ8S+kCU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wwzgo9sU; 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="Wwzgo9sU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EEA971F00A3D; Tue, 1 Sep 2026 13:18:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788268739; bh=7ZB1yfEGzN5K33ID0e3bcOFkHhvifJ8hhhrNtAvrugg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=Wwzgo9sUB5TGy5zNJC4yHnKl5PtqWaoL8Dz9GwQCTVx+obhlYqR1i0dXlvtkkUxsH d+W+CRtkgAwmR64rN/I4NsWsEeAvHdwvnu4Vyozpe6/CE/q0+kr6mHKbH0iEm4/4Jm FJYIaONRuASM+kaXuNw2QgWGSuP929VGyraDfmNW86cRwkx5yeM7103V36kmVm4szn bx6KyNXzylnXnBWUo3/kFBeCT6ycgOkaxm3HK56Di10oFNNBgRUz7AZm9oAxaCElpM kHbjXf9YQkEdZIG8KxU7SY9fRBE7hp39GHgeYEPLuM+IgfzjovwWd0RP6pk/iArJRp pbVx5n3G7spjQ== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, Usama Arif , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 2/8] mm/damon/paddr: respect folio end for DAMOS_STAT Date: Tue, 1 Sep 2026 06:18:43 -0700 Message-ID: <20260901131850.98037-3-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260901131850.98037-1-sj@kernel.org> References: <20260901131850.98037-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 function for applying DAMOS_STAT in DAMON physical address space operation set (paddr), namely damon_pa_stat(), applies DAMOS filters to folios of the given region. For that, it gets folios of addresses in the region. It starts from the region start address and advances the address by the size of the folio of the address until it goes out of the region. If the start address is in the middle of a large folio, and if the next folios are small, some of the next folios could be skipped. Fix the issue by advancing the address to exactly the start address of the next folio. The user impact is that the DAMOS_STAT-based page level monitoring results become inaccurate. Since the page level monitoring is supposed to provide relatively high precision, this is definitely a problem. It is arguably not critical since it is only monitoring quality degradation. Fixes: bdbe1d7bc325 ("mm/damon/paddr: increment pa_stat damon address range= by folio size") Cc: # 6.14.x Signed-off-by: SJ Park --- mm/damon/paddr.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c index 5c6c3a597fd0b..2ab7b3842701e 100644 --- a/mm/damon/paddr.c +++ b/mm/damon/paddr.c @@ -379,7 +379,7 @@ static unsigned long damon_pa_stat(struct damon_region = *r, =20 if (!damos_pa_filter_out(s, folio)) *sz_filter_passed +=3D folio_size(folio) / addr_unit; - addr +=3D folio_size(folio); + addr =3D PFN_PHYS(folio_pfn(folio)) + folio_size(folio); folio_put(folio); } s->last_applied =3D folio; --=20 2.47.3 From nobody Sat Sep 26 12:26:28 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 CCAE439150B; Tue, 1 Sep 2026 13:18:59 +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=1788268741; cv=none; b=QHndBlZU5b3AdqRc2btF3Wzc4rfS92Il6YR8PklFseelnjPujmFPMiYuxv/OMj92muPuDbUjwBQZ14QvJdMjMru9J0cWv0qauMBY4ThdlFYmQOzrKK80eOBazcU768GPwnLRb+iPjb0NCIodoj10KXWOSvip0O9TMQCT+e/hdWs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788268741; c=relaxed/simple; bh=3tuXFYxnY5whCfMb9BBfKAgRQ7zxuSBaL+SQQ8TayGI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lBqyk5vioDWoZmiQod+86zMBLnrKrYZEzvpVPoaU8OvV0eRws2NOxUay6FBsTUnj3r+3zvji3rxVfI4/OdzNa7xy0DndHzShYBvJYnWHLJra4O7SY7feVMQFqxywbmq8sfDT/PbZgrf1yHhs7yK76fzzECRy27Dyq9H3vu+/JK4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=nggKh11a; 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="nggKh11a" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 586211F00ACA; Tue, 1 Sep 2026 13:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788268739; bh=l4DJBfV8Ln2wiu4MTHaklCvhtPpo+9nKnYvuVasq3nI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=nggKh11aISb6Edpze86CzVlB4WBkZ3fPZ+n/O/cHOag+W5A+rql6O27cDz3C2pvYC 1QhBjHHEW/DjEwkGXVPzDlWClgNwV8yIe07WhxXH0dHqMZWCbZ7gDiQFgsHKav/Gty Wb/988mjBSPtVmlxQh4nWp7OUIm+s2j6fuAK2SgFQJ8rpFQO5bkXdO2nAD4yGBSVQb KInfTX0G1tWJx2JhhM7yqE9RLa+gB+jbd1wEx+FbydFDkDzXjACkibCqytHJrWAshW 95hyaE9AXB+Ops7olWTX51woHk3Mqs9k3BnUuaEnUvO6awgn+aie9+/iqqqZGE5BEH hOvv0Sc3CGyHQ== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, Usama Arif , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 3/8] mm/damon/paddr: respect folio end for DAMOS actions except STAT Date: Tue, 1 Sep 2026 06:18:44 -0700 Message-ID: <20260901131850.98037-4-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260901131850.98037-1-sj@kernel.org> References: <20260901131850.98037-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" A few functions for applying DAMOS actions including pageout, lru_[de]prio and migrate_{hot,cold} in DAMON physical address space operation set (paddr) collect folios of the given region by getting the folios of region-internal addresses. Then, those functions apply the action to the collected folios at once. The collection starts from the region start address and advances the address by the size of the folio of the address until it goes out of the region. If the start address is in the middle of a large folio, and if the next folios are small, some of the next folios could be skipped. Fix the issue by advancing the address to exactly the start address of the next folio. The user impact is that DAMOS action is applied to less than expected amount of memory. Given the best effort nature of DAMON, it is no big problem, but it is clearly a bug that is better to be fixed. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260517234112.89245-1-sj@kernel.org Fixes: 3a06696305e7 ("mm/damon/ops: have damon_get_folio return folio even = for tail pages") Cc: # 6.15.x Signed-off-by: SJ Park --- mm/damon/paddr.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/mm/damon/paddr.c b/mm/damon/paddr.c index 2ab7b3842701e..9ddd1ec8202b7 100644 --- a/mm/damon/paddr.c +++ b/mm/damon/paddr.c @@ -264,7 +264,7 @@ static unsigned long damon_pa_pageout(struct damon_regi= on *r, else list_add(&folio->lru, &folio_list); put_folio: - addr +=3D folio_size(folio); + addr =3D PFN_PHYS(folio_pfn(folio)) + folio_size(folio); folio_put(folio); } if (install_young_filter) @@ -302,7 +302,7 @@ static inline unsigned long damon_pa_de_activate( folio_deactivate(folio); applied +=3D folio_nr_pages(folio); put_folio: - addr +=3D folio_size(folio); + addr =3D PFN_PHYS(folio_pfn(folio)) + folio_size(folio); folio_put(folio); } s->last_applied =3D folio; @@ -350,7 +350,7 @@ static unsigned long damon_pa_migrate(struct damon_regi= on *r, folio_is_file_lru(folio)); list_add(&folio->lru, &folio_list); put_folio: - addr +=3D folio_size(folio); + addr =3D PFN_PHYS(folio_pfn(folio)) + folio_size(folio); folio_put(folio); } applied =3D damon_migrate_pages(&folio_list, s->target_nid); --=20 2.47.3 From nobody Sat Sep 26 12:26:28 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 6C8233CB2F8; Tue, 1 Sep 2026 13:19:00 +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=1788268741; cv=none; b=he8wyg8an8osmFc21dVynCeAiOJau9OAMEOXIxf/vQmf3j7nGHvpIPIA03F3pBNZSGarfGV8se9k5B9uTExOD3y6nJTUdoqF0//AqzkuAdYL6nJ/z/axxzzQc0+DK8FZy9exO2mZUWEG9hRaNepUAso9kUperU4wgXTZ8bGyG04= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788268741; c=relaxed/simple; bh=5AGJ58CxaHUHnA7OwFTsM+2rMQoeaY6UpbD7qoJcoXk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QEiHOinV1HCf5BmBCCOd+k/sxHEqi4WatI0O1OMx8l4l4p3BrG9SLcB1DVYlTNNwdkeRr/sKM3QpgzgunB34Rf0LAXCjHitSVOa4grr3pSF8zb3lKT0N4R5UPqKN0vyIM4HeuGcLTWa08gzqKAofLtC61LMNEtCX6Z/Q8FcO5kc= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LKaTg89x; 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="LKaTg89x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B645C1F00A3F; Tue, 1 Sep 2026 13:18:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788268740; bh=nSTjwnDV8A+NiGPVQu+FC6bukzN4Edj/bjp5VqLzRxU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=LKaTg89xFTeHYyTU0AYlP5vP6CBoCrQY+li5Smev5n/gqRqavoXXXL2OkN/kD6Vgm XgbB27M94hUc2eLdsd64j9MYA/F1dC3ikoy+VUUqSCyem0Xwq9qW5R/55RRwsfqF5o MH5W7MLxavzLWxZmFKmrVaU1opKhs8Y3LvivBsF1hsd0KYQrdmd+sw9Di30uVWhtIX dtQ5N7irsZmSpYO3RoKtDHp7fBf8fjvZVPx3QLA8+f4UK4fX0AC6a7ZBYPjo/J9Qjy Yx0bVYJG/yQ+n8bqIXUn5flvjNOzeIqisuHGjajW+S1xBGBUM/s9NcJekTBTYSdHCc MazJtTNWXOctA== From: SJ Park To: Andrew Morton Cc: SJ Park , stable@vger.kernel.org, Yueyang Pan , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH 4/8] mm/damon/vaddr: respect folio end for DAMOS_STAT Date: Tue, 1 Sep 2026 06:18:45 -0700 Message-ID: <20260901131850.98037-5-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260901131850.98037-1-sj@kernel.org> References: <20260901131850.98037-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" For applying DAMOS_STAT action to a region, DAMON virtual address space operation set (vaddr) calls walk_page_range[_vma]() for the region. The pmd walk entry function, namely damon_va_stat_pmd_entry(), applies DAMOS filters to folios of addresses of the region in the pmd. It starts from the walking address and advances the address by the size of the folio of the address until it goes out of the pmd or the region. Let's suppose it is for the first pmd of the region, and the region start address is in the middle of a large folio. Also, the next folios are small. Then, some of the next folios could be skipped. Fix the issue by advancing the address to exactly the start address of the next folio. The user impact is that the DAMOS_STAT-based page level monitoring results become inaccurate. Since the page level monitoring is supposed to provide relatively high precision, this is definitely a problem. It is arguably not critical since it is only monitoring quality degradation. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260514015053.149396-1-sj@kernel.org Fixes: 63f39737d1e3 ("mm/damon/vaddr: support stat-purpose DAMOS filters") Cc: # 6.18.x Signed-off-by: SJ Park --- mm/damon/vaddr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c index 0648400b2d65b..4b0b5edf67952 100644 --- a/mm/damon/vaddr.c +++ b/mm/damon/vaddr.c @@ -831,6 +831,8 @@ static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned= long addr, return 0; =20 for (; addr < next; pte +=3D nr, addr +=3D nr * PAGE_SIZE) { + unsigned long page_idx; + nr =3D 1; ptent =3D ptep_get(pte); =20 @@ -844,7 +846,8 @@ static int damos_va_stat_pmd_entry(pmd_t *pmd, unsigned= long addr, =20 if (!damos_va_filter_out(s, folio, vma, addr, pte, NULL)) *sz_filter_passed +=3D folio_size(folio); - nr =3D folio_nr_pages(folio); + page_idx =3D folio_page_idx(folio, pte_page(ptent)); + nr =3D folio_nr_pages(folio) - page_idx; s->last_applied =3D folio; } pte_unmap_unlock(start_pte, ptl); --=20 2.47.3 From nobody Sat Sep 26 12:26:28 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 9A5643D093C; Tue, 1 Sep 2026 13:19:00 +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=1788268741; cv=none; b=G30PW2r3SmH3ivjvrTNYsTW88k5AatlWtgRvByH+am4gADtRk8ItArZRbZSR7z3ed1T3/37nXh67R2NR4CQL6c1KMAcoETnv9Y9IS8bDwbSNeruYgSyKP0EYmtmifvbVoYiY39ADsGL77Pi2qsmptLDFQCChowlr/pbQ/8Kwcuc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788268741; c=relaxed/simple; bh=6Z73CbNxQYTOYNM3TzN9z5SgCwrzw1We6fTUP5ae8l4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=KyMub0yHvdH/c/S9UagLBWQR6vrNqeHUxUOg2vpJ6zMCu/hzWMngHuFZSPty8UBfJZ1n9W1HMFGCCmE2WVrKDvRk5nh+NNn1OTQGB8XeGXuZXx8sUVsYoWr0alVJH2+WaG7QmcDY6f3RQoiMjKg1/a4pjSL+UgBnL4JDU+jT8Aw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BkOGbXHt; 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="BkOGbXHt" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 205671F000E9; Tue, 1 Sep 2026 13:19:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788268740; bh=SLM/iGuOERBTFxu8mql/4ATf4p59p9Me6R2GTZoj17M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BkOGbXHtNIV35nOD5BO38v1EVSPQbb31jM9e4LeI3O8uWXuBhWBo26gj2J8OGjLyA bfkqbYKmd4jKEKq4DT5PjTxpucmJ3jX62oeonMNLCn2iuBLx7v/zkOn4cFcNx8bnXP N3eM8+zvmHvTrM+Jr9oBoI+blmqUHzNMiDt2+/Nufo4giN+U0slj6n1VyeaakH/Ocx R9pMr52UT7DuImtFuJq78RdTnmyazUlmpGAUH5tnRlIGl80T863jBTjmNoVhCay7sl 0bZNFQAD/fVDF3jQWDuVk5+X+n5bZp8Qvh5IyVv1ANMJZT+kW4VU6Vao7kENYxmTOZ f++qIJtRLtwMA== 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 5/8] mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} Date: Tue, 1 Sep 2026 06:18:46 -0700 Message-ID: <20260901131850.98037-6-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260901131850.98037-1-sj@kernel.org> References: <20260901131850.98037-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" For applying DAMOS_MIGRATE_{HOT,COLD} actions to a region, DAMON virtual address space operation set (vaddr) calls walk_page_range[_vma]() for the region. The pmd walk entry function, namely damon_va_migrate_pmd_entry(), collects folios of addresses of the region in the pmd. It starts from the walking address and advances the address by the size of the folio of the address until it goes out of the pmd or the region. Let's suppose it is for the first pmd of the region, and the region start address is in the middle of a large folio. Also, the next folios are small. Then, some of the next folios could be skipped. Fix the issue by advancing the address to exactly the start address of the next folio. The user impact is that DAMOS action is applied to less than expected amount of memory. Given the best effort nature of DAMON, it is no big problem, but it is clearly a bug that is better to be fixed. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260514015053.149396-1-sj@kernel.org Fixes: 09efc56a3b1c ("mm/damon/vaddr: consistently use only pmd_entry for d= amos_migrate") Cc: # 6.19.x Signed-off-by: SJ Park --- mm/damon/vaddr.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c index 4b0b5edf67952..c8c32b2ae0402 100644 --- a/mm/damon/vaddr.c +++ b/mm/damon/vaddr.c @@ -669,6 +669,8 @@ static int damos_va_migrate_pmd_entry(pmd_t *pmd, unsig= ned long addr, return 0; =20 for (; addr < next; pte +=3D nr, addr +=3D nr * PAGE_SIZE) { + unsigned long page_idx; + nr =3D 1; ptent =3D ptep_get(pte); =20 @@ -681,7 +683,8 @@ static int damos_va_migrate_pmd_entry(pmd_t *pmd, unsig= ned long addr, continue; damos_va_migrate_dests_add(folio, walk->vma, addr, dests, migration_lists); - nr =3D folio_nr_pages(folio); + page_idx =3D folio_page_idx(folio, pte_page(ptent)); + nr =3D folio_nr_pages(folio) - page_idx; } pte_unmap_unlock(start_pte, ptl); return 0; --=20 2.47.3 From nobody Sat Sep 26 12:26:28 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 D57383DA7E4; Tue, 1 Sep 2026 13:19:00 +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=1788268742; cv=none; b=mbgjOxs+H+t9+DhBiATdNnIgVya+ll8LS/2v7WhO7u19206Xq7fS6dXZscVSjf2MdGmx9JE11KVwNnlfyNB3+9dEuX/owkS8C5i6tTUN+00NPEqgH5a5Sr+sWD+Pse0tnSHgbWDcZMD49t414p0vUOJs0qA/0jqvVYQUw+3/XV4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788268742; c=relaxed/simple; bh=tzAcE6SEgWB3A7dvKIyT7G341pe6G1l97zdd278rH/8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QsciObuILD2R7XdNCqv8iTKndQGRqwOKrJeWmIJCsb+YqOsoU8zTUOrtgVcbK16mHtPa5eJOhK3oi3VP3p4MvGo2dFXqapft8HvCX8xgWFaqUiUg21yTg+v10kstra9bwUI5+tp/J3W0HJJbWQ3VDzXIbVHB4QClCcjYuHUHT54= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=WvRKDNbT; 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="WvRKDNbT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8B0DB1F00ADB; Tue, 1 Sep 2026 13:19:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788268740; bh=YLJtgrH/eA5cfD1d64StUX4ou+TBBQRag4ZJY9MXlY0=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=WvRKDNbT0hyEoN7m5TjTShQ5sN5bJPnuNWLT6l7VT3lCd/KVbAfzwtJkyYLnKaccq P1Jw9u0g7PmSQBwVBlbiQEs8LfnoL/0DQbMK8XTluP/mmlATssbYqxglyn6C/fYh7l rp+7LZauxItUuyiDJ4F/zDntxqOpzYlZKFlU9xINPgFA4M7tWIzkweK9pz461bhAnY 3/Wx8HiFakAB/JN3eWrXGLGf1uJiGNbN9/qPXlnfQx+MbZgFfnQ5N0f0vD3P9DNS3Q QY/JgRdyAdRo48bYa/MLnNFX/VQqTSlkN74Z86yHtOfe/uztJgo8Qnbfn64UX4i+4q MBDXcwSvH7XyQ== 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 6/8] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() Date: Tue, 1 Sep 2026 06:18:47 -0700 Message-ID: <20260901131850.98037-7-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260901131850.98037-1-sj@kernel.org> References: <20260901131850.98037-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" In an extreme and unlikely situation, si_meminfo_node() might let the caller show zero total ram. That could cause a divide by zero in damon_get_node_mem_bp(). It could also show free memory larger than the total memory. This could cause underflow and make DAMOS temporarily make unexpected behavior. Thanks to safety guards in the auto-tuning feedback loop, that should not be a real problem, though. Fix the problems by respectively returning 100% and 0% for used and free memory queries in the corner cases. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260328133216.9697-1-sj@kernel.org Fixes: 0e1c773b501f ("mm/damon/core: introduce damos quota goal metrics for= memory node utilization") Cc: # 6.16.x Signed-off-by: SJ Park --- mm/damon/core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/mm/damon/core.c b/mm/damon/core.c index a6fdb3068262d..ad3657d356fbc 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2807,6 +2807,13 @@ static __kernel_ulong_t damos_get_node_mem_bp( } =20 si_meminfo_node(&i, goal->nid); + if (!i.totalram || i.totalram < i.freeram) { + if (goal->metric =3D=3D DAMOS_QUOTA_NODE_MEM_USED_BP) + return 10000; + else /* DAMOS_QUOTA_NODE_MEM_FREE_BP */ + return 0; + } + if (goal->metric =3D=3D DAMOS_QUOTA_NODE_MEM_USED_BP) numerator =3D i.totalram - i.freeram; else /* DAMOS_QUOTA_NODE_MEM_FREE_BP */ --=20 2.47.3 From nobody Sat Sep 26 12:26:28 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 79115432E60; Tue, 1 Sep 2026 13:19:01 +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=1788268742; cv=none; b=mlg6F2hQ/kuKB8g4Z+SBr0m2g//q7e+WwM1lRf+wVWVOClgbWQfprlM0WN4Ud9xbf72itW6qB5dDVkdzl6DEWVi4EnkKRyW1A24iXN0ZYLLUurcU4jUTjqfy5QFQFizdySLZpyKfN5XDWnLUK60mqvJuotdf8xz0dMmjMKz4O5c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788268742; c=relaxed/simple; bh=lZqnF/fq0s75WPlK1Ldiv9o028oS83xr/Lv60UdZAxc=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=M00EoEFCcKQMBmB5n8dkQbCbWQVJpvJU6Shpj4uyX80iYgTekf9rbYSG4HX8NcGhDlEOFzkAhIHJuTKOomRMhyCYwDdHkjjKW60G7UkM5P11aZnbL/AgGCT4A1F9offB+08/8rZG6k0khbsJZCsZa9CCpNhu/hjGHFeP9kYDAc4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZwKYNYCW; 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="ZwKYNYCW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E25D21F00A3D; Tue, 1 Sep 2026 13:19:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788268741; bh=/E3Oie88We+VUNBoQinHbEvxciAXpLnuOmC5tKc4/XE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ZwKYNYCWXkf3YcSo51XFKfIBjCb8OCl5BO+I54kmq6FiZHkliHE7g1on9UYpfxsdU 2SDIwQfVwj2Zf7vAcXQVsVbi8q3wupnNKn/brVsZzmIY3rYNCGLkn2YO7VOESECV3W 8OQIjhhtUNLHhUCyhUxO40Al8ceT8Izf16Ej6fi06DtaHFKPu/1bJFljhROx4NhcJn doJSWRCIQJbfbftYigig4hpE6Yx+vjeUpX7HJLzSd9t6OQk7xxMevPVSa1x60QFS+z c1LVdwXDuKxe0+hxv6I/2HVsHfGAYVcMaD2mfnoBkIE0SOzWAiBgO7oP+vSlj27mzZ lXe3py30Y8SAA== 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 7/8] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() Date: Tue, 1 Sep 2026 06:18:48 -0700 Message-ID: <20260901131850.98037-8-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260901131850.98037-1-sj@kernel.org> References: <20260901131850.98037-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" In extreme unlikely situations, total memory might be zero. In less extreme but still very unlikely situations, lruvec_page_state() calls might let the caller show used memory larger than total memory. In the two cases, damos_get_node_memcg_used_bp() could cause division by zero, or return underflowed value, respectively. Handle the cases by respectively returning 100% and 0% for used and free memory queries in the corner cases. This issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260329154813.47382-1-sj@kernel.org Fixes: b74a120bcf50 ("mm/damon/core: implement DAMOS_QUOTA_NODE_MEMCG_USED_= BP") Cc: # 6.19.x Signed-off-by: SJ Park --- mm/damon/core.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/mm/damon/core.c b/mm/damon/core.c index ad3657d356fbc..3060edf5e4fa6 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2854,6 +2854,12 @@ static unsigned long damos_get_node_memcg_used_bp( mem_cgroup_put(memcg); =20 si_meminfo_node(&i, goal->nid); + if (!i.totalram || i.totalram < used_pages) { + if (goal->metric =3D=3D DAMOS_QUOTA_NODE_MEMCG_USED_BP) + return 10000; + else /* DAMOS_QUOTA_NODE_MEMCG_FREE_BP */ + return 0; + } if (goal->metric =3D=3D DAMOS_QUOTA_NODE_MEMCG_USED_BP) numerator =3D used_pages; else /* DAMOS_QUOTA_NODE_MEMCG_FREE_BP */ --=20 2.47.3 From nobody Sat Sep 26 12:26:28 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 9C8C743B3C6; Tue, 1 Sep 2026 13:19:01 +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=1788268742; cv=none; b=Gi6KkXs92awQDOIqdb662s55res1zNn7jl0Vzq5tDwwjqVJs73UuF3ziopzRz6Glxbxu0uOgU5LSZrSenDFVvlJl0ILucg28od3mbrKXlqWMaU3FJrOriyuS1X3ImymykolXmLnzc84A6HINBwR9xd91LlclHjhTuoHlbpsgF14= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788268742; c=relaxed/simple; bh=GXr/1jJ0ZcG+tvVvUf9OAFx0ZgFUmAAa9q7CIMr6dbk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Ey6ktulilvYHyj5h89ybycXHc0SgqnZRAItkAcMVdt2FK2KqV13MhYyWGhRrxrfF+PAT2L0pCdS9TE+NABGys4b5Nf5cvp6qEw9Ioj+OVmgRIXXfwH1lWEaU3qm6vhaOXge8HRii1+y0nKcsa5fdpfkjY6fmdX9wJu7d9v2urBA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ig92mQta; 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="ig92mQta" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 452D01F00A3E; Tue, 1 Sep 2026 13:19:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788268741; bh=VvO9nu/pvwrT8AJnGanMkEVbhfeAa8vp4BSGaiM1GXg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ig92mQtakTdHt0VVFboiQzpG74wWcUaalH06d9B8H+DqFvf8O10xsK8agpzNt48dI J6z78dAJsmkAgL1bGwzouj7Bo1tsFXUwjGUhxaemvkiP5iJj5I27039kzIr6sPksz/ JmcUMbUDgwzghHaFtsLePi+nD/8bOnxkGtErWkZTfW+jquJlWqsN8qC0LBAV4yE2Mh E6LBN4vo828WsQkUMz4FEZZroCbmbvGpWvYiJZv6EeK+4lqNiYuxidJqZjeLKjMtPt iXRCXVLksLVM8WMlccLkVlGFJDyXyLeFnLG3uFITa+I94BxAVO5fXbh2YuVmqx6CPS uPIFRnMKnnwDg== 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 8/8] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() Date: Tue, 1 Sep 2026 06:18:49 -0700 Message-ID: <20260901131850.98037-9-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260901131850.98037-1-sj@kernel.org> References: <20260901131850.98037-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" damos_get_in_active_mem_bp() uses the sum of the active and inactive memory amount as a denominator. In an extreme and unlikely environment, active and inactive memory might be zero. In this case, hence, it results in a divide by zero problem. Avoid it by changing the denominator to one if it is zero, before it is being used. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260721034756.147011-1-sj@kernel.org Fixes: 4835e2871321 ("mm/damon/core: introduce [in]active memory ratio damo= s quota goal metric") Cc: # 7.0.x Signed-off-by: SJ Park --- mm/damon/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index 3060edf5e4fa6..0df785e72438f 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3006,7 +3006,7 @@ static unsigned int damos_get_in_active_mem_bp(bool a= ctive_ratio) global_node_page_state(NR_LRU_BASE + LRU_ACTIVE_FILE); inactive =3D global_node_page_state(NR_LRU_BASE + LRU_INACTIVE_ANON) + global_node_page_state(NR_LRU_BASE + LRU_INACTIVE_FILE); - total =3D active + inactive; + total =3D max(active + inactive, 1); if (active_ratio) return mult_frac(active, 10000, total); return mult_frac(inactive, 10000, total); --=20 2.47.3