From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C9B253043BA; Tue, 2 Sep 2025 13:40:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756820406; cv=none; b=gDp9rhJpRNGeDsPnKobvj47LrcWRbkMglTRrw4lw8qcxmguT9oY3alUfeGJOrklpuKt1G7RJApyQAQlMNZAdpB/9Osi1y4jnvXfTFq+5GBuHm7Jd/efEN6khPZbIQU/jmphq/ZNSoCL+Y2miQ4nC22001VtJQr+UMy5GibL37SA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1756820406; c=relaxed/simple; bh=5RSfbRUfS80LyAaJZhK5n75NBpz5iTWVhmcSYe+J3O0=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=rMHmYOtijXZzOvWtQTRL3dpW2/Djxt/YsE+qKLdm/RXyDLdAZzsOyo5kD3c44qEkBXSY635vCtUDt6YihqK0A28waAuQbNHsfzqazyJfXgZQt2XgtCfBDCZu0EeVLR1h1bveOXrjgaUGhMnHEjKJJYwhBQG6ql7Fx2hNEOdxda0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=P17NrsTv; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="P17NrsTv" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 20F17C4CEED; Tue, 2 Sep 2025 13:40:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1756820406; bh=5RSfbRUfS80LyAaJZhK5n75NBpz5iTWVhmcSYe+J3O0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=P17NrsTvMLQlPITWQgB2cRg9bQ0H8yAo9tqjlR9mxgIYlCAo8tDb1TQLfMoCDbVRb W4DWIGOap2YT7r0DiFOgglGpXAB99b9PKG66BIEYUBlQX1ljUloTzGmgUPZjWIFOvY uQn4y5acRPO8RRBETL51vQCgpr9AwdNhGcXAGON0= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Ludovico de Nittis , Luiz Augusto von Dentz , Sasha Levin Subject: [PATCH 6.1 19/50] Bluetooth: hci_event: Mark connection as closed during suspend disconnect Date: Tue, 2 Sep 2025 15:21:10 +0200 Message-ID: <20250902131931.283381665@linuxfoundation.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20250902131930.509077918@linuxfoundation.org> References: <20250902131930.509077918@linuxfoundation.org> User-Agent: quilt/0.68 X-stable: review X-Patchwork-Hint: ignore Precedence: bulk X-Mailing-List: stable@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.1-stable review patch. If anyone has any objections, please let me know. ------------------ From: Ludovico de Nittis [ Upstream commit b7fafbc499b5ee164018eb0eefe9027f5a6aaad2 ] When suspending, the disconnect command for an active Bluetooth connection could be issued, but the corresponding `HCI_EV_DISCONN_COMPLETE` event might not be received before the system completes the suspend process. This can lead to an inconsistent state. On resume, the controller may auto-accept reconnections from the same device (due to suspend event filters), but these new connections are rejected by the kernel which still has connection objects from before suspend. Resulting in errors like: ``` kernel: Bluetooth: hci0: ACL packet for unknown connection handle 1 kernel: Bluetooth: hci0: Ignoring HCI_Connection_Complete for existing connection ``` This is a btmon snippet that shows the issue: ``` < HCI Command: Disconnect (0x01|0x0006) plen 3 Handle: 1 Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd) Reason: Remote User Terminated Connection (0x13) > HCI Event: Command Status (0x0f) plen 4 Disconnect (0x01|0x0006) ncmd 2 Status: Success (0x00) [...] // Host suspends with the event filter set for the device // On resume, the device tries to reconnect with a new handle > HCI Event: Connect Complete (0x03) plen 11 Status: Success (0x00) Handle: 2 Address: 78:20:A5:4A:DF:28 (Nintendo Co.,Ltd) // Kernel ignores this event because there is an existing connection with // handle 1 ``` By explicitly setting the connection state to BT_CLOSED we can ensure a consistent state, even if we don't receive the disconnect complete event in time. Link: https://github.com/bluez/bluez/issues/1226 Fixes: 182ee45da083 ("Bluetooth: hci_sync: Rework hci_suspend_notifier") Signed-off-by: Ludovico de Nittis Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Sasha Levin --- net/bluetooth/hci_event.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index 3ff428df58a46..ff013e1d82a85 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -2782,6 +2782,12 @@ static void hci_cs_disconnect(struct hci_dev *hdev, u8 status) goto done; } + /* During suspend, mark connection as closed immediately + * since we might not receive HCI_EV_DISCONN_COMPLETE + */ + if (hdev->suspended) + conn->state = BT_CLOSED; + mgmt_conn = test_and_clear_bit(HCI_CONN_MGMT_CONNECTED, &conn->flags); if (conn->type == ACL_LINK) { -- 2.50.1