Messages in this thread | | | From | Alexander Potapenko <> | Date | Mon, 25 Sep 2023 15:09:04 +0200 | Subject | Re: [PATCH v5 2/5] lib/test_bitmap: add tests for bitmap_{read,write}() |
| |
On Mon, Sep 25, 2023 at 2:23 PM Andy Shevchenko <andriy.shevchenko@linux.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); }
... [ 29.601614][ T1] test_bitmap: [lib/test_bitmap.c:1250] bitmaps contents differ: expected "960-963,966-967,969,971-973,976,978-979,981", got "963" ...
So it's probably expect_eq_bitmap() that is incorrectly rounding up the bitmap length somewhere (or maybe it is not supposed to be used for non-aligned bitmaps?) Looking further...
| |