linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Marcel Holtmann <marcel@holtmann.org>,
	Pengutronix Kernel Team <kernel@pengutronix.de>,
	"regressions@lists.linux.dev" <regressions@lists.linux.dev>
Subject: Re: [BUG] BLE device unpairing triggers kernel panic
Date: Mon, 16 May 2022 18:37:58 +0200	[thread overview]
Message-ID: <8d5c4724-d511-39b1-21d7-116c91cada45@pengutronix.de> (raw)
In-Reply-To: <CABBYNZ+zsuggTpaUSPsZKeL=qqvM1=sgMWzdWEqaS_oh6dhY2g@mail.gmail.com>

Hello Luiz,

On 14.05.22 01:52, Luiz Augusto von Dentz wrote:
> On Fri, May 13, 2022 at 1:14 PM Luiz Augusto von Dentz
> <luiz.dentz@gmail.com> wrote:

Thanks for the quick reply.

>> Hi Ahmad,
>>
>> On Fri, May 13, 2022 at 7:10 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>
>>> Hello,
>>>
>>> On Linux v5.18-rc5, I can reliably crash the kernel on the second (un)pairing
>>> with a customer's BLE device. I have bisected the issue and found two commits:
>>>
>>> - Commit 6cd29ec6ae5e ("Bluetooth: hci_sync: Wait for proper events when
>>>   connecting LE") causes previously working pairing to time out, presumably
>>>   because it keeps waiting for the wrong event.
>>
>> Can you describe in more details what is the second pairing, are you
>> pairing 2 devices concurrently? I recall someone for nxp having
>> similar problem, at least the traces look pretty similar, the problem
>> seems to be the expected event don't match the event the controller
>> send, in this case hci_le_enh_conn_complete_evt, so hci_event process
>> it and frees the hci_conn instead of first running the callback.

It's the same device. I set the host to pairable, then have the device
pair with the host. Then I unpair on the device and then redo the
same operation again. First one works. Second one fails triggering
the crash.

> Looks like my memory failed me on this one, the sync callback is run
> last so we shouldn't cleanup the hci_conn at that point, perhaps
> something like the following should fix the crash:
> 
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 0270e597c285..c1634af670b8 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -5632,10 +5632,8 @@ static void le_conn_complete_evt(struct hci_dev
> *hdev, u8 status,
>                 status = HCI_ERROR_INVALID_PARAMETERS;
>         }
> 
> -       if (status) {
> -               hci_conn_failed(conn, status);
> +       if (status)
>                 goto unlock;
> -       }

Yes, this fixes the crash for me. Can you send a patch to that effect?
Feel free to add:

  Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de>

>         if (conn->dst_type == ADDR_LE_DEV_PUBLIC)
>                 addr_type = BDADDR_LE_PUBLIC;
> 
>>> - Commit a56a1138cbd8 ("Bluetooth: hci_sync: Fix not using conn_timeout")
>>>   fixes, despite the title, what event is waited on. First Pairing works now,
>>>   but the second pairing times out and crashes the kernel:
>>>
>>>   [   84.191684] Bluetooth: hci0: Opcode 0x200d failed: -110
>>>   [   84.230478] Bluetooth: hci0: request failed to create LE connection: err -110
>>>   [   84.237690] Unable to handle kernel read from unreadable memory at virtual address 0000000000000ca8
> 
> That said the error -110 mean -ETIMEDOUT

Yes, this issue remains still. I feel better about my revert
knowing that the crash is fixed, but I'd like this regression
here fixed upstream as well. I'll try to collect some more
information and report back.

Cheers,
Ahmad

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  parent reply	other threads:[~2022-05-16 16:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-13 14:10 [BUG] BLE device unpairing triggers kernel panic Ahmad Fatoum
2022-05-13 20:14 ` Luiz Augusto von Dentz
2022-05-13 23:52   ` Luiz Augusto von Dentz
2022-05-13 23:57     ` Luiz Augusto von Dentz
2022-05-16 16:37     ` Ahmad Fatoum [this message]
2022-06-16 10:38       ` Ahmad Fatoum
2022-06-17 20:48         ` Luiz Augusto von Dentz
2022-06-20 10:06           ` Ahmad Fatoum
2022-06-20 20:18             ` Luiz Augusto von Dentz
2022-06-21  8:32               ` Ahmad Fatoum
2022-06-21 18:52                 ` Luiz Augusto von Dentz
2022-06-24 12:53                   ` Ahmad Fatoum
2022-06-24 19:59                     ` Luiz Augusto von Dentz
2022-07-04 12:11                       ` Thorsten Leemhuis
2022-07-07  5:45                         ` Ahmad Fatoum
2022-08-17 10:24                           ` Thorsten Leemhuis
2023-04-04 12:14                             ` Linux regression tracking #update (Thorsten Leemhuis)
2023-04-04 12:17                               ` Ahmad Fatoum

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=8d5c4724-d511-39b1-21d7-116c91cada45@pengutronix.de \
    --to=a.fatoum@pengutronix.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=luiz.dentz@gmail.com \
    --cc=marcel@holtmann.org \
    --cc=regressions@lists.linux.dev \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).