From: Dan Carpenter <error27@gmail.com>
To: Haoxiang Li <haoxiang_li2024@163.com>
Cc: marcel@holtmann.org, luiz.dentz@gmail.com,
yangyingliang@huawei.com, mst@redhat.com,
linux-bluetooth@vger.kernel.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH v4] Bluetooth: virtio: Fix virtbt_probe() init and cleanup
Date: Thu, 9 Jul 2026 15:28:17 +0300 [thread overview]
Message-ID: <ak-T4SMxr4rw10jP@stanley.mountain> (raw)
In-Reply-To: <20260709114745.4030794-1-haoxiang_li2024@163.com>
On Thu, Jul 09, 2026 at 07:47:45PM +0800, Haoxiang Li wrote:
> virtbt_probe() allocates vbt before setting up the virtqueues, but some
> failure paths return without freeing it.
>
> The probe path also registers the HCI device before the virtio transport
> is opened. Since hci_register_dev() makes the HCI device visible and queues
> power_on work, move it after virtio_device_ready() and virtbt_open_vdev()
> so the transport is ready before the HCI core can use it.
>
> On failures after DRIVER_OK, reset and close the virtio device before
> deleting the virtqueues and freeing vbt. This also cancels pending rx work
> before vbt is freed.
>
> Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver")
> Fixes: dc65b4b0f90a ("Bluetooth: virtio_bt: fix device removal")
> Cc: stable@vger.kernel.org
> Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
> ---
> Changes in v2:
> - Rework virtbt_probe() error paths into an unwind ladder.
> - Free vbt on probe failures.
> - Reset the virtio device and unregister the HCI device before freeing it
> when virtbt_open_vdev() fails.
> - Close the virtio device before unregistering the HCI device in remove().
>
> Thanks Dan for the suggestions. The blog is very helpful.
>
> Changes in v3:
> - Remove virtio_reset_device() from the virtbt_open_vdev() failure path.
>
> Changes in v4:
> - Move hci_register_dev() after virtio_device_ready() and virtbt_open_vdev().
> - Reset and close the virtio device on probe failures after DRIVER_OK. Thanks, Luiz!
These are Sashiko warnings. To be honest, I would feel really
uncomfortable blindly applying them without testing. If someone
can test, then great. Otherwise, I would probably apply v3. The
stuff that Sashiko complained about was all pre-existing issues
even though for the last one it said it wasn't but it was.
regards,
dan carpenter
next prev parent reply other threads:[~2026-07-09 12:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 11:47 [PATCH v4] Bluetooth: virtio: Fix virtbt_probe() init and cleanup Haoxiang Li
2026-07-09 12:28 ` Dan Carpenter [this message]
2026-07-09 12:36 ` Michael S. Tsirkin
2026-07-09 13:44 ` Dan Carpenter
2026-07-09 14:21 ` Michael S. Tsirkin
2026-07-09 12:35 ` Michael S. Tsirkin
2026-07-09 14:40 ` [v4] " bluez.test.bot
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=ak-T4SMxr4rw10jP@stanley.mountain \
--to=error27@gmail.com \
--cc=haoxiang_li2024@163.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=mst@redhat.com \
--cc=stable@vger.kernel.org \
--cc=yangyingliang@huawei.com \
/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.