From nobody Fri Oct 2 11:40:45 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 CFDA03B71BD; Sun, 2 Aug 2026 16:26:40 +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=1785688001; cv=none; b=hnMpYeWmBP89cBXCWyMFuU1VNuRsAO0kYsWT6mLPYfwbP/B9thoq0DRazM5tUTJgJaAo5JGWgYTe+lyHxkG22Nvanl5jAYcgx7H/cn03ptZg6EmrygdVwnuPRKuOinqd3QQE7/jQ4kZeGfxY5RHFzXyiO2oB/yeCrpMlCGIiprE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688001; c=relaxed/simple; bh=c8YnLYM9gCkCamNMX4Ifu9ihjCO2crXUFIBol3Mz1aU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Vsc9E1zzEfEPheXnFiqwECimK6ChnqvQs/MbtzsMMJgTacKkCYuLAX6wTtpESZ/bm1niJ3Lv+O7C4h+9kGyH7oc7y2hJml3LTDRCJOuTjtvlcMFAb3QpKacqtOpIQ+wCfISTJLqjaie75vCMNZiNN+/kSfOSbaTO8bmvCuRe9Og= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=LkusKe2F; 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="LkusKe2F" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 855FE1F00A3D; Sun, 2 Aug 2026 16:26:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688000; bh=ccJR9KUzvn7k6BzhoDEjN3sQrL1C2MxY/yOiNOzvC90=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=LkusKe2FMzJBDbjcyry/6L7Ye17EKtbUrBNtIWUra74cYtqsGpoMI1PdIeeRkUdEL r987uAJiH9MyvCSbP98srQXmYFaUswDAUdc/hsiDePQU3Y29gfH9Fj7oXiZTARPOW6 In1y/bOdVU6eyO3IRSF0OyfhXWg+YUQuhC+/uTw7zUgrBuE+Pq9uS3TQqmqXZkvtWC AucarmJsSQLIo84mQyoUlunXNC4Ybinv2sVSsDY1Z2B6o9dJNcGhGIc6rd1bNh82jV 4XH4xoGZAK4gkqph6/Cp4QC+cVo65fR7fhiSNCZxaeiLZfivlcm7GwCPDxrUMnBUU0 KXOiOI6k92L6A== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 1/9] mm/damon/core: skip applying scheme if region split for quota fails Date: Sun, 2 Aug 2026 09:26:22 -0700 Message-ID: <20260802162631.90304-2-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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 644daf5a16560..e2900d0c984c9 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2613,7 +2613,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 Fri Oct 2 11:40:45 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 5B09C3ADBA5; Sun, 2 Aug 2026 16:26:41 +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=1785688002; cv=none; b=fWzDFt29MiPyaq9+PqYlmQOSX7P/SFupivSaOUHGnB0H5Pu33LTsd6MjA5PQQ3dCLUgCms+XraXO8EzMgNfpiwds82Ayz2YcTmwzlFhv19Hd++VNzWTvGhbXrkEhcPuU8c3VKVfnXAAcV6OpKOj5UvlBJVYdZSccz1J0s55hCsI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688002; c=relaxed/simple; bh=ZKIT6xnY2oY0e92eMERMwBiCQNJeROh6kYo/rMQan28=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=QYEdUJP8BxjzEiz0BD7oUbhHf9lS4wjE6cR1np++muIv8YvhmkjMqvoaMoVRFFrXBCaKNLrAM8HHodlbsv+5HLr2oE1kMiFiT9eHwETOcK1Mgau6OrJEmnP7oTBz+7PSW002DswRJ5XT+2nS+c35jXv34BF+2tTPqb27x9+NlLM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=OCxkL/p+; 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="OCxkL/p+" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DA7841F00A3A; Sun, 2 Aug 2026 16:26:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688001; bh=u3Yai1oWYsB5IJ1T8UFXb8F9ZG0QK/4CFjudJQO8wtI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=OCxkL/p+39Bi9iTZV0NqYw2G6YyiSqoQ5a0QvVf2YzJYLXd7z66X1o8vR+uygnJOX t+Mdv4nmbfTaf4kOf2GMcVYF5kwgK/85UucUwmPbvlsSoHSGv4LeAVmgNi1qR/YfjH cYtxRmJk4DNfbk1AUHLA5v9oBcCuRhl1eq22EFv8SWoHB1ho95Ei6AVuqpQyJ66bgm uK2OdcXhUr2o9gFbECJpC9Ovd1O3MaL67hQUygvSPpfClq+kVb7YZelkPD9OhGUbqf F3tJ5D5lkwnU0oaw2aB79xrxpVyngzDkF7syF6nDk6wnjdaNvLuN/WmsFiMNzjPw4f G7sshIzQWpK6Q== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 2/9] mm/damon/core: initialize damos_quota_goal->last_psi_total Date: Sun, 2 Aug 2026 09:26:23 -0700 Message-ID: <20260802162631.90304-3-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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" When DAMOS_QUOTA_SOME_MEM_PSI_US metric damos quota goal is set, the PSI delta for the feedback loop is calculated using damos_quota_goal->last_psi_total. It is not initialized at the beginning. So the first iteration of the feedback loop uses the uninitialized value and makes an unexpected starting point quota. Initialize the value at the beginning of kdamond. The user impact would be trivial because the issue impacts only the initial iteration of the feedback loop. The feedback loop also has an internal cap of the quota adjustment. The wrong adjustment will soon be corrected over a few iterations. The issue was discovered [1] by Sashiko. [1] https://lore.kernel.org/20260718005316.89585-1-sj@kernel.org Fixes: 2dbb60f789cb ("mm/damon/core: implement PSI metric DAMOS quota goal") Cc: # 6.9.x Signed-off-by: SJ Park --- mm/damon/core.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/mm/damon/core.c b/mm/damon/core.c index e2900d0c984c9..3bdbf4fbf7147 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3728,6 +3728,17 @@ static int kdamond_wait_activation(struct damon_ctx = *ctx) return -EBUSY; } =20 +static void damos_init_quota_goal_last_psi(struct damos *s) +{ + struct damos_quota_goal *goal; + + damos_for_each_quota_goal(goal, &s->quota) { + if (goal->metric !=3D DAMOS_QUOTA_SOME_MEM_PSI_US) + continue; + goal->last_psi_total =3D damos_get_some_mem_psi_total(); + } +} + static void kdamond_init_ctx(struct damon_ctx *ctx) { unsigned long sample_interval =3D ctx->attrs.sample_interval ? @@ -3744,6 +3755,7 @@ static void kdamond_init_ctx(struct damon_ctx *ctx) damon_for_each_scheme(scheme, ctx) { damos_set_next_apply_sis(scheme, ctx); damos_set_filters_default_reject(scheme); + damos_init_quota_goal_last_psi(scheme); } } =20 --=20 2.47.3 From nobody Fri Oct 2 11:40:45 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 9E201397935; Sun, 2 Aug 2026 16:26:41 +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=1785688002; cv=none; b=XRxim429C0pozWs3mdTUeZiicZZn7YnyDJ+Yd9ac7hRW7To6dCLbnvsFOhDKix1xWbLBLzrLBJumj4rjCEavl/efIECy+t4XbiH7vh3Pxu0afZfWZ51HAU+OfN2ZJGU873UgLQeAugVmaCIuZvkIQDCcjvHXw32LMjD8Jqbdul4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688002; c=relaxed/simple; bh=35/yin/QF8t3Kqfg+UAOrsmVX85pqU2Iyl2wuXO5t+0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=k6XaYW73kIsTuM1BCb0g/kVGyvr7reyJrXpQbnV8Yh6SwC4qx7V0bE5Q/VoWqVAMsTXE4tHqaGCG/YywPmNdyLB3E8o6/I7DHZg22mGryHih5DTVE3PzT7D5ydVO26S9WJ6wuCD+aQeUJEyeqO0LSKMvhQCExJbYLD+Sl4fwE0w= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=BHl/VqGk; 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="BHl/VqGk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3ABC21F00A3F; Sun, 2 Aug 2026 16:26:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688001; bh=7ZB1yfEGzN5K33ID0e3bcOFkHhvifJ8hhhrNtAvrugg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BHl/VqGkYNrEF4AO5DDxQ8DZfWi/AR93VaCva3l+Wy7MW7g4dJuamnqSK2IrNQR3d mk+XX0FUD2ENVKg7Xw6ZxplyfcPHPOKLobCgogY++kAhAgerrD9ne0SefX2YyQ4Dfc 8mdlsVJk1k0ABP/qkua8MIV2pQlHi8vaAstL+T6m8ECNCbHoV9f9dPatlqFEU2XpXu ZrmQrbKn8fxtBYcayBzu/pPO6EkhLsVvII8W6evH5M/zMUgtRaFb/1uPpN65lPN+tc M5eK0YF5Bapurtf0gvcKTMe6UupNIEODebDhMu6bGLOyo0h6OllJIFgl1n7Ak0Xx6n 0bqbXqYgwZX7Q== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , Usama Arif , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 3/9] mm/damon/paddr: respect folio end for DAMOS_STAT Date: Sun, 2 Aug 2026 09:26:24 -0700 Message-ID: <20260802162631.90304-4-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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 Fri Oct 2 11:40:45 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 EA2A83BD657; Sun, 2 Aug 2026 16:26:41 +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=1785688003; cv=none; b=QngXtv2ZJUX1TFTuem1W60UH7EYkEWIgcXqG2YNrqwSKp9WmMoX0aTdunwM7yLn7tA4X45Bbp2A2Xd6Lx3H+QpdU/7ddz9AlDluu/o4vT9likhgDyEXnPPs1gcYZxL2BLTdACEJsNGSyM+7sspzXcfQlFs4bVll34y/o5HUXNuE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688003; c=relaxed/simple; bh=3tuXFYxnY5whCfMb9BBfKAgRQ7zxuSBaL+SQQ8TayGI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=WD/4knNdhWqAXAMOOgI2PTO6jN1SKKCHRB7TD+au5jyWBaP2Gvp4K5+VRhx70cCR32d1IkhZwOy5WVdm1jLqA78bqJGFoJgVna2f9DFLPHCF0bEteQlpsHtvcl/tQnJxgaBt5qDT7oKrZnKbFxcNc7AmMUbdXgHpLmSk2ZF5i0A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=L0eYjzrx; 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="L0eYjzrx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 951841F00AC4; Sun, 2 Aug 2026 16:26:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688001; bh=l4DJBfV8Ln2wiu4MTHaklCvhtPpo+9nKnYvuVasq3nI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=L0eYjzrxKQgFu++2Z1fBClKpatsUoHdYaOJZBYub+Nw5sxEri0fzDzGtBDsgDsKWg s54N8ydwKySGmQlCi8y6ZqdqP9gtxY7dtM04MtvffC8Eo3YL/q6Mu1QdgeiRsqvNvj JwDM6oTaIGTwvhgPZ+F1dmdWn6vtzSIsMCfP92J0F4Ph6lGHDkpRw3rHBdrwZhTMSA bA9HOfaWSXQq2H0mXX6cMc+u4jRH3wsvqDlpT67rfKJRZ25Mxdt0O60W0L1/iNUK7d 4ABzC9WYhyyguy7cIQoAxBRy8vYloDUn8EOtCJL41puoOrQvEBJaf26Rd3ot8jUptZ oCqj8NAvfe/Qw== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , Usama Arif , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 4/9] mm/damon/paddr: respect folio end for DAMOS actions except STAT Date: Sun, 2 Aug 2026 09:26:25 -0700 Message-ID: <20260802162631.90304-5-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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 Fri Oct 2 11:40:45 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 EDBCB3C3F48; Sun, 2 Aug 2026 16:26:42 +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=1785688005; cv=none; b=WySPo7A/0JzMUDYARICBFywBmcMXsBII6Ks+w1ZnfGyPO8hBuN5QHHXPoEkuNQOWAJ5AqTneb5QvQqCC46dinKbfQNYVzVnHTFRvX0k9kfCuk7R2rzHYo/yx1x6LUHAfhsWcyOqoukaegncw/ZkV9/68fQBrPT6WJi6KPcw/4ZA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688005; c=relaxed/simple; bh=5AGJ58CxaHUHnA7OwFTsM+2rMQoeaY6UpbD7qoJcoXk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Z+zE8vHMOCBQ8GzJ9aTZHntzYBC8xfZ4ApJ+l58KBP4SmKylvBGLZ5Q9uEUeBNSdBQ3sGwCCGNGsjax9mlXvL37yZPjQAc3NDAf72Iv9nsNUnYMHtoXBJhhlrjudNmXAOK/Ko4BdvmvA2EO7pt8lA+RGAtzI4gkyhSaoeuBfbLY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VPP1daxk; 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="VPP1daxk" Received: by smtp.kernel.org (Postfix) with ESMTPSA id F13D41F00A3D; Sun, 2 Aug 2026 16:26:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688002; bh=nSTjwnDV8A+NiGPVQu+FC6bukzN4Edj/bjp5VqLzRxU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=VPP1daxkJXKjw19NUc7Z6RGkRDyWKUmVdKkYofrxQZWt8lBLVZTvam9kiHMe1LwSf eHKwTdEIgn9wBVNn0qj+sXBU3eCkzVzzI4eWILMp/iF9v9VRe/r2AOw+Tif9jBWPgm GvaHlqsVooEvjw2hbbfg19RwBT1P2TBs3IyrYe5MN76ybOdaVecZEAkdhdPQuu8lUS 7bVvIDnhF35q+yG8YusWGJuMq6ffaSU9/ekxHOrwNU4mzSsJYqEoUtu19TjkmNx0Lu 5FavlCCTIB8ptfqY4M8NhWR/IWyFIQPJQvUiZJW0MyDlEX+8JPjjRK0fTincYLI1CE FlSURFfAZcCCw== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , Yueyang Pan , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 5/9] mm/damon/vaddr: respect folio end for DAMOS_STAT Date: Sun, 2 Aug 2026 09:26:26 -0700 Message-ID: <20260802162631.90304-6-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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 Fri Oct 2 11:40:45 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 EDAFA175A93; Sun, 2 Aug 2026 16:26:42 +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=1785688004; cv=none; b=VwOhAUEknjxJEZQwMAQncTAKy4cKrxjyIjcAzY00ralVG2yw4kjhQIlodxe9fA56oaTGgPVdP2X+gvQsWX3JN1rpm/2uVZz2m+uU/cpm07McS6yk41/iKnMyuexIJp4dgirupCgY8I3Npziw1dW5KdlNNPFuQXAlbLQEm+RmRPw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688004; c=relaxed/simple; bh=6Z73CbNxQYTOYNM3TzN9z5SgCwrzw1We6fTUP5ae8l4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=toUcb8sk02dqgMS9Hmbs7uccKzZd7Q+wRuPYYGNdnY6Wht9IkwV5GoTaKI6rps+PwnTO6iRz9voSic0Qkhevce69oQamX3p0QWY3jf8bAIPr7kMlBu8IJdjcAImMA/BQXmpqFSprNMrmT7+q2UpOs6PhH+LaqV7D373D+eqJNcM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UHv5cTEZ; 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="UHv5cTEZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 57BCE1F00A3E; Sun, 2 Aug 2026 16:26:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688002; bh=SLM/iGuOERBTFxu8mql/4ATf4p59p9Me6R2GTZoj17M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=UHv5cTEZKzhRB7KsY5VAqfOxGEnCzIj6KjzB0a08BwYuiVUZm5dUk3A9CQ6IYXwd7 zKYys125rvcGQqMNhi9zD0aoOaZULn3BZAzEYWybMJEHkYC01ydwu7vj/IeEoLuRKG mTyRuK7EF0pbeTrTAcyX2qbHeMrRsnXkp9FpzACFFHklhZr/RrisibHGmEAd/0KyN9 r4v6hmC4t+5ccvvw8aBeGaUR0mHF4A9TsCnPrlzyjSybliWNZa8oeC2V+00ipZ4oII C2MWXntanRysslwPs0u5qSFKfLPZBF6jJzOrg/ZdZvt2RBUUD1gADaAiqBEL6W7Kyu 0P/vWXnFhoBsQ== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 6/9] mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} Date: Sun, 2 Aug 2026 09:26:27 -0700 Message-ID: <20260802162631.90304-7-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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 Fri Oct 2 11:40:45 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 6172D3C456F; Sun, 2 Aug 2026 16:26:43 +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=1785688004; cv=none; b=hWjIUl7SY2DQfQGmjq4zjjvHKCV2HN9SmwTXsopSlT4AfchtIgc39xtQX4GqP6fktoYSVgIBvKfW3xiWUdwWn+dwhPcLCsZOxEdXmXbqbz5SDO+svnC82rpY/6pwdJheyDj7H7hDgaWAxpVrAOPzL+EvO9rldwn0g9Xsc+btW7w= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688004; c=relaxed/simple; bh=vtkwcz9sAeGBi+04ZC3OJfIwe/7uVSh2+/Pk5/qfBCk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=YucFJe+nyv/twFCw1TLPo3QOqsNAm7fkLtUl3mlUY7L3ef5ir3I697oG+5TpF416edNkM8ioYl7mp7dUV/UeSZHzV0z9UhkM7SS+tmCxHR7V0uN2/hndCMvWgz0ykx9Yy3HD8bD+C4k1agI1YNJpPCXIChVtUoRwte7UxMqXlNY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=PdOII6RH; 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="PdOII6RH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A99A21F000E9; Sun, 2 Aug 2026 16:26:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688002; bh=WiXFs5/zG+q5AEfCdPBDZKoOPM3GsSFg0ysudbMhxYI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=PdOII6RH9kC1nW2NlNxCkQzAaSrbwyfJm9hOsB7grL0tx9y+EU0jaKwlvWNa+mWAX dk9Kf/QASWSmsRah/mGqksuXYUah1O2NAwhqWihGdMzlqRwwXOrE4to+DYCVROjI+j YIo7I02SZJSR7pIGX152i4Zg7eF9tXwbyVR526HSZ5wmERG6lgz4hjB4vziS+2yo8i KRBRNNGdeiqYN+IMWfWzqFE/ltGTztAM6BdWa+yqWdmkCp/vIvrrsUrd/8Y3nTWaWj aMroU9gExuLwYBuneUKbcTAWg3s2L0EuIeSZhznFaGjctp8wrcTN6QeFwzBkykoDd4 HXu5Ytki+3VAg== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 7/9] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() Date: Sun, 2 Aug 2026 09:26:28 -0700 Message-ID: <20260802162631.90304-8-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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(). Fix it by setting the totalram one byte in the case. 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 | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index 3bdbf4fbf7147..e3f3ee75a3d33 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2816,10 +2816,16 @@ static __kernel_ulong_t damos_get_node_mem_bp( } =20 si_meminfo_node(&i, goal->nid); - if (goal->metric =3D=3D DAMOS_QUOTA_NODE_MEM_USED_BP) + if (!i.totalram) + return 10000; + if (goal->metric =3D=3D DAMOS_QUOTA_NODE_MEM_USED_BP) { numerator =3D i.totalram - i.freeram; - else /* DAMOS_QUOTA_NODE_MEM_FREE_BP */ + } else { + /* DAMOS_QUOTA_NODE_MEM_FREE_BP */ + if (i.totalram < i.freeram) + return 0; numerator =3D i.freeram; + } return mult_frac(numerator, 10000, i.totalram); } =20 --=20 2.47.3 From nobody Fri Oct 2 11:40:45 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 4DFD23C4562; Sun, 2 Aug 2026 16:26:43 +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=1785688004; cv=none; b=DXvQ9kcpsu0Q5jOF1/Vwk8vt7A0dhk92XrjcOhwD4R/wgobhyi5RrCFfTPscoZJiepAeu5UvfPOdrXp8pEvCEqDory7uNcX8VRfSuAAlDmnpupPKLrDW63tqNBWaYkyzBMxuXmcQ9jyF/ygntJ2qtyH59JMql3B1mxAUGoZFuY8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688004; c=relaxed/simple; bh=WmQs425Ef+xSSAMNq/UxNBdA3EHvev2EgnxOjd6G0UE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=nHN6Qs+GaWoWiVIUmDqsgUf7+/HkucXpoelU9V5xHJSVPRcmWhEEjm6BSCRXXO+CR0NgmWEs24UjzqtcLcWyxVQfsNYcg3XrCn0go8ODdyie6Nq2XWA4Ychhp/wnxe2ZTCpJUUbiaSk8s0kc/dtRg5Yl93RNGT4Hp0b2IgCap9c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=i93KIxE6; 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="i93KIxE6" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 096EC1F00A3A; Sun, 2 Aug 2026 16:26:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688003; bh=UlahV7MXYAlqB2Rb+2/EWA2ZT0Z/bDkXZ3DtwrXgJX8=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=i93KIxE6IhKofsUKUjSvoeTgC+o3fRHexLU8S91bisem0Lp1CY8/A9/xz5YySiK0Q DbxNTTvq6m2hy8D8QfWt79E95h9+vbIKCtq0dp65YKgGjRYF056e6++4Qo1uxQCrTB d5R+gLEHMfovUlT5Zh17788JeytKKcbJADVpsmuVsXtpqrcyEAmLbAFUUfPP8wMG86 VdV22kxE5i5yj+U2mmK1zZRiAQSM/YwnrWzamUK4AqKjapmqCXHb6gEhrQj2Yn114h YT3pGUA7OGqhLWE0GigIzBIlukKcgYSz8r+HAqrrXcwT3lNbzDmzopv7g175tufi4C 6fNpVrcK2xMGg== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 8/9] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() Date: Sun, 2 Aug 2026 09:26:29 -0700 Message-ID: <20260802162631.90304-9-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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 returning 100% and 0% for the two cases, respectively. 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 | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/mm/damon/core.c b/mm/damon/core.c index e3f3ee75a3d33..67ad1f07c29a4 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2862,10 +2862,16 @@ static unsigned long damos_get_node_memcg_used_bp( mem_cgroup_put(memcg); =20 si_meminfo_node(&i, goal->nid); - if (goal->metric =3D=3D DAMOS_QUOTA_NODE_MEMCG_USED_BP) + if (!i.totalram) + return 10000; + if (goal->metric =3D=3D DAMOS_QUOTA_NODE_MEMCG_USED_BP) { numerator =3D used_pages; - else /* DAMOS_QUOTA_NODE_MEMCG_FREE_BP */ + } else { + /* DAMOS_QUOTA_NODE_MEMCG_FREE_BP */ + if (i.totalram < used_pages) + return 0; numerator =3D i.totalram - used_pages; + } return mult_frac(numerator, 10000, i.totalram); } =20 --=20 2.47.3 From nobody Fri Oct 2 11:40:45 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 AAE893C5833; Sun, 2 Aug 2026 16:26:43 +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=1785688005; cv=none; b=mfT9n1bl3Em7zdbHTRLZwt8zaHZvkr3eQcaVHJZv8rfNtu8LZmj1hNUYigdumfoCuC4Gnx5SdYxbual17C6gHzIh+7R/YbhjIJGrmSm8t2YPj+tGynyN/J41X9htsgUseXbDFqN6DVCrEoQFMdlJxzBM8hurSdj+EffBdoBj7SM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785688005; c=relaxed/simple; bh=yf/Wtcy4X8myT49I/nXHYz/zUI9Qgg5E+qxFaSvv6V0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=fG76GD0xAqUHUZQ9xBQhuAc05ru6kpukrPXWdLyVsOpa5vSUFCNQaK2WcxcRg27oeB20ssNjiH56bxdzLsD3pAZ8gT2Nefxu/AOYIRYLv+bgRnvfiIvvxnkVuUAgNv5X7x7SkZPHEO96HJpmuNccb2ER8UQfND7ePJ7HUTC/BME= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ofUbJFVR; 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="ofUbJFVR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5E2AB1F00AC4; Sun, 2 Aug 2026 16:26:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785688003; bh=FjpIc++QZPjZOYYyTcv8UZquOm4P+vQqtVegyQJWS98=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=ofUbJFVR7en0yO0u2gPuMSNQGF9LpRv6jXSWh8QWsDr0ac+40r0HMmVvt7WTuctK1 KQLtO97awGBVMnLh4R8Vqj+ZtTKLPAVpJXiGf5mLcmpdIqLCCAThLDY1lhwcaBm0cs VW1NZJPqcEPC/AxOP1D/ukzLmOuZZQ6Ka0krAe4nah7mQm8hSpJtEmUMOyJnWHlyzW 5/sb1DYCZq8M60TAb7NKEFbgs1zJ30rqFC0apy1d3FYlAOr6nooymr0K0QaDyqGB+g mx/1InCGj+lfKu+6C4CK9X2mqg3dDC3AR1olcCKFxgT+N8+TTvMDDxtLlzF30mykpc WymgJ8KHGWQLQ== From: SJ Park To: Cc: SJ Park , stable@vger.kernel.org, Andrew Morton , damon@lists.linux.dev, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [RFC PATCH v1.1 9/9] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() Date: Sun, 2 Aug 2026 09:26:30 -0700 Message-ID: <20260802162631.90304-10-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260802162631.90304-1-sj@kernel.org> References: <20260802162631.90304-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 67ad1f07c29a4..c79b854e1a971 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3014,7 +3014,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