From: Aby Sam Ross <abysamross@gmail.com>
To: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Cc: marcel@holtmann.org, linux-bluetooth@vger.kernel.org,
linux-kernel@vger.kernel.org, skhan@linuxfoundation.org,
me@brighamcampbell.com,
syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.com
Subject: Re: [PATCH v1] Bluetooth: hci_release_dev: disable delayed devcoredump work
Date: Sat, 28 Mar 2026 15:49:17 +0530 [thread overview]
Message-ID: <acerJSJ5cx-4CKcp@fedora> (raw)
In-Reply-To: <CABBYNZJ0hJaVRpqPOknitzD_VnKwQ3RkS00EH4GStdbW6E+ADg@mail.gmail.com>
On Tue, Mar 24, 2026 at 04:42:21PM -0400, Luiz Augusto von Dentz wrote:
> Hi Aby,
>
> On Sun, Mar 22, 2026 at 5:09 PM Aby Sam Ross <abysamross@gmail.com> wrote:
> >
> > It is not necessary that the pending delayed hci devcoredump timeout
> > work, hdev->dump.dump_timeout, submitted to the hdev->workqueue by the
> > bluetooth devcoredump state machine,
> > hci_devcd_rx()
> > hci_devcd_handle_pkt_init()
> > will be reset by it or by the timeout func hci_devcd_timeout(), using
> > hci_devcd_reset(), before destroying the workqueue or before the hci
> > device is freed up in hci_release_dev().
> >
> > In this bug the active delayed devcoredump timeout work's timer object
> > is active when the memory associated with the hci device is freed up in
> > hci_release_dev() causing the ODEBUG WARNING.
> >
> > Make sure that the delayed devcoredump timeout work is disabled before
> > the hdev->workqueue is destroyed and before the hdev memory is freed in
> > hci_release_dev().
> >
> > Tested the change with the syzbot reproducer that uses vhci device
> > locally on x86_64 and on syzbot portal as well. Ran kselftest with net
> > target.
> >
> > Fixes: 9695ef876fd1 ("Bluetooth: Add support for hci devcoredump")
> > Reported-by: syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.com
> > Closes: https://syzkaller.appspot.com/bug?extid=b170dbf55520ebf5969a
> > Tested-by: syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.com
> > Signed-off-by: Aby Sam Ross <abysamross@gmail.com>
> > ---
> > net/bluetooth/hci_core.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> > index 01f8ceeb1c0c..1c7ee2a33337 100644
> > --- a/net/bluetooth/hci_core.c
> > +++ b/net/bluetooth/hci_core.c
> > @@ -2747,6 +2747,9 @@ void hci_release_dev(struct hci_dev *hdev)
> > kfree_const(hdev->hw_info);
> > kfree_const(hdev->fw_info);
> >
> > + if (hdev->dump.supported)
> > + disable_delayed_work_sync(&hdev->dump.dump_timeout);
> > +
> > destroy_workqueue(hdev->workqueue);
> > destroy_workqueue(hdev->req_workqueue);
> >
> > --
> > 2.53.0
> >
>
> https://sashiko.dev/#/patchset/20260322210849.68743-1-abysamross%40gmail.com
>
> Both points seems valid, that perhaps the dump shouldn't be attached
> to hdev object since it maybe necessary to unregister the hdev as part
> of devcoredump handling, anyway if it is required then upon unregister
> it shall actually cleanup the dump object as well.
>
> --
> Luiz Augusto von Dentz
Hi Luiz,
From what I see hci_unregister_dev() is called by all bluetooth drivers that use
hci_devcd_init(). Please correct me if I am wrong.
So we can either make hci_devcd_free() non-static and then call it from
hci_unregister_dev()
OR
Do vfree(hdev->dump.head) followed by disabling the delayed devcoredump timeout
work in hci_unregister_dev()
And then destroy the workqueue(dump_rx)?
next prev parent reply other threads:[~2026-03-28 10:19 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-22 21:08 [PATCH v1] Bluetooth: hci_release_dev: disable delayed devcoredump work Aby Sam Ross
2026-03-22 21:43 ` [v1] " bluez.test.bot
2026-03-24 20:42 ` [PATCH v1] " Luiz Augusto von Dentz
2026-03-28 10:19 ` Aby Sam Ross [this message]
2026-04-09 20:01 ` [v1] " 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=acerJSJ5cx-4CKcp@fedora \
--to=abysamross@gmail.com \
--cc=linux-bluetooth@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luiz.dentz@gmail.com \
--cc=marcel@holtmann.org \
--cc=me@brighamcampbell.com \
--cc=skhan@linuxfoundation.org \
--cc=syzbot+b170dbf55520ebf5969a@syzkaller.appspotmail.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.