From: Pauli Virtanen <pav@iki.fi>
To: linux-bluetooth@vger.kernel.org
Cc: Pauli Virtanen <pav@iki.fi>,
marcel@holtmann.org, luiz.dentz@gmail.com,
linux-kernel@vger.kernel.org
Subject: [PATCH v3 0/4] Bluetooth: fix hci_conn lookup RCU usage + holding refcounts
Date: Fri, 10 Jul 2026 11:23:39 +0300 [thread overview]
Message-ID: <cover.1783671570.git.pav@iki.fi> (raw)
Resending parts of
https://lore.kernel.org/linux-bluetooth/cover.1762100290.git.pav@iki.fi/
plus additional hci_conn_params usage fix.
v3
- Copy params->flags in hci_le_pa_create_sync() to reduce number of
unlocks in branches.
- Don't convert hci_conn_params to RCU here, as it appears to require
sorting out eg. data race vs MGMT_OP_LOAD_CONN_PARAM in field access,
and is more complex change than memory safety fix.
To my understanding it would be performance optimization and it's
unclear that it is significant: these are on Create LE Connection and
Create PA Sync code paths which take hdev->lock in several places eg.
in completion callback in any case.
v2:
- Take hdev->lock instead of RCU in hci_update_scan_sync() to
guard also the hdev->accept_list access.
- In unpair_device/disconnect_sync, take hdev->lock instead of RCU.
This avoids potential access to uninitialized struct device.
In __hci_conn_add() it looks like we should move
hci_conn_hash_add(hdev, conn); after hci_conn_init_sysfs(conn);
so that the pattern
conn = hci_conn_lookup(...)
if (conn)
hci_conn_get(conn)
can be done with RCU without needing hdev->lock.
But better done in separate patch series.
Pauli Virtanen (4):
Bluetooth: hci_sync: extend conn_hash lookup critical sections
Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync
Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds
Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups
net/bluetooth/hci_sync.c | 66 +++++++++++++++++++++++++++++++++++-----
net/bluetooth/mgmt.c | 42 ++++++++++++++++++++++---
2 files changed, 97 insertions(+), 11 deletions(-)
--
2.55.0
next reply other threads:[~2026-07-10 8:24 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 8:23 Pauli Virtanen [this message]
2026-07-10 8:23 ` [PATCH v3 1/4] Bluetooth: hci_sync: extend conn_hash lookup critical sections Pauli Virtanen
2026-07-10 11:18 ` Bluetooth: fix hci_conn lookup RCU usage + holding refcounts bluez.test.bot
2026-07-10 8:23 ` [PATCH v3 2/4] Bluetooth: mgmt: fix locking in unpair_device/disconnect_sync Pauli Virtanen
2026-07-10 8:23 ` [PATCH v3 3/4] Bluetooth: mgmt: hold reference for hci_conn in mgmt_pending_cmds Pauli Virtanen
2026-07-10 8:23 ` [PATCH v3 4/4] Bluetooth: hci_sync: hold hdev->lock for hci_conn_params lookups Pauli Virtanen
2026-07-10 20:10 ` [PATCH v3 0/4] Bluetooth: fix hci_conn lookup RCU usage + holding refcounts patchwork-bot+bluetooth
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=cover.1783671570.git.pav@iki.fi \
--to=pav@iki.fi \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
/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 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.