From nobody Sat Sep 26 14:37:53 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 213F648424A; Mon, 31 Aug 2026 14:03:03 +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=1788184984; cv=none; b=FCHhqD+U2cyxffX1b94eHoCW2/yiPRaXXQydyjBUSbyhc2kowBcpp2aiKpnVG+pzKHJXNoVPqVh3a3eeSYQ3wjmoBhV6bxbhwm1aC+d5zYHg/STCOqciuXzLEoF9TzfnSBmqJG8SkMtGy2JeNmeBvP+w/XmNdCKJs+s+lP2/MvY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184984; c=relaxed/simple; bh=c8YnLYM9gCkCamNMX4Ifu9ihjCO2crXUFIBol3Mz1aU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mgTZRnUGfaKuSxI7fqh94XJEi1GZ0aiKRPDaw+xnc83Cj6GqcvuDxzT4jg111Cw0rNBl79njakJN+gj6tW/s5yS/kQbz5fULibghHUQJrzj9jRfNCID8mddrui5p35ewNFR1QmmcyPsLjcEV0UEe2Pp4lZXAD/pCMWFF2O455hQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=h+1eIXDe; 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="h+1eIXDe" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC6771F00A3F; Mon, 31 Aug 2026 14:03:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788184983; bh=ccJR9KUzvn7k6BzhoDEjN3sQrL1C2MxY/yOiNOzvC90=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=h+1eIXDeQBAQUEQT+BHPoIt3p/SRP8E+YgRQDpNx0ek9JHPXbuwO0QBybw+PfjfrZ hHRD5xsWcY4EoIhMgDT5cKTMNKxOib1aMBeU16mcgv74zbIVZWmtnqNJN7V06osC1H fGo60DV1jRBKLrPXpVjoq7fpmZQixJNKqZrtZiyfvmDTetdnUjdoTkurf8aSfVAOC8 6R5+j/oVhpV9iY6JWJzQf9zH4CJCLSG+WS3q2Qyshrnr6PK/kv41ElGi8FUn6W/3lq 0CHnlRxIWF45bMsV6ZfHPw9oroitEgD6q9hNcqHfNa5f4YCvca5kLlfldmIZyoXVe6 oBDRf+zfa/ZXg== 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.2 1/8] mm/damon/core: skip applying scheme if region split for quota fails Date: Mon, 31 Aug 2026 07:02:40 -0700 Message-ID: <20260831140254.72004-2-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260831140254.72004-1-sj@kernel.org> References: <20260831140254.72004-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 Sat Sep 26 14:37:53 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 7C3CB484255; Mon, 31 Aug 2026 14:03:03 +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=1788184984; cv=none; b=eEdD9fVGQ7aQhdGR0KXMgIQwfDdP/dD4Y1JtRIdAEVefSzkwjgHjBJAaY776DRB2q67Ran6whC6J/K4T1+wqjNmSjO21eDkO3Wrmp0LUlZF1VW2LfIqV//gypoLbPg2vHhXqu4A7TCIHJ0ruTEKA37MCQ21D1ghlwmz95czzfjM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184984; c=relaxed/simple; bh=35/yin/QF8t3Kqfg+UAOrsmVX85pqU2Iyl2wuXO5t+0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=MISSo033wv3cvahh5qPg8IT2px8UNwL24DUh67bVoYA25r+aDEsfcP/K+VX3wM9yrwdE8VrsVVNN9r9/pOAgxwjPTmvOl7lTgt5hIYPk1p30FXvPUBbVU9pPSTLQgZHPPFFaACUYnRWEMvfV9Y/SaSCruJOrc3C4NqH8xZvoYHs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=irD4Ae4D; 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="irD4Ae4D" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1CBBF1F000E9; Mon, 31 Aug 2026 14:03:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788184983; bh=7ZB1yfEGzN5K33ID0e3bcOFkHhvifJ8hhhrNtAvrugg=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=irD4Ae4DKcf8PeVHbMIoXVmCG2XKWzQmLktHoyVCc/ltspDG7jkbi1VoTpdxAMGrw oEb7Xpdf3Fn6kS9cnBqas4zMMgM0LGPOyRcV5i4IQW5WjdW18jH6NGKAR+Gh4Oa4cw 0R1k0ICtEq6r/PKzIwLJQcuIcrV+y5J3NzWZzGl7jDAaaXfWZaWonfmraI2LYdS1wB rWDVbqw5wgtHIqvUJAci4RFc/frCAhzqnU3V0k2h8ThWh1yTO81ZCBJmI32YtBadrF eGyQDgWxzJM1pYctbEK+t4pRduc15P5dHwm92jbb/3JMWLkPXWSgHA8cMYlrVjJ4ih RpmPGuf95qGpA== 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.2 2/8] mm/damon/paddr: respect folio end for DAMOS_STAT Date: Mon, 31 Aug 2026 07:02:41 -0700 Message-ID: <20260831140254.72004-3-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260831140254.72004-1-sj@kernel.org> References: <20260831140254.72004-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 14:37:53 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 C76454854FA; Mon, 31 Aug 2026 14:03:03 +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=1788184985; cv=none; b=lk0TMtmbvPn65W/u9Ay74mPnkKQbeCMKTY0IukSVfHA1lxnrQjh7rNI+xBbENv/0kmmczRBZzfdEpLWbtJtwmKrSFRhXboUoy0+vsif1bkG5G/1dJFH/IiVL1Gqbmwj+vs+bNvzrR/i88XrC1sqdzK34IHA5yQEpHzKp+WPNoUE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184985; c=relaxed/simple; bh=3tuXFYxnY5whCfMb9BBfKAgRQ7zxuSBaL+SQQ8TayGI=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=aDSr/2A18taaYQ6m+HVTsHg4G9db8E5NRTZ18pLnDcY2vIRBmbRrGmyUY64awxgOjjpG51uNO4G3IxVWR/aTb68aMtfbKR9/4DnL8tAFT5ovjtJ+HmmEaUcasYlTWc4IpvGB4krAcYmEFc7Ml0o33rKuA120eVc6oL5w1763inY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=FXnBJtsg; 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="FXnBJtsg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 788731F00ACA; Mon, 31 Aug 2026 14:03:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788184983; bh=l4DJBfV8Ln2wiu4MTHaklCvhtPpo+9nKnYvuVasq3nI=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=FXnBJtsg4T/jdCIgbGNIC7C9lZLwx9En+qSGSYWcf9S3ezctloyO7ts7ywqdmktJq YWcG5xRWBaNtZq3U/tIOgdKFb33eIS3WW1JOO78jEVYc4Uum6uF7Sg/bglLZ5xy1Ny JqjPHMrVQSr873qz79bpF3N8gA9gcEGlINcxVAnlbZjVSEjlkJLLf7srW4adVF6fh6 rwYMfUml2hzc5cnMeebrNnfZn7BOBT70fjdjD7iit+C8LB0ssUQ/yw5TH9u5lVImZX vxlRlhg6nDprdjscFmkvAZYV/mkjjq1jjGXkKExEmuYjEpt3oXhR89WDDIsHUpNgim 5QXNf/mkEueVw== 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.2 3/8] mm/damon/paddr: respect folio end for DAMOS actions except STAT Date: Mon, 31 Aug 2026 07:02:42 -0700 Message-ID: <20260831140254.72004-4-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260831140254.72004-1-sj@kernel.org> References: <20260831140254.72004-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 14:37:53 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 2FA664854FC; Mon, 31 Aug 2026 14:03:04 +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=1788184985; cv=none; b=igOj5B6pZQvJHicIhIHPhkDUu4vim/nykhhgSjMv0axQPcfCtYAZBrHLnCdRr+zDLrAeCjpj9ImJWWpD5x9rV5pw7A8HgG2SflgOFvO7am5CNSog+c2w5nzrjnMJA0IAnVKkh5F70/tyG6ypwc1D2fCUtF2Q+MYA5Hg3ZCQaFP0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184985; c=relaxed/simple; bh=5AGJ58CxaHUHnA7OwFTsM+2rMQoeaY6UpbD7qoJcoXk=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=BvWxT8grh2jMa/ZCbF+LxUsiiROuQkh9aPbX4/CXhXevHSU5C+pggX6MDZHqiADN/d9AgMJ+1uVrOm7sFdqZXAwqVF3AAKQ1j2hYZUyic5dGkbbK7GL6Dkfwf2K8OzEGQw+DLgSL3t/gSHU33kp37WEEt3QbKpBs04AD01qAwCQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TGzATSIN; 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="TGzATSIN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D5E201F00ACF; Mon, 31 Aug 2026 14:03:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788184984; bh=nSTjwnDV8A+NiGPVQu+FC6bukzN4Edj/bjp5VqLzRxU=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=TGzATSINz42tKbEmPPTcS4J9tASvuhG6q2ioTy7mYUo2FOsQA+bY3ccQjSzWis/QN QMqkOCwDM5mJRH1zLaR421tWxE1piSSa1KRtVKWamXiwOzmoitvQnfWHvW+dl/DYA9 75rR7U7JuWkaK55dlUNdvknDGqIDpIUPTvVVnZJllJ5v0FI6IDWa8xWeQn9kDr7Q5v otERl2mpbErQaw/3QwaR2o64E5Z0ZzJ5KYuqTbM+lgGUQ9fqY7XgFZcF3/pDQjrCaF TlVkTEHyEuZ2hhpTttLuv9uK2OR5eWtZVA5uk8LTaGf2kOnSGkilVygLGQ+z5MjqZg x1hdN0POOUXcQ== 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.2 4/8] mm/damon/vaddr: respect folio end for DAMOS_STAT Date: Mon, 31 Aug 2026 07:02:43 -0700 Message-ID: <20260831140254.72004-5-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260831140254.72004-1-sj@kernel.org> References: <20260831140254.72004-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 14:37:53 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 87C9F4854ED; Mon, 31 Aug 2026 14:03:04 +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=1788184985; cv=none; b=tbGQYDtGkDzLETII/xV+xmv+SveSNUO3cctP2z8eIK5pAYkeOWUMkuEzq3NcE1H0NEAvsapL2+9y3t8OB92cYa15TlCKFjYh20MKdZQUsWW7IP62LlZQnYlkw3AQTdsIosCgv+ZWwnvXA7qVBAIFQoSNRh8eoKjKLp5ZRoMLbJo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184985; c=relaxed/simple; bh=6Z73CbNxQYTOYNM3TzN9z5SgCwrzw1We6fTUP5ae8l4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=l3TChwviR91+0nIUqjCJ1hF/M98g2QJV+wgm72qAYn6BWtQqyKsfQUQkefGtD9Hh1ioPY/p+vMhgLEfbM4CWwYtj9S1WwfEwoh5uRVqzhVtFZT7Ewy72a868JRDX4XBk5B4z+DPu69d7Z4FGnEMBOEnvsDypip6uljJeIELIt/o= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HxqPaCWX; 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="HxqPaCWX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3E5421F00A3E; Mon, 31 Aug 2026 14:03:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788184984; bh=SLM/iGuOERBTFxu8mql/4ATf4p59p9Me6R2GTZoj17M=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=HxqPaCWXz36XYrXZs36tURpnzE1QQPLIHZn2GbhatQy2eK0bA553g1f0VORg84K/2 5vKwVliPAEhIA0mNE2KhbbBvOjRZJYBjNDvZ+FAEBoIriAFNJBEqWG6XwvuayoWSYk 9XxP809cm+ltP4wIzZn7B2EMMcRVPJXOU25t6/NDfITTCZ2HLNkqF5EVmlgZ1TSnbC dueUwMJrECkZvyiEgx7jatMUkCH0mP0AWwHQREdJstM6/nOZVMKFOFW2ZiGz/JDyTd le31dNV1yajdLVpUTGIErxG5kD0ICCh/glTX1Uq4tDo5VofEulopGIAJAMi6UnxPJt zSg9U0vHUYMMA== 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.2 5/8] mm/damon/vaddr: respect folio end for DAMOS_MIGRATE_{HOT,COLD} Date: Mon, 31 Aug 2026 07:02:44 -0700 Message-ID: <20260831140254.72004-6-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260831140254.72004-1-sj@kernel.org> References: <20260831140254.72004-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 14:37:53 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 DB95B485508; Mon, 31 Aug 2026 14:03:04 +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=1788184986; cv=none; b=ByVdPLYoqojnl2c0XbBnO2L2XSl/ik1EWg3trDZq5unlay0BKqPLAVVS1yapqUZg+OeDRpuQsB7NF+15OQSUxfBdIpawYE60Tx3xCkQdh75Mh86DQ7mVqJovGpVRG4alVSAgeinJgo9i70B43dN/+oKJOLUWK8GdGDTAwhOLymY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184986; c=relaxed/simple; bh=1/nML6wnR05rkV9jNVuuWopWlORtCjTUs8FNgIFWA4w=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=X7g6CV6F13901/7YikHeZk4K05fSf0A0i25UokZbSaPXChnii2kyrGBm/TfCuANiEKHzx/x0D0BdmYTinzL39NzXRkvw7Wb5Yk6FctBJ/TiYJF7mK/N381yoDrSM/nYt8OrMdizfLyPM3IGShZ5r2cehQqhiAW9LmOsa5NSjY8Q= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=IS4NaUCZ; 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="IS4NaUCZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97BF51F00ADB; Mon, 31 Aug 2026 14:03:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788184984; bh=XKdCBVqYdsKdXO80RoHHV0o5QsCfADzPQf1ZzSc7B9k=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=IS4NaUCZQl4owxLyOXkjofnED5AIG5ZNyQRpkBVZBoyMt8ateeyXPEa7lNhU6i4J6 OTne7u4RNdgEO8kTKPD835bdYHYEIzzIQsr5p73sCK04IEq+aDZU4YtXGL9/pCaiYr p0M+iMo+J64J/7zmfywqh5Eg8+fE6hGs9MEkbpP7sV94aXy52aO7mNVdDsIV9B8Fz7 j9fPrxqbBOFfNuY2etAIKQua52nNoNhmwemNj6VzAu0yVgptcjyIMLlSBkrD5s8WK9 TR4tehQpFQtRK9ajPeTGv+B1PNb1AcKYep11zfhv0Eh+3+1Lz4kHLDd2NQWjmQ05HJ nH3HY0AzQivCw== 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.2 6/8] mm/damon/core: handle extreme memory state in damon_get_node_mem_bp() Date: Mon, 31 Aug 2026 07:02:45 -0700 Message-ID: <20260831140254.72004-7-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260831140254.72004-1-sj@kernel.org> References: <20260831140254.72004-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 e2900d0c984c9..75d71ac09515e 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2816,6 +2816,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 14:37:53 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 44586485511; Mon, 31 Aug 2026 14:03:05 +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=1788184986; cv=none; b=fyAk4p0bq8i4VC9pxD4TM+Hejd9N8bEo+Ao2csFI0s5okWDWgULJd8Eb54W9lTFG/4mB9ww4MccU7+ewfpMb6wiO3SmqbWz+YzRSJZVtqONg5PapE0yW59Ozgp2KI0RxjLwQHu0YatMHn395Eq4aGEPOvcIWXGaX0g7regOuGRc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184986; c=relaxed/simple; bh=axrgDohB9pRR8QC5Ey27g+zeND1mCd5WgD3HP/J4WSg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Heei2wg+1l3v8PBbxfdGEeFVsiKk7BRQPZowyUWJeQ5870n350Dkih0/McXDOMwscEsAkMNYcn+k9gSxEvArjg1sgViXwKvyD+bQ2aE5xdq5cRw/OMZNgs92v8wtDW1byezQiBeQ45+OmVYnxxqzaKAIdI4dyCRDN1ISFiphcBs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oJxpLDdV; 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="oJxpLDdV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA3581F000E9; Mon, 31 Aug 2026 14:03:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788184985; bh=wjxFgW2qNu2RQvNA0pBq7+cQKGiXodxnzF3g5CFurUE=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=oJxpLDdVlPHJRD4OBQA0YEmwv5RdeoyTODGHJk9zi6EAtfAJONJ12tMhjaLQE1cQS K0bCOwsuKK8My/5RD8Dac+hvm0QNFuUtBB4m122d1FgrK+mIhgUwZosoipv0Vb+FDk d83/CCEP66tbJ5ezQ6GmckTsnB7MUtDz+QoTH+HJwKTBoI0SJjnQFAMf+uBGViCT10 TFjkYPQk8HRnfu2IMh8OxjHkCxn4BQSV8vhx2rvvdORWLOJP9dSfrF+KTHkEJhsxnG 2ZpC9BBom8O8JJhlIWu462KRFCinaOzmClyX0wS8idLOa9EwGr2T4TW5XeOPHQn5di DtyQk2vgwPyjg== 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.2 7/8] mm/damon/core: handle extreme memory state in get_node_memcg_used_bp() Date: Mon, 31 Aug 2026 07:02:46 -0700 Message-ID: <20260831140254.72004-8-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260831140254.72004-1-sj@kernel.org> References: <20260831140254.72004-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 75d71ac09515e..3779a04753061 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -2863,6 +2863,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 14:37:53 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 8E886485CC1; Mon, 31 Aug 2026 14:03:05 +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=1788184986; cv=none; b=LtjXfLrnLmXvVUDfdAYQmI/zeO7TF/Y8vgoKyUd0fDXhK/j/urFzsQb/1oM4mC4wpe5xYh9zBwhot1Wh25l1Gw+5s/y0RhZ8642aw2RLSZePyXWlTJqKb+7lwmgUnwKAXhj8wGPrDTftKrIAg8AbtwtnG7Lg+5yK+X23AcxFj+E= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788184986; c=relaxed/simple; bh=lj/M1S5oaN42+56NlgGpIrZFtQOGxHB9iPCOijXVAX4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ATBn8aEFC3h0JdPx4dQYOUBACOy2THJ6AE7WMIkQfuM7KFBGkIeAgeRYKCT49WhKM07GMQPyFE70mFjx8n/UavAcwttCvvCRiO1jjesBzd3i1eYj1ppqjwRYxcMu4YYqKMp4tNh6C/lyLRUuf0HTJypyJnNGOtt/vVA02TrSfjM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=erWnS5qg; 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="erWnS5qg" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4B32B1F00ACA; Mon, 31 Aug 2026 14:03:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1788184985; bh=W4ZULCHKs962Ql2lXNfqffyY3ieZ1mpdjWXyoNcHe50=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=erWnS5qgR382J6JC8z3nVk1ADCqsV8VhofU2Ph+h8YZCbWmv4FeaOqyakgTD3sVT6 SCDWU3vMlqX54v/PG7m1wVOXEswl6nXm00wz0VJf1/lwCiwoCY6x84Nr8suHAxrml1 HYX2AqXO5O0XBw0XgDnmhCcAsrFQG6jZCOXpgTM7chqvOzAfbTmkPZRdUFtgHqupVn KFECZgtDxf1hYRvQLoN0g0494AS6/lMMnnPUqTbS1HlN3doLwddGJzAqXf8UQr5gMo Wo5XQy6dUpXn7VLZLO5JQ+v4igVQ51FDFI8oDOcG+r5CGMMu3QBHsVi/DP4Xbz3rs4 5HnIhItzFoL/Q== 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.2 8/8] mm/damon/core: handle extreme memory state in get_in_active_mem_bp() Date: Mon, 31 Aug 2026 07:02:47 -0700 Message-ID: <20260831140254.72004-9-sj@kernel.org> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260831140254.72004-1-sj@kernel.org> References: <20260831140254.72004-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 3779a04753061..f8dddbff74a77 100644 --- a/mm/damon/core.c +++ b/mm/damon/core.c @@ -3015,7 +3015,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