On Sun, Jun 5, 2022 at 11:51 AM Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> *Most* of the accesses to those connection flags seem to be with
> hci_dev_lock() held, and the ones that aren't can't possibly depend on
> atomicity since those things are currently copied around with random
> other "copy bitmaps" functions.
I've committed that patch as commit e1cff7002b71 ("bluetooth: don't
use bitmaps for random flag accesses").
That basically ends up reverting
a9a347655d22 ("Bluetooth: MGMT: Add conditions for setting
HCI_CONN_FLAG_REMOTE_WAKEUP")
6126ffabba6b ("Bluetooth: Introduce HCI_CONN_FLAG_DEVICE_PRIVACY device flag")
which did horrible things, and would end up overwriting the end of the
bitmap allocation on 32-bit architectures.
Luiz, if the reason for the change to use a bitmap type was because of
some atomicity concerns, then you can do that by
(a) change 'hci_conn_flags_t' to be an 'atomic_t' instead of a 'u8'
(b) change the regular accesses to it to use 'atomic_read/write()'
(c) change the "bitfield" operations to use 'atomic_or/andnot()'
but honestly, when it used to mix atomic ops
(set_bit/clear_bit/test_bit) with random non-atomic users
(bitmap_from_u64(), bitmap_to_arr32() etc) it was never atomic to
begin with.
Regardless, trying to use bitmaps for this was absolutely not the
right thing to ever do. It looks like gcc randomly started complaining
when 'bitmap_from_u64()' was changed, but it was buggy before that
too.
Linus
