Re: [PATCH 2/2] bitmap: Add test for bitmap_cut()
On Mon, 15 Jun 2020 14:43:53 +0300
Andy Shevchenko wrote:
> On Mon, Jun 15, 2020 at 01:08:25PM +0200, Stefano Brivio wrote:
> >
> > [...]
> >
> > By the way, tests for 'parse', 'parse_user' and 'parselist' report
> > issues:
>
> I believe this [1] will fix it.
>
> [1]: 81c4f4d924d5 ("lib: fix bitmap_parse() on 64-bit big endian archs")
Yes, thanks, that works for me too.
--
Stefano
Re: [PATCH 2/2] bitmap: Add test for bitmap_cut()
On Mon, Jun 15, 2020 at 12:46:16PM +0300, Andy Shevchenko wrote: > On Mon, Jun 15, 2020 at 12:41:55PM +0300, Andy Shevchenko wrote: > > On Sun, Jun 14, 2020 at 07:40:54PM +0200, Stefano Brivio wrote: > > > Inspired by an original patch from Yury Norov: introduce a test for > > > bitmap_cut() that also makes sure functionality is as described for > > > partially overlapping src and dst. > > > > Taking into account recent fixes for BE 64-bit, do we have test cases for a > > such? > > It might be enough to have only these, but perhaps s390 guys can help? > > Alexander, can you apply this patch (w/o the first one, which is suppose to > fix) and confirm that you have test case failure, followed by applying first > one and confirm a fix? This failure goes away when patch #1 is applied: test_bitmap: [lib/test_bitmap.c:666] bitmaps contents differ: expected "0-16,18-19,21,24,26-27,29", got "1,3-4,6,9,11-12,14,16,18-19,21,24,26-27,29" Thus, I confirm. [...] > -- > With Best Regards, > Andy Shevchenko > >
Re: [PATCH 2/2] bitmap: Add test for bitmap_cut()
On Mon, Jun 15, 2020 at 01:08:25PM +0200, Stefano Brivio wrote:
> On Mon, 15 Jun 2020 12:46:16 +0300
> Andy Shevchenko wrote:
>
> > On Mon, Jun 15, 2020 at 12:41:55PM +0300, Andy Shevchenko wrote:
> > > On Sun, Jun 14, 2020 at 07:40:54PM +0200, Stefano Brivio wrote:
> > > > Inspired by an original patch from Yury Norov: introduce a test for
> > > > bitmap_cut() that also makes sure functionality is as described for
> > > > partially overlapping src and dst.
> > >
> > > Taking into account recent fixes for BE 64-bit, do we have test cases for
> > > a such?
> >
> > It might be enough to have only these, but perhaps s390 guys can help?
>
> There's no behaviour difference due to endianness in this test itself --
> just word size was a topic, hence that BITS_PER_LONG usage with
> redundant values (checked on i686).
>
> That is, if you have:
> { 0xUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL },
>
> then 1 as array subscript always denotes the second item (from the left)
> there, it doesn't matter how and where different architectures store it.
>
> Indeed, if bitmap_cut() directly addressed single bytes within the
> words, I would need to pay special attention there. The values I picked
> for these tests are also meant to show any issue in that sense.
>
> > Alexander, can you apply this patch (w/o the first one, which is suppose to
> > fix) and confirm that you have test case failure, followed by applying first
> > one and confirm a fix?
>
> I did that already on s390x (of course, I thought :)), I can confirm
> that. Without patch 1/2 the test also fails there:
>
> [ 20.917848] test_bitmap: [lib/test_bitmap.c:666] bitmaps contents differ:
> expected "0-16,18-19,21,24,26-27,29", got
> "1,3-4,6,9,11-12,14,16,18-19,21,24,26-27,29"
Thanks!
Reviewed-by: Andy Shevchenko
> If Alexander wants to test this on a z14 or z15, sure, it won't harm.
Sure.
> By the way, tests for 'parse', 'parse_user' and 'parselist' report
> issues:
I believe this [1] will fix it.
[1]: 81c4f4d924d5 ("lib: fix bitmap_parse() on 64-bit big endian archs")
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 2/2] bitmap: Add test for bitmap_cut()
On Mon, 15 Jun 2020 12:46:16 +0300
Andy Shevchenko wrote:
> On Mon, Jun 15, 2020 at 12:41:55PM +0300, Andy Shevchenko wrote:
> > On Sun, Jun 14, 2020 at 07:40:54PM +0200, Stefano Brivio wrote:
> > > Inspired by an original patch from Yury Norov: introduce a test for
> > > bitmap_cut() that also makes sure functionality is as described for
> > > partially overlapping src and dst.
> >
> > Taking into account recent fixes for BE 64-bit, do we have test cases for a
> > such?
>
> It might be enough to have only these, but perhaps s390 guys can help?
There's no behaviour difference due to endianness in this test itself --
just word size was a topic, hence that BITS_PER_LONG usage with
redundant values (checked on i686).
That is, if you have:
{ 0xUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL },
then 1 as array subscript always denotes the second item (from the left)
there, it doesn't matter how and where different architectures store it.
Indeed, if bitmap_cut() directly addressed single bytes within the
words, I would need to pay special attention there. The values I picked
for these tests are also meant to show any issue in that sense.
> Alexander, can you apply this patch (w/o the first one, which is suppose to
> fix) and confirm that you have test case failure, followed by applying first
> one and confirm a fix?
I did that already on s390x (of course, I thought :)), I can confirm
that. Without patch 1/2 the test also fails there:
[ 20.917848] test_bitmap: [lib/test_bitmap.c:666] bitmaps contents differ:
expected "0-16,18-19,21,24,26-27,29", got
"1,3-4,6,9,11-12,14,16,18-19,21,24,26-27,29"
If Alexander wants to test this on a z14 or z15, sure, it won't harm.
By the way, tests for 'parse', 'parse_user' and 'parselist' report
issues:
[ 20.390401] test_bitmap: loaded.
[ 20.394839] test_bitmap: parse: 4: input is 1, result is 0x1,
expected 0x1
[ 20.395011] test_bitmap: parse: 5: input is deadbeef, result is
0xdeadbeef, expected 0xdeadbeef
[ 20.395059] test_bitmap: parse: 6: input is 1,0, result is 0x1, expected
0x1
[ 20.395099] test_bitmap: parse: 7: input is deadbeef,
,0,1, result is 0x1, expected 0xdeadbeef
[ 20.396696] test_bitmap: parse: 8: input is deadbeef,1,0, result is 0x1,
expected 0x1
[ 20.396735] test_bitmap: parse: 9: input is baadf00d,deadbeef,1,0, result is
0x1, expected 0x1
[ 20.396835] test_bitmap: parse: 10: input is badf00d,deadbeef,1,0, errno is
-75, expected 0
[ 20.396878] test_bitmap: parse: 11: input is badf00d,deadbeef,1,0, errno is
-75, expected 0
[ 20.396913] test_bitmap: parse: 12: input is badf00d,deadbeef,1,0 , errno
is -75, expected 0
[ 20.396957] test_bitmap: parse: 13: input is , badf00d,deadbeef,1,0 , ,
errno is -75, expected 0
[ 20.396983] test_bitmap: parse: 14: input is , badf00d, ,, ,,deadbeef,1,0 ,
, errno is -75, expected 0
[ 20.397052] test_bitmap: parse: 16: input is 3,0, errno is 0, expected -75
[ 20.397712] test_bitmap: parse_user: 4: input is 1, result is 0x1,
expected 0x1
[ 20.397832] test_bitmap: parse_user: 5: input is deadbeef, result is
0xdeadbeef, expected 0xdeadbeef
[ 20.397928] test_bitmap: parse_user: 6: input is 1,0, result is 0x1,
expected 0x1
[ 20.398022] test_bitmap: parse_user: 7: input is deadbeef,
,0,1, result is 0x1, expected 0xdeadbeef
[ 20.398116] test_bitmap: parse_user: 8: input is deadbeef,1,0, result is
0x1, expected 0x1
[ 20.398209] test_bitmap: parse_user: 9: input is baadf00d,deadbeef,1,0,
result is 0x1, expected 0x1
[ 20.398301] test_bitmap: parse_user: 10: input is badf00d,deadbeef,1,0,
errno is -75, expected 0
[ 20.398393] test_bitmap: parse_user: 11: input is badf00d,deadbeef,1,0,
errno is -75, expected 0
[ 20.398484] test_bitmap: parse_user: 12: input is badf00d,deadbeef,1,0 ,
errno is -75, expected 0
[ 20.398574] test_bitmap: parse_user: 13: input is , badf00d,deadbeef,1,0 ,
, errno is -75, expected 0
[ 20.398666] test_bitmap: parse_user: 14: input is , badf00d, ,,
,,deadbeef,1,0 , , errno is -75, expected 0
[ 20.398794] test_bitmap: parse_user: 16: input is 3,0, errno is 0, expected
-75
[ 20.399906] test_bitmap: parselist: 14: input is '0-2047:128/256' OK, Time:
2641
[ 20.400914] test_bitmap: parselist_user: 14: input is '0-2047:128/256' OK,
Time: 19961
[ 20.421406] test_bitmap: all 1679 tests passed
and at a glance those *seem* to be bugs in the tests themselves, not in
the actual functions they test. Sure, they should be fixed, but I can't
take care of that right now.
--
Stefano
Re: [PATCH 2/2] bitmap: Add test for bitmap_cut()
On Mon, Jun 15, 2020 at 12:41:55PM +0300, Andy Shevchenko wrote:
> On Sun, Jun 14, 2020 at 07:40:54PM +0200, Stefano Brivio wrote:
> > Inspired by an original patch from Yury Norov: introduce a test for
> > bitmap_cut() that also makes sure functionality is as described for
> > partially overlapping src and dst.
>
> Taking into account recent fixes for BE 64-bit, do we have test cases for a
> such?
It might be enough to have only these, but perhaps s390 guys can help?
Alexander, can you apply this patch (w/o the first one, which is suppose to
fix) and confirm that you have test case failure, followed by applying first
one and confirm a fix?
> > Signed-off-by: Stefano Brivio
> > ---
> > v2:
> > - use expect_eq_bitmap() instead of open coding result check (Andy
> > Shevchenko)
> > - don't use uncommon Co-authored-by: tag (Andy Shevchenko), drop
> > it altogether as Yury asked me to go ahead with this and I haven't
> > heard back in a while. Patch is now rather different anyway
> > - avoid stack overflow, buffer needs to be five unsigned longs and
> > not four as 'in' is shifted by one, spotted by kernel test robot
> > with CONFIG_STACKPROTECTOR_STRONG
> >
> > lib/test_bitmap.c | 58 +++
> > 1 file changed, 58 insertions(+)
> >
> > diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
> > index 6b13150667f5..df903c53952b 100644
> > --- a/lib/test_bitmap.c
> > +++ b/lib/test_bitmap.c
> > @@ -610,6 +610,63 @@ static void __init test_for_each_set_clump8(void)
> > expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, );
> > }
> >
> > +struct test_bitmap_cut {
> > + unsigned int first;
> > + unsigned int cut;
> > + unsigned int nbits;
> > + unsigned long in[4];
> > + unsigned long expected[4];
> > +};
> > +
> > +static struct test_bitmap_cut test_cut[] = {
> > + { 0, 0, 8, { 0x000aUL, }, { 0x000aUL, }, },
> > + { 0, 0, 32, { 0xdadadeadUL, }, { 0xdadadeadUL, }, },
> > + { 0, 3, 8, { 0x00aaUL, }, { 0x0015UL, }, },
> > + { 3, 3, 8, { 0x00aaUL, }, { 0x0012UL, }, },
> > + { 0, 1, 32, { 0xa5a5a5a5UL, }, { 0x52d2d2d2UL, }, },
> > + { 0, 8, 32, { 0xdeadc0deUL, }, { 0x00deadc0UL, }, },
> > + { 1, 1, 32, { 0x5a5a5a5aUL, }, { 0x2d2d2d2cUL, }, },
> > + { 0, 15, 32, { 0xa5a5a5a5UL, }, { 0x00014b4bUL, }, },
> > + { 0, 16, 32, { 0xa5a5a5a5UL, }, { 0xa5a5UL, }, },
> > + { 15, 15, 32, { 0xa5a5a5a5UL, }, { 0x000125a5UL, }, },
> > + { 15, 16, 32, { 0xa5a5a5a5UL, }, { 0xa5a5UL, }, },
> > + { 16, 15, 32, { 0xa5a5a5a5UL, }, { 0x0001a5a5UL, }, },
> > +
> > + { BITS_PER_LONG, BITS_PER_LONG, BITS_PER_LONG,
> > + { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
> > + { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
> > + },
> > + { 1, BITS_PER_LONG - 1, BITS_PER_LONG,
> > + { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
> > + { 0x0001UL, 0x0001UL, },
> > + },
> > +
> > + { 0, BITS_PER_LONG * 2, BITS_PER_LONG * 2 + 1,
> > + { 0xa5a5a5a5UL, 0x0001UL, 0x0001UL, 0x0001UL },
> > + { 0x0001UL, },
> > + },
> > + { 16, BITS_PER_LONG * 2 + 1, BITS_PER_LONG * 2 + 1 + 16,
> > + { 0xUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL },
> > + { 0x2d2dUL, },
> > + },
> > +};
> > +
> > +static void __init test_bitmap_cut(void)
> > +{
> > + unsigned long b[5], *in = [1], *out = [0]; /* Partial overlap */
> > + int i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(test_cut); i++) {
> > + struct test_bitmap_cut *t = _cut[i];
> > +
> > + memcpy(in, t->in, sizeof(t->in));
> > +
> > + bitmap_cut(out, in, t->first, t->cut, t->nbits);
> > +
> > + expect_eq_bitmap(t->expected, out, t->nbits);
> > + }
> > +}
> > +
> > static void __init selftest(void)
> > {
> > test_zero_clear();
> > @@ -623,6 +680,7 @@ static void __init selftest(void)
> > test_bitmap_parselist_user();
> > test_mem_optimisations();
> > test_for_each_set_clump8();
> > + test_bitmap_cut();
> > }
> >
> > KSTM_MODULE_LOADERS(test_bitmap);
> > --
> > 2.27.0
> >
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
With Best Regards,
Andy Shevchenko
Re: [PATCH 2/2] bitmap: Add test for bitmap_cut()
On Sun, Jun 14, 2020 at 07:40:54PM +0200, Stefano Brivio wrote:
> Inspired by an original patch from Yury Norov: introduce a test for
> bitmap_cut() that also makes sure functionality is as described for
> partially overlapping src and dst.
Taking into account recent fixes for BE 64-bit, do we have test cases for a
such?
> Signed-off-by: Stefano Brivio
> ---
> v2:
> - use expect_eq_bitmap() instead of open coding result check (Andy
> Shevchenko)
> - don't use uncommon Co-authored-by: tag (Andy Shevchenko), drop
> it altogether as Yury asked me to go ahead with this and I haven't
> heard back in a while. Patch is now rather different anyway
> - avoid stack overflow, buffer needs to be five unsigned longs and
> not four as 'in' is shifted by one, spotted by kernel test robot
> with CONFIG_STACKPROTECTOR_STRONG
>
> lib/test_bitmap.c | 58 +++
> 1 file changed, 58 insertions(+)
>
> diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
> index 6b13150667f5..df903c53952b 100644
> --- a/lib/test_bitmap.c
> +++ b/lib/test_bitmap.c
> @@ -610,6 +610,63 @@ static void __init test_for_each_set_clump8(void)
> expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, );
> }
>
> +struct test_bitmap_cut {
> + unsigned int first;
> + unsigned int cut;
> + unsigned int nbits;
> + unsigned long in[4];
> + unsigned long expected[4];
> +};
> +
> +static struct test_bitmap_cut test_cut[] = {
> + { 0, 0, 8, { 0x000aUL, }, { 0x000aUL, }, },
> + { 0, 0, 32, { 0xdadadeadUL, }, { 0xdadadeadUL, }, },
> + { 0, 3, 8, { 0x00aaUL, }, { 0x0015UL, }, },
> + { 3, 3, 8, { 0x00aaUL, }, { 0x0012UL, }, },
> + { 0, 1, 32, { 0xa5a5a5a5UL, }, { 0x52d2d2d2UL, }, },
> + { 0, 8, 32, { 0xdeadc0deUL, }, { 0x00deadc0UL, }, },
> + { 1, 1, 32, { 0x5a5a5a5aUL, }, { 0x2d2d2d2cUL, }, },
> + { 0, 15, 32, { 0xa5a5a5a5UL, }, { 0x00014b4bUL, }, },
> + { 0, 16, 32, { 0xa5a5a5a5UL, }, { 0xa5a5UL, }, },
> + { 15, 15, 32, { 0xa5a5a5a5UL, }, { 0x000125a5UL, }, },
> + { 15, 16, 32, { 0xa5a5a5a5UL, }, { 0xa5a5UL, }, },
> + { 16, 15, 32, { 0xa5a5a5a5UL, }, { 0x0001a5a5UL, }, },
> +
> + { BITS_PER_LONG, BITS_PER_LONG, BITS_PER_LONG,
> + { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
> + { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
> + },
> + { 1, BITS_PER_LONG - 1, BITS_PER_LONG,
> + { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
> + { 0x0001UL, 0x0001UL, },
> + },
> +
> + { 0, BITS_PER_LONG * 2, BITS_PER_LONG * 2 + 1,
> + { 0xa5a5a5a5UL, 0x0001UL, 0x0001UL, 0x0001UL },
> + { 0x0001UL, },
> + },
> + { 16, BITS_PER_LONG * 2 + 1, BITS_PER_LONG * 2 + 1 + 16,
> + { 0xUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL },
> + { 0x2d2dUL, },
> + },
> +};
> +
> +static void __init test_bitmap_cut(void)
> +{
> + unsigned long b[5], *in = [1], *out = [0]; /* Partial overlap */
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(test_cut); i++) {
> + struct test_bitmap_cut *t = _cut[i];
> +
> + memcpy(in, t->in, sizeof(t->in));
> +
> + bitmap_cut(out, in, t->first, t->cut, t->nbits);
> +
> + expect_eq_bitmap(t->expected, out, t->nbits);
> + }
> +}
> +
> static void __init selftest(void)
> {
> test_zero_clear();
> @@ -623,6 +680,7 @@ static void __init selftest(void)
> test_bitmap_parselist_user();
> test_mem_optimisations();
> test_for_each_set_clump8();
> + test_bitmap_cut();
> }
>
> KSTM_MODULE_LOADERS(test_bitmap);
> --
> 2.27.0
>
--
With Best Regards,
Andy Shevchenko
[PATCH 2/2] bitmap: Add test for bitmap_cut()
Inspired by an original patch from Yury Norov: introduce a test for
bitmap_cut() that also makes sure functionality is as described for
partially overlapping src and dst.
Signed-off-by: Stefano Brivio
---
v2:
- use expect_eq_bitmap() instead of open coding result check (Andy
Shevchenko)
- don't use uncommon Co-authored-by: tag (Andy Shevchenko), drop
it altogether as Yury asked me to go ahead with this and I haven't
heard back in a while. Patch is now rather different anyway
- avoid stack overflow, buffer needs to be five unsigned longs and
not four as 'in' is shifted by one, spotted by kernel test robot
with CONFIG_STACKPROTECTOR_STRONG
lib/test_bitmap.c | 58 +++
1 file changed, 58 insertions(+)
diff --git a/lib/test_bitmap.c b/lib/test_bitmap.c
index 6b13150667f5..df903c53952b 100644
--- a/lib/test_bitmap.c
+++ b/lib/test_bitmap.c
@@ -610,6 +610,63 @@ static void __init test_for_each_set_clump8(void)
expect_eq_clump8(start, CLUMP_EXP_NUMBITS, clump_exp, );
}
+struct test_bitmap_cut {
+ unsigned int first;
+ unsigned int cut;
+ unsigned int nbits;
+ unsigned long in[4];
+ unsigned long expected[4];
+};
+
+static struct test_bitmap_cut test_cut[] = {
+ { 0, 0, 8, { 0x000aUL, }, { 0x000aUL, }, },
+ { 0, 0, 32, { 0xdadadeadUL, }, { 0xdadadeadUL, }, },
+ { 0, 3, 8, { 0x00aaUL, }, { 0x0015UL, }, },
+ { 3, 3, 8, { 0x00aaUL, }, { 0x0012UL, }, },
+ { 0, 1, 32, { 0xa5a5a5a5UL, }, { 0x52d2d2d2UL, }, },
+ { 0, 8, 32, { 0xdeadc0deUL, }, { 0x00deadc0UL, }, },
+ { 1, 1, 32, { 0x5a5a5a5aUL, }, { 0x2d2d2d2cUL, }, },
+ { 0, 15, 32, { 0xa5a5a5a5UL, }, { 0x00014b4bUL, }, },
+ { 0, 16, 32, { 0xa5a5a5a5UL, }, { 0xa5a5UL, }, },
+ { 15, 15, 32, { 0xa5a5a5a5UL, }, { 0x000125a5UL, }, },
+ { 15, 16, 32, { 0xa5a5a5a5UL, }, { 0xa5a5UL, }, },
+ { 16, 15, 32, { 0xa5a5a5a5UL, }, { 0x0001a5a5UL, }, },
+
+ { BITS_PER_LONG, BITS_PER_LONG, BITS_PER_LONG,
+ { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
+ { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
+ },
+ { 1, BITS_PER_LONG - 1, BITS_PER_LONG,
+ { 0xa5a5a5a5UL, 0xa5a5a5a5UL, },
+ { 0x0001UL, 0x0001UL, },
+ },
+
+ { 0, BITS_PER_LONG * 2, BITS_PER_LONG * 2 + 1,
+ { 0xa5a5a5a5UL, 0x0001UL, 0x0001UL, 0x0001UL },
+ { 0x0001UL, },
+ },
+ { 16, BITS_PER_LONG * 2 + 1, BITS_PER_LONG * 2 + 1 + 16,
+ { 0xUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL, 0x5a5a5a5aUL },
+ { 0x2d2dUL, },
+ },
+};
+
+static void __init test_bitmap_cut(void)
+{
+ unsigned long b[5], *in = [1], *out = [0]; /* Partial overlap */
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(test_cut); i++) {
+ struct test_bitmap_cut *t = _cut[i];
+
+ memcpy(in, t->in, sizeof(t->in));
+
+ bitmap_cut(out, in, t->first, t->cut, t->nbits);
+
+ expect_eq_bitmap(t->expected, out, t->nbits);
+ }
+}
+
static void __init selftest(void)
{
test_zero_clear();
@@ -623,6 +680,7 @@ static void __init selftest(void)
test_bitmap_parselist_user();
test_mem_optimisations();
test_for_each_set_clump8();
+ test_bitmap_cut();
}
KSTM_MODULE_LOADERS(test_bitmap);
--
2.27.0
