[PW_SID:1154959] [v2] Bluetooth: hci_sock: Reject raw operations while powering down - #677
[PW_SID:1154959] [v2] Bluetooth: hci_sock: Reject raw operations while powering down#677BluezTestBot wants to merge 6 commits into
Conversation
This patch adds workflow files for ci: [sync.yml] - The workflow file for scheduled work - Sync the repo with upstream repo and rebase the workflow branch - Review the patches in the patchwork and creates the PR if needed [ci.yml] - The workflow file for CI tasks - Run CI tests when PR is created Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
This replaces the bzcafe action with bluez/action-ci so we can maintain everything in the github bluez organization Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This attempts to sync every 5 minutes instead of 30. Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
bluez/action-ci uses master as default branch for workflow which is incorrect for kernel Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
The CI action now creates individual GitHub Check Runs per test, which requires 'checks: write' permission on the GITHUB_TOKEN. Also make the pull_request trigger types explicit to include 'reopened', allowing CI to be retriggered by closing and reopening a PR.
When an adapter is powered off with devices still connected, the shutdown sequence issues an HCI reset which returns Command Complete while the controller firmware is still rebooting. A command sent concurrently through a raw socket during this window (e.g. hciconfig queries triggered by the Bluetooth status change) can leave the firmware in a stuck state where it stops answering any HCI command. The subsequent power on then fails with 'Opcode 0x0c03 failed: -110' and the adapter is lost until reboot or re-enumeration. Unlike the ioctl paths (HCIDEVUP/HCIDEVDOWN/HCIDEVRESET) which are already serialized by hci_req_sync_lock against the power off sequence, raw socket command transmission goes directly to the transport through hdev->send() without taking the lock, so it has to be rejected explicitly: - hci_sock_sendmsg(): reject with -ENETDOWN while HCI_POWERING_DOWN is set, extending the existing HCI_UP check - hci_sock_bind(): fail early with -EBUSY while HCI_POWERING_DOWN is set, avoiding HCI_USER_CHANNEL to be toggled (and the controller to be opened as user channel) right after power off Changes in v2: - Drop the HCI_POWERING_DOWN checks in hci_dev_open()/hci_dev_close()/ hci_dev_reset() (hci_core.c): those paths are already serialized by hci_req_sync_lock against the power off sequence, checking the flag outside the lock is redundant (as pointed out in review). Signed-off-by: Chen Zhang <zhangchen01@kylinos.cn>
|
CheckPatch |
|
VerifyFixes |
|
VerifySignedoff |
|
GitLint |
|
SubjectPrefix |
|
BuildKernel |
|
CheckAllWarning |
|
CheckSparse |
|
BuildKernel32 |
|
CheckKernelLLVM |
|
TestRunnerSetup |
|
TestRunner_l2cap-tester |
|
TestRunner_iso-tester |
|
TestRunner_bnep-tester |
|
TestRunner_mgmt-tester |
|
TestRunner_rfcomm-tester |
|
TestRunner_sco-tester |
|
TestRunner_ioctl-tester |
|
TestRunner_mesh-tester |
|
TestRunner_smp-tester |
|
TestRunner_userchan-tester |
|
TestRunner_6lowpan-tester |
|
IncrementalBuild |
8f53a45 to
d690686
Compare
3 participants
From: Chen Zhang zhangchen01@kylinos.cn
When an adapter is powered off with devices still connected, the
shutdown sequence issues an HCI reset which returns Command Complete
while the controller firmware is still rebooting. A command sent
concurrently through a raw socket during this window (e.g. hciconfig
queries triggered by the Bluetooth status change) can leave the
firmware in a stuck state where it stops answering any HCI command.
The subsequent power on then fails with 'Opcode 0x0c03 failed: -110'
and the adapter is lost until reboot or re-enumeration.
Unlike the ioctl paths (HCIDEVUP/HCIDEVDOWN/HCIDEVRESET) which are
already serialized by hci_req_sync_lock against the power off
sequence, raw socket command transmission goes directly to the
transport through hdev->send() without taking the lock, so it has to
be rejected explicitly:
is set, extending the existing HCI_UP check
set, avoiding HCI_USER_CHANNEL to be toggled (and the controller
to be opened as user channel) right after power off
Changes in v2:
hci_dev_reset() (hci_core.c): those paths are already serialized by
hci_req_sync_lock against the power off sequence, checking the flag
outside the lock is redundant (as pointed out in review).
Signed-off-by: Chen Zhang zhangchen01@kylinos.cn
net/bluetooth/hci_sock.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)