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>
 <CAOxioN=2p23_K1VuFth5PwFAUR1oXcgs5GPHeM595OOivh6Y2Q@mail.gmail.com>
In-Reply-To: <CAOxioN=2p23_K1VuFth5PwFAUR1oXcgs5GPHeM595OOivh6Y2Q@mail.gmail.com>
From:   Sonny Sasaka <sonnysasaka@chromium.org>
Date:   Thu, 30 Apr 2020 10:11:28 -0700
Message-ID: <CAOxioN=1dP9W=WZ2TM+3RLbVmxBYkcrG0s4HiExihAXQ=0pJJg@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,

Could you take another look at my last proposal based on your
suggestion? If we are to move the logic inside hci_cc_inquiry_cancel,
we will need a way to update the status to the caller, 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.

On Tue, Apr 28, 2020 at 10:25 AM Sonny Sasaka <sonnysasaka@chromium.org> wr=
ote:
>
> Hi Marcel,
>
> On Tue, Apr 28, 2020 at 2:47 AM Marcel Holtmann <marcel@holtmann.org> wro=
te:
> >
> > Hi Sonny,
> >
> > > After sending Inquiry Cancel command to the controller, it is possibl=
e
> > > that Inquiry Complete event comes before Inquiry Cancel command compl=
ete
> > > 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_bu=
ff *skb)
> > > +static void hci_cc_inquiry_cancel(struct hci_dev *hdev, struct sk_bu=
ff *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_de=
v *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 even=
t right
> > > +              * before we receive Inquiry Cancel Command Complete ev=
ent, in
> > > +              * which case the latter event should have status of Co=
mmand
> > > +              * Disallowed (0x0c). This should not be treated as err=
or, since
> > > +              * we actually achieve what Inquiry Cancel wants to ach=
ieve,
> > > +              * 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 co=
mmand");
> > > +                     *status =3D 0;
> > > +             }
> >
> > is there a problem with moving this check into hci_cc_inquiry_cancel? T=
hen we don=E2=80=99t have to play any tricks with an extra parameter that i=
s 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 b=
t_dev_warn or bt_dev_warn_ratelimited.
> Ack, I will change BT_DBG to bt_dev_dbg.
> >
> > Regards
> >
> > Marcel
> >