linux-kernel - Re: [PATCH v5 2/5] lib/test_bitmap: add tests for bitmap

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: <CAG_fn=WX+yAFHtbsxSvd41P61jjWtFEePqOs_1AKGJcgaWfVag@mail.gmail.com>
Date:   Mon, 25 Sep 2023 16:54:00 +0200
From:   Alexander Potapenko <glider@...gle.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     catalin.marinas@....com, will@...nel.org, pcc@...gle.com,
        andreyknvl@...il.com, linux@...musvillemoes.dk,
        yury.norov@...il.com, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, eugenis@...gle.com,
        syednwaris@...il.com, william.gray@...aro.org
Subject: Re: [PATCH v5 2/5] lib/test_bitmap: add tests for bitmap_{read,write}()

On Mon, Sep 25, 2023 at 3:09 PM Alexander Potapenko <glider@...gle.com> wrote:
>
> On Mon, Sep 25, 2023 at 2:23 PM Andy Shevchenko
> <andriy.shevchenko@...ux.intel.com> wrote:
> >
> > On Mon, Sep 25, 2023 at 02:16:37PM +0200, Alexander Potapenko wrote:
> >
> > ...
> >
> > > > +/*
> > > > + * Test bitmap should be big enough to include the cases when start is not in
> > > > + * the first word, and start+nbits lands in the following word.
> > > > + */
> > > > +#define TEST_BIT_LEN (1000)
> > >
> > > Dunno why this didn't fire previously, but CONFIG_CPU_BIG_ENDIAN=y
> > > kernel reports mismatches here, presumably because the last quad word
> > > ends up partially initialized.
> >
> > Hmm... But if designed and used correctly it shouldn't be the issue,
> > and 1000, I believe, is carefully chosen to be specifically not dividable
> > by pow-of-2 value.
> >
>
> The problem manifests already right after initialization:
>
> static void __init test_bit_len_1000(void)
> {
>         DECLARE_BITMAP(bitmap, TEST_BIT_LEN);
>         DECLARE_BITMAP(exp_bitmap, TEST_BIT_LEN);
>         memset(bitmap, 0x00, TEST_BYTE_LEN);
>         memset(exp_bitmap, 0x00, TEST_BYTE_LEN);
>         expect_eq_bitmap(exp_bitmap, bitmap, TEST_BIT_LEN);
> }

The problem is that there's no direct analog of memset() that can be
used to initialize bitmaps on both BE and LE systems.
bitmap_zero() and bitmap_set() work by rounding up the bitmap size to
BITS_TO_LONGS(nbits), but there's no bitmap_memset() that would do the
same for an arbitrary byte pattern.
We could call memset(..., ..., BITS_TO_LONGS(TEST_BIT_LEN)), but that
would be similar to declaring a bigger bitmap and not testing the last
24 bits.

Overall, unless allocating and initializing bitmaps with size
divisible by sizeof(long), most of bitmap.c is undefined behavior, so
I don't think it makes much sense to specifically test this case here
(given that we do not extend bitmap_equal() in the patch set).