Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <20200428051151.14879-1-sonnysasaka@gmail.com> <D2192131-CC65-4D4E-91BE-B1C3B1C12BC4@holtmann.org>
In-Reply-To: <D2192131-CC65-4D4E-91BE-B1C3B1C12BC4@holtmann.org>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Tue, 28 Apr 2020 10:25:05 -0700
Message-ID: <CAOxioN=2p23_K1VuFth5PwFAUR1oXcgs5GPHeM595OOivh6Y2Q@mail.gmail.com>
Subject: Re: [PATCH] Bluetooth: Handle Inquiry Cancel error after Inquiry Complete
To:     Marcel Holtmann <marcel@holtmann.org>
Cc:     BlueZ <linux-bluetooth@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Sender: linux-bluetooth-owner@vger.kernel.org
Precedence: bulk

Hi Marcel,

On Tue, Apr 28, 2020 at 2:47 AM Marcel Holtmann <marcel@holtmann.org> wrote=
:
>
> Hi Sonny,
>
> > After sending Inquiry Cancel command to the controller, it is possible
> > that Inquiry Complete event comes before Inquiry Cancel command complet=
e
> > event. In this case the Inquiry Cancel command will have status of
> > Command Disallowed since there is no Inquiry session to be cancelled.
> > This case should not be treated as error, otherwise we can reach an
> > inconsistent state.
> >
> > Example of a btmon trace when this happened:
> >
> > < HCI Command: Inquiry Cancel (0x01|0x0002) plen 0
> >> HCI Event: Inquiry Complete (0x01) plen 1
> >        Status: Success (0x00)
> >> HCI Event: Command Complete (0x0e) plen 4
> >      Inquiry Cancel (0x01|0x0002) ncmd 1
> >        Status: Command Disallowed (0x0c)
> > ---
> > net/bluetooth/hci_event.c | 19 +++++++++++++++----
> > 1 file changed, 15 insertions(+), 4 deletions(-)
> >
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index 966fc543c01d..0f3f7255779f 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -42,10 +42,9 @@
> >
> > /* Handle HCI Event packets */
> >
> > -static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff=
 *skb)
> > +static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_buff=
 *skb,
> > +                               u8 status)
> > {
> > -     __u8 status =3D *((__u8 *) skb->data);
> > -
> >       BT_DBG("%s status 0x%2.2x", hdev->name, status);
> >
> >       if (status)
> > @@ -3233,7 +3232,19 @@ static void hci_cmd_complete_evt(struct hci_dev =
*hdev, struct sk_buff *skb,
> >
> >       switch (*opcode) {
> >       case HCI_OP_INQUIRY_CANCEL:
> > -             hci_cc_inquiry_cancel(hdev, skb);
> > +             /* It is possible that we receive Inquiry Complete event =
right
> > +              * before we receive Inquiry Cancel Command Complete even=
t, in
> > +              * which case the latter event should have status of Comm=
and
> > +              * Disallowed (0x0c). This should not be treated as error=
, since
> > +              * we actually achieve what Inquiry Cancel wants to achie=
ve,
> > +              * which is to end the last Inquiry session.
> > +              */
> > +             if (*status =3D=3D 0x0c && !test_bit(HCI_INQUIRY, &hdev->=
flags)) {
> > +                     BT_DBG("Ignoring error of HCI Inquiry Cancel comm=
and");
> > +                     *status =3D 0;
> > +             }
>
> is there a problem with moving this check into hci_cc_inquiry_cancel? The=
n we don=E2=80=99t have to play any tricks with an extra parameter that is =
also included in the skb data struct itself.
I did that the first time, but turns out the updated status code is
needed in the bottom part of this function. So, if we are to move this
logic inside hci_cc_inquiry_cancel, we will need a way to update the
status, for example by having hci_cc_inquiry_cancel return a value, or
accept a pointer for the updated status value. Let me know which way
you prefer.
>
> I prefer we start using bt_dev_dbg and in this case maybe we just use bt_=
dev_warn or bt_dev_warn_ratelimited.
Ack, I will change BT_DBG to bt_dev_dbg.
>
> Regards
>
> Marcel
>