All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sonny Sasaka <sonnysasaka@chromium.org>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: BlueZ <linux-bluetooth@vger.kernel.org>
Subject: Re: [PATCH] Bluetooth: Handle Inquiry Cancel error after Inquiry Complete
Date: Thu, 30 Apr 2020 10:11:28 -0700	[thread overview]
Message-ID: <CAOxioN=1dP9W=WZ2TM+3RLbVmxBYkcrG0s4HiExihAXQ=0pJJg@mail.gmail.com> (raw)
In-Reply-To: <CAOxioN=2p23_K1VuFth5PwFAUR1oXcgs5GPHeM595OOivh6Y2Q@mail.gmail.com>

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> wrote:
>
> 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 complete
> > > 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 = *((__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 event, in
> > > +              * which case the latter event should have status of Command
> > > +              * Disallowed (0x0c). This should not be treated as error, since
> > > +              * we actually achieve what Inquiry Cancel wants to achieve,
> > > +              * which is to end the last Inquiry session.
> > > +              */
> > > +             if (*status == 0x0c && !test_bit(HCI_INQUIRY, &hdev->flags)) {
> > > +                     BT_DBG("Ignoring error of HCI Inquiry Cancel command");
> > > +                     *status = 0;
> > > +             }
> >
> > is there a problem with moving this check into hci_cc_inquiry_cancel? Then we don’t 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
> >

  reply	other threads:[~2020-04-30 17:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-28  5:11 Sonny Sasaka
2020-04-28  9:47 ` Marcel Holtmann
2020-04-28 17:25   ` Sonny Sasaka
2020-04-30 17:11     ` Sonny Sasaka [this message]
2020-05-05 23:42       ` Marcel Holtmann
2020-05-06 19:55         ` Sonny Sasaka
2020-05-13  7:34           ` Marcel Holtmann
2020-05-13 18:51             ` Sonny Sasaka
2020-05-06 19:57         ` Sonny Sasaka
2020-05-12 19:34           ` Sonny Sasaka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOxioN=1dP9W=WZ2TM+3RLbVmxBYkcrG0s4HiExihAXQ=0pJJg@mail.gmail.com' \
    --to=sonnysasaka@chromium.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    --subject='Re: [PATCH] Bluetooth: Handle Inquiry Cancel error after Inquiry Complete' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.