[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABBYNZJfqAU-o7f9HhLCgTmL46WfwNQbM5NsCACsVVDLACMLYw@mail.gmail.com>
Date: Mon, 6 Jun 2022 23:00:13 -0700
From: Luiz Augusto von Dentz <luiz.dentz@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Yury Norov <yury.norov@...il.com>,
Marcel Holtmann <marcel@...tmann.org>,
Johan Hedberg <johan.hedberg@...il.com>,
"David S . Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, Guo Ren <guoren@...nel.org>,
linux-bluetooth <linux-bluetooth@...r.kernel.org>,
Netdev <netdev@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-csky@...r.kernel.org,
Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Alexander Gordeev <agordeev@...ux.ibm.com>,
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
Christian Borntraeger <borntraeger@...ux.ibm.com>,
Claudio Imbrenda <imbrenda@...ux.ibm.com>,
David Hildenbrand <david@...hat.com>,
Heiko Carstens <hca@...ux.ibm.com>,
Janosch Frank <frankja@...ux.ibm.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Sven Schnelle <svens@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>
Subject: Re: [PATCH] net/bluetooth: fix erroneous use of bitmap_from_u64()
Hi Linus,
On Sun, Jun 5, 2022 at 5:02 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> On Sun, Jun 5, 2022 at 11:51 AM Linus Torvalds
> <torvalds@...ux-foundation.org> 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.
Right, thanks for fixing it. About some of the changes perhaps we
should use BIT when declaring values in enum hci_conn_flags?
--
Luiz Augusto von Dentz
Powered by blists - more mailing lists