[snipped]
> >How? Most of the time the BT controller can't be brought up again
> >after shutdown(), and we need to stop other activities before that.
> >What other reasoning is expected?
>
> See below.
> >
> >Kai-Heng
> >
> >>
> >> >time it's just "Bluetooth: hci0: HCI reset during shutdown failed" in
> >> >dmesg.
>
> In drivers/bluetooth/btusb.c, there are three cases of
>
> bt_dev_err(hdev, "HCI reset during shutdown failed");
>
> and in btusb_shutdown_intel_new() it has nothing to do with kfree_skb()
> because of IS_ERR(skb).
No, kfree_skb() doesn't gets called in this case. But when that
happens the BT controller won't work anymore.
>
> Feel free to specify why an skb error links to the race you are trying to fix.
The race here is that the btusb_shutdown_intel_new() is trying to
reset the controller while other works like scanning or discovering
are still underway.
So the patch is to ensure that shutdown() callback is invoked after
other works are cancelled.
I think I understand what you are trying to ask, you want to know
where the double kfree_skb() race happens.
I didn't really investigate that because quiesce the other activities
then call shutdown() is the right thing to do and I haven't seen the
kernel splat since.
Kai-Heng
>
> >> >
> >> >Kai-Heng
> >>
> >>
> >> +++ x/net/bluetooth/hci_request.c
> >> @@ -257,8 +257,10 @@ int __hci_req_sync(struct hci_dev *hdev,
> >> break;
> >> }
> >>
> >> - kfree_skb(hdev->req_skb);
> >> - hdev->req_skb = NULL;
> >> + if (!err) {
> >> + kfree_skb(hdev->req_skb);
> >> + hdev->req_skb = NULL;
> >> + }
> >> hdev->req_status = hdev->req_result = 0;
> >>
> >> bt_dev_dbg(hdev, "end: err %d", err);
