On Wed, Jul 15, 2020 at 08:40:05AM -0700, Luiz Augusto von Dentz wrote:
> Hi Patrick,
>
> On Wed, Jul 15, 2020 at 7:50 AM Patrick Steinhardt <ps@xxxxxx> wrote:
> >
> > Starting with the upgrade to v5.8-rc3, I've noticed I wasn't able to
> > connect to my Bluetooth headset properly anymore. While connecting to
> > the device would eventually succeed, bluetoothd seemed to be confused
> > about the current connection state where the state was flapping hence
> > and forth. Bisecting this issue led to commit 3ca44c16b0dc ("Bluetooth:
> > Consolidate encryption handling in hci_encrypt_cfm"), which refactored
> > `hci_encrypt_cfm` to also handle updating the connection state.
> >
> > The commit in question changed the code to call `hci_connect_cfm` inside
> > `hci_encrypt_cfm` and updating the connection state. But the conversion
> > didn't keep old behaviour of when the connection state is updated, which
> > now causes us to not properly update it anymore.
> >
> > Fix the issue by adding another parameter to the function that allows
> > callers to specify whether the connection state should be updated, which
> > allows us to restore previous behaviour.
> >
> > Fixes: 3ca44c16b0dc ("Bluetooth: Consolidate encryption handling in hci_encrypt_cfm")
> > Signed-off-by: Patrick Steinhardt <ps@xxxxxx>
> > ---
> > include/net/bluetooth/hci_core.h | 4 ++--
> > net/bluetooth/hci_event.c | 6 +++---
> > 2 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
> > index cdd4f1db8670..9abcc4a89abc 100644
> > --- a/include/net/bluetooth/hci_core.h
> > +++ b/include/net/bluetooth/hci_core.h
> > @@ -1381,13 +1381,13 @@ static inline void hci_auth_cfm(struct hci_conn *conn, __u8 status)
> > conn->security_cfm_cb(conn, status);
> > }
> >
> > -static inline void hci_encrypt_cfm(struct hci_conn *conn, __u8 status)
> > +static inline void hci_encrypt_cfm(struct hci_conn *conn, __u8 status, __u8 update_state)
> > {
> > struct hci_cb *cb;
> > __u8 encrypt;
> >
> > if (conn->state == BT_CONFIG) {
> > - if (status)
> > + if (update_state)
>
> The intent was actually to have if (!status) as it means the
> encryption has succeeded the state can be considered connected, so I
> wonder if we really need to introduce another parameter. Anyway as it
> is broken we need to come up with a fix rather quickly.
Yeah, I kind of figured that to be the case but wanted to go with the
"safe" fix of restoring old behaviour first. I'll test whether `if
(!status)` fixes the problem I'm seeing and will send a v2 in case it
does.
Patrick
Attachment:
signature.asc
Description: PGP signature
