linux-kernel - Re: [PATCH] mm/damon/core: prevent unnecessary overflow in damos_set_effective

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20250821165911.79204-1-sj@kernel.org>
Date: Thu, 21 Aug 2025 09:59:11 -0700
From: SeongJae Park <sj@...nel.org>
To: Quanmin Yan <yanquanmin1@...wei.com>
Cc: SeongJae Park <sj@...nel.org>,
	akpm@...ux-foundation.org,
	damon@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	linux-mm@...ck.org,
	wangkefeng.wang@...wei.com,
	zuoze1@...wei.com,
	apanyaki@...zon.com
Subject: Re: [PATCH] mm/damon/core: prevent unnecessary overflow in damos_set_effective_quota()

On Thu, 21 Aug 2025 20:55:55 +0800 Quanmin Yan <yanquanmin1@...wei.com> wrote:

> On 32-bit systems, the throughput calculation in function
> damos_set_effective_quota() is prone to unnecessary multiplication
> overflow. Using mult_frac() to fix it.
> 
> Andrew Paniakin also recently found and privately reported this
> issue, on 64 bit systems. This can also happen on 64-bit systems,
> once the charged size exceeds ~17 TiB. On systems running for long
> time in production, this issue can actually happen.
> 
> More specifically, when a DAMOS scheme having the time quota run
> for longtime, throughput calculation can overflow and set esz too
> small. As a result, speed of the scheme get unexpectedly slow.
> 
> Fixes: 1cd243030059 ("mm/damon/schemes: implement time quota")
> Cc: <stable@...r.kernel.org> # 5.16.x
> Signed-off-by: Quanmin Yan <yanquanmin1@...wei.com>
> Reported-by: Andrew Paniakin <apanyaki@...zon.com>
> Closes: N/A # privately reported

Reviewed-by: SeongJae Park <sj@...nel.org>


Thanks,
SJ

[...]