linux-kernel - Re: [PATCH 1/2] mm/damon/core: modified and tunning damon_split_regions

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260114154622.100466-1-sj@kernel.org>
Date: Wed, 14 Jan 2026 07:46:21 -0800
From: SeongJae Park <sj@...nel.org>
To: JaeJoon Jung <rgbi3307@...il.com>
Cc: SeongJae Park <sj@...nel.org>,
	damon@...ts.linux.dev,
	linux-mm@...ck.org,
	linux-kernel@...r.kernel.org,
	rgbi3307@...e.com
Subject: Re: [PATCH 1/2] mm/damon/core: modified and tunning damon_split_regions_of()

Hello JaeJoon, thank you for continued interest in DAMON.

On Tue, 13 Jan 2026 21:16:42 +0900 JaeJoon Jung <rgbi3307@...il.com> wrote:

> Before modification:
>                                                              sz_region
>     |--------|--------|--------||--------|--------|--------|--------|
> nr_subs:     1        2        3        4        5                  9
> split random:    <----------- (*] randmon        LOST -------------->
> 
> When dividing sz_region at rand, the random value may be small, such as
> 1 or 2.  At this time, there is a problem that only the front areas
> corresponding to 1 and 2 are divided, and the remaining back area
> becomes too wide.  If the area is too wide, there will be many missed
> address access judgments.
> 
> After modification:
>                                                              sz_region
>     |--------|--------|--------|--------|--------|--------|--------||
> nr_subs:     1        2        3        4        5                  9
> split from   <------------ (sz_region / nr_subs) ------------------>
> 
> It is recommended to divide sz_region evenly in the ratio (sz_region /
> nr_subs) rather than using rand.  In this way, if you decide nr_subs well,
> you can logically match the number of divisions and their sizes.

I was thinking about how to reply to this patch.  Since it is taking unusually
long time, let me add short comments for direct future of this patch.

The existing code uses random() for a reason.  This change might break it.  Can
you further explain what was the point of the use of random(), and why this
change is not breaking it?

> 
> Signed-off-by: JaeJoon Jung <rgbi3307@...il.com>

Unless you can give me a convincing answer to my above question,

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

Same for your followup patch [1].  Btw, please send patches of same series as
one thread from next time.

[1] https://lore.kernel.org/20260113121731.31468-1-rgbi3307@gmail.com


Thanks,
SJ

[...]