Re: [PATCH v4] Bluetooth: virtio: Fix virtbt_probe() init and cleanup

Igor Skalkin <[email protected]>
Newsgroups org.kernel.vger.linux-bluetooth,org.kernel.vger.linux-kernel
Message-ID <[email protected]>
I tested this against real hardware (not just QEMU-internal loopback):
a MediaTek USB Bluetooth controller on the host, exposed to a guest
kernel through QEMU's virtio-bt-pci device via HCI_CHANNEL_USER. This
exercises the actual virtio transport and the real HCI core, not a
mock. No other local changes to drivers/bluetooth/virtio_bt.c were
present; this v4 patch was applied alone on top of plain v7.2-rc4.

Test setup:
- Host: Linux with a MediaTek USB BT controller (hci0), bluetooth.service
  stopped/masked and the adapter taken down for the duration of the test
  so QEMU could bind HCI_CHANNEL_USER exclusively.
- Guest: v7.2-rc4 kernel with CONFIG_DEBUG_KMEMLEAK=y, booted via QEMU's
  virtio-bt-pci device pointed at the host adapter.
- This patch (v4) applied alone, on top of plain v7.2-rc4, nothing else
  changed in virtio_bt.c; built as a loadable module for repeated
  bind/unbind testing.
- A module parameter (test-only, not part of this patch) let me force
  a failure at each of the four points virtbt_probe() can now fail at,
  to drive every branch of the new unwind ladder without needing to
  fault-inject the real kernel functions.

Cases run, each followed by an explicit kmemleak scan:

1. Happy path: probe succeeds, hci0 appears under
   /sys/class/bluetooth, remove() runs cleanly.
2. Five back-to-back insmod/rmmod cycles on the happy path, to catch
   leaks or use-after-free that only show up cumulatively.
3. Forced failure at virtio_find_vqs() -> err_free_vbt path.
4. Forced failure at hci_alloc_dev() -> err_del_vqs path.
5. Forced failure at virtbt_open_vdev(), i.e. after
   virtio_device_ready() (post-DRIVER_OK) -> err_close_vdev path.
6. Forced failure at hci_register_dev(), also post-DRIVER_OK and
   post-open -> err_close_vdev path.

Results for all six: no Oops/BUG, no lockdep or RCU-stall warnings,
rmmod always succeeded, hci0 was present under
/sys/class/bluetooth only when probe actually succeeded (cases 1-2),
and kmemleak reported zero unreferenced objects after every case and
in a final aggregate scan at the end of the run.

This covers the ordering fix Sashiko flagged (hci_register_dev()
moved after virtio_device_ready()/virtbt_open_vdev(), so no buffers
are kicked before DRIVER_OK) and the vbt-leak/priv-cleanup fix on the
virtio_find_vqs() failure path, both under a real transport rather
than a stub.

Tested-by: Igor Skalkin <[email protected]>

Happy to share the QEMU/kernel config and the fault-injection harness
if useful for other reviewers.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.