| 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
| ||
|
Message-Id: <20241018183310.115850-1-sj@kernel.org>
Date: Fri, 18 Oct 2024 11:33:10 -0700
From: SeongJae Park <sj@...nel.org>
To: Zheng Yejian <zhengyejian@...weicloud.com>
Cc: SeongJae Park <sj@...nel.org>,
akpm@...ux-foundation.org,
sieberf@...zon.com,
shakeel.butt@...ux.dev,
foersleo@...zon.de,
damon@...ts.linux.dev,
linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/damon/vaddr: Fix issue in damon_va_evenly_split_region()
Hi Zheng,
Thank you for sharing this nice finding and fix! I have a few comments below.
On Fri, 18 Oct 2024 11:53:04 +0800 Zheng Yejian <zhengyejian@...weicloud.com> wrote:
> According to the logic of damon_va_evenly_split_region(), currently at
> least following split cases would not meet the expectation:
>
> Suppose DAMON_MIN_REGION=0x1000,
> Case1: Split [0x0, 0x1100) into 1 pieces, then the result would be
> acutually [0x0, 0x1000), but NOT the expected [0x0, 0x1100) !!!
Nice finding! However, as long as DAMON_MIN_REGION is respected, [0x0, 0x1100]
region could not be created. So, the problematic case cannot happen in real?
Please let me know if I'm missing something.
And, why would someone call the function with nr_pieces 1?
> Case2: Split [0x0, 0x3000) into 2 pieces, then the result would be
> acutually 3 regions:
> [0x0, 0x1000), [0x1000, 0x2000), [0x2000, 0x3000)
> but NOT the expected 2 regions:
> [0x0, 0x1000), [0x1000, 0x3000) !!!
Nice finding!
>
> The root cause is that when calculating size of each split piece in
> damon_va_evenly_split_region():
>
> `sz_piece = ALIGN_DOWN(sz_orig / nr_pieces, DAMON_MIN_REGION);`
>
> both the dividing and the ALIGN_DOWN may cause loss of precision,
> then each time split one piece of size 'sz_piece' from origin 'start' to
> 'end' would cause:
> 1. For the above Case1, the 'end' value of the split 1 piece is
> aligned but not updated!!!
> 2. For the above Case2, more pieces are split out than expected!!!
>
> To fix it, in this patch:
> - As for the expect to split 1 piece, just return 0;
As mentioned above, I think this is not needed, since the problematic case is
unreal.
> - Count for each piece split and make sure no more than 'nr_pieces';
> - Add above two cases into damon_test_split_evenly().
Thank you for adding tests!
>
> BTW, currently when running kunit test, DAMON_MIN_REGION is redefined
> as 1, then above ALIGN_DOWN cases may not be test, since every int
> value is ALIGN-ed to 1.
>
> After this patch, damon-operations test passed:
>
> # ./tools/testing/kunit/kunit.py run damon-operations
> [...]
> ============== damon-operations (6 subtests) ===============
> [PASSED] damon_test_three_regions_in_vmas
> [PASSED] damon_test_apply_three_regions1
> [PASSED] damon_test_apply_three_regions2
> [PASSED] damon_test_apply_three_regions3
> [PASSED] damon_test_apply_three_regions4
> [PASSED] damon_test_split_evenly
> ================ [PASSED] damon-operations =================
>
> Fixes: 3f49584b262c ("mm/damon: implement primitives for the virtual memory address spaces")
> Signed-off-by: Zheng Yejian <zhengyejian@...weicloud.com>
> ---
> mm/damon/tests/vaddr-kunit.h | 2 ++
> mm/damon/vaddr.c | 13 +++++++++----
> 2 files changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/mm/damon/tests/vaddr-kunit.h b/mm/damon/tests/vaddr-kunit.h
> index a339d117150f..b9a03e4e29e5 100644
> --- a/mm/damon/tests/vaddr-kunit.h
> +++ b/mm/damon/tests/vaddr-kunit.h
> @@ -300,6 +300,8 @@ static void damon_test_split_evenly(struct kunit *test)
> damon_test_split_evenly_fail(test, 0, 100, 0);
> damon_test_split_evenly_succ(test, 0, 100, 10);
> damon_test_split_evenly_succ(test, 5, 59, 5);
> + damon_test_split_evenly_succ(test, 4, 6, 1);
If my above assumption (the first problem is unreal) is not wrong, maybe this
test is not needed?
> + damon_test_split_evenly_succ(test, 0, 3, 2);
Nice.
> damon_test_split_evenly_fail(test, 5, 6, 2);
> }
>
> diff --git a/mm/damon/vaddr.c b/mm/damon/vaddr.c
> index 08cfd22b5249..1f3cebd20829 100644
> --- a/mm/damon/vaddr.c
> +++ b/mm/damon/vaddr.c
> @@ -67,10 +67,14 @@ static int damon_va_evenly_split_region(struct damon_target *t,
> unsigned long sz_orig, sz_piece, orig_end;
> struct damon_region *n = NULL, *next;
> unsigned long start;
> + int i;
Purpose of this variable is counting the number of splitted regions, and
comparing it against 'nr_pieces', right? Because nr_pieces is 'unsigned int',
let's make this 'unsigned int' type, too.
>
> if (!r || !nr_pieces)
> return -EINVAL;
>
> + if (nr_pieces == 1)
> + return 0;
> +
As mentioned above, I don't think this is not needed.
> orig_end = r->ar.end;
> sz_orig = damon_sz_region(r);
> sz_piece = ALIGN_DOWN(sz_orig / nr_pieces, DAMON_MIN_REGION);
> @@ -79,9 +83,11 @@ static int damon_va_evenly_split_region(struct damon_target *t,
> return -EINVAL;
>
> r->ar.end = r->ar.start + sz_piece;
> + /* origin region will be updated as the first one after splitting */
I don't think this comment is easy to understand. Let's just remove it.
> + i = 1;
> + n = r;
Why we need this? for 'nr_pieces == 1' case? If so, I don't think we need to
take care about the case for the above mentioned reason. Please let me know if
I'm missing something.
> next = damon_next_region(r);
> - for (start = r->ar.end; start + sz_piece <= orig_end;
> - start += sz_piece) {
> + for (start = r->ar.end; i < nr_pieces; start += sz_piece, i++) {
> n = damon_new_region(start, start + sz_piece);
> if (!n)
> return -ENOMEM;
> @@ -89,8 +95,7 @@ static int damon_va_evenly_split_region(struct damon_target *t,
> r = n;
> }
> /* complement last region for possible rounding error */
> - if (n)
> - n->ar.end = orig_end;
> + n->ar.end = orig_end;
Maybe this change is related with the above 'n = r' line? But, I don't think
we need that, as commented there.
>
> return 0;
> }
> --
> 2.25.1
Thanks,
SJ
Powered by blists - more mailing lists