Re: mainline build failure due to 0a97953fd221 ("lib: add bitmap_{from,to}_arr64")

[Yury Norov]

On Sun, Jun 05, 2022 at 11:48:22AM +0100, Sudip Mukherjee wrote:
> Hi All,
> 
> The latest mainline kernel branch fails to build for "arm allmodconfig"
> and "csky allmodconfig".
> 
> "arm allmodconfig" fails with the error:
> 
> In file included from ./include/linux/string.h:253,
>                  from ./include/linux/bitmap.h:11,
>                  from ./include/linux/cpumask.h:12,
>                  from ./include/linux/smp.h:13,
>                  from ./include/linux/lockdep.h:14,
>                  from ./include/linux/mutex.h:17,
>                  from ./include/linux/rfkill.h:35,
>                  from net/bluetooth/hci_core.c:29:
> In function 'fortify_memcpy_chk',
>     inlined from 'bitmap_copy' at ./include/linux/bitmap.h:254:2,
>     inlined from 'bitmap_copy_clear_tail' at ./include/linux/bitmap.h:263:2,
>     inlined from 'bitmap_from_u64' at ./include/linux/bitmap.h:540:2,
>     inlined from 'hci_bdaddr_list_add_with_flags' at net/bluetooth/hci_core.c:2156:2:
> ./include/linux/fortify-string.h:344:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
>   344 |                         __write_overflow_field(p_size_field, size);
> 
> 
> And, "csky allmodconfig" fails with the error:
> 
> In file included from ./include/linux/cpumask.h:12,
>                  from ./include/linux/mm_types_task.h:14,
>                  from ./include/linux/mm_types.h:5,
>                  from ./include/linux/buildid.h:5,
>                  from ./include/linux/module.h:14,
>                  from net/bluetooth/mgmt.c:27:
> In function 'bitmap_copy',
>     inlined from 'bitmap_copy_clear_tail' at ./include/linux/bitmap.h:263:2,
>     inlined from 'bitmap_from_u64' at ./include/linux/bitmap.h:540:2,
>     inlined from 'set_device_flags' at net/bluetooth/mgmt.c:4534:4:
> ./include/linux/bitmap.h:254:9: error: 'memcpy' forming offset [4, 7] is out of the bounds [0, 4] of object 'flags' with type 'long unsigned int[1]' [-Werror=array-bounds]
>   254 |         memcpy(dst, src, len);
>       |         ^~~~~~~~~~~~~~~~~~~~~
> In file included from ./include/linux/kasan-checks.h:5,
>                  from ./include/asm-generic/rwonce.h:26,
>                  from ./arch/csky/include/generated/asm/rwonce.h:1,
>                  from ./include/linux/compiler.h:248,
>                  from ./include/linux/build_bug.h:5,
>                  from ./include/linux/container_of.h:5,
>                  from ./include/linux/list.h:5,
>                  from ./include/linux/module.h:12,
>                  from net/bluetooth/mgmt.c:27:
> net/bluetooth/mgmt.c: In function 'set_device_flags':
> net/bluetooth/mgmt.c:4532:40: note: 'flags' declared here
>  4532 |                         DECLARE_BITMAP(flags, __HCI_CONN_NUM_FLAGS);
>       |                                        ^~~~~
> ./include/linux/types.h:11:23: note: in definition of macro 'DECLARE_BITMAP'
>    11 |         unsigned long name[BITS_TO_LONGS(bits)]
> 
> 
> For both the failures, git bisect points to:
> 0a97953fd221 ("lib: add bitmap_{from,to}_arr64")
> 
> 
> And, reverting it on top of mainline branch has fixed both the build failures.

Hi Sudip,

Thanks for pointing at this.

In the patch you mentioned, silent typecasting from to u64 has been
replaced with explicit memory dereference, and it spotted -Warray-bounds:

 static inline void bitmap_from_u64(unsigned long *dst, u64 mask)
 {
-       dst[0] = mask & ULONG_MAX;
-
-       if (sizeof(mask) > sizeof(unsigned long))
-               dst[1] = mask >> 32;
+       bitmap_from_arr64(dst, &mask, 64);
 }

The problem is that bluetooth code declares current_flags as u32, and 
later applies 64-bit function to convert it to bitmap.

In the bluetooth code, using bitmap_from_u64 is incorrect because of
that, and because the length of bitmap in that case is __HCI_CONN_NUM_FLAGS,
which is 2, not 64. The simplest fix is to switch to bitmap_from_arr32.

I'll send a fix shortly.

Thanks,
Yury