Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp209545rwb; Mon, 26 Sep 2022 17:26:31 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5idt336AYDeU71BENRiU6mo79uy/j9fZrEVhbW1fsA68Byj2pqCboboksmQJ8oo6VxVSit X-Received: by 2002:a05:6402:3549:b0:454:414e:a7fd with SMTP id f9-20020a056402354900b00454414ea7fdmr26093541edd.69.1664238390815; Mon, 26 Sep 2022 17:26:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664238390; cv=none; d=google.com; s=arc-20160816; b=gyBekfluqEabhr6qT3HyjeemXxbRMsRsNWmtDpj9+7S1O5FBUkDzpM+JGruud/WXNV 6B9TvhLwWQL5D2H1iKRHZDqw26HRkV9YJI8nshtemu7cvTk41LPLs32mOBui5bIW+AjT pETadXzVaIlVH3r94nNgbB53snif1Gg/gd82Yk4V4XbJf1VSOi0aNjLmy9tNtm5aAMY8 L35xfG9bRlkDf8IYuAvs5L0K7ZtmBMa0f3rm3zCZ2ePPAy7YPfBct3NUyJVbHASLBwTm yORKjyr9pWeKhbXAAOUsSRS9neMKJMYdsR7hXcLj5swVhk02w9AaJpQidylRphj0ddoh 44LQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=3IzVwXkFM8Cc1CGnFjsCxlD0U12h7ddTKb7YMIGDc+Y=; b=G/CYbE5ix1fDkoAP1WDdhH5QIT93Ggq/K9Cwdyayrlrh7UFqFJOZApYjjfdQcCTuVY z0Kj6f5TcNe1Uvo03JuW5lit5+MIl9H4VxqTa6CO/y8ZriwkpXe9TZGm+529+yQIdMhn PJFuDKmgNF1Veg32ZFSMQRi011KYixLKV+lWh4AIidUmg+SoRPOTtJbnJ7l9vPjtFxLe zegB2DxtsRC4BLyYVa1/7vmet56lE7GsVvoNsMGxxMlbS+C46ouEzNDu6akDfU745Bsl 3Yc+lxp6vmaDRUQBilEz1ir7z4X/WYPTcekmYXAN+FSNqc9jKsVkzZ8T7G5hvF82+xy9 rLpg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=FHoiLztv; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id sh15-20020a1709076e8f00b00741a186e53csi1679528ejc.50.2022.09.26.17.26.02; Mon, 26 Sep 2022 17:26:30 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=FHoiLztv; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229774AbiI0AVO (ORCPT + 99 others); Mon, 26 Sep 2022 20:21:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229570AbiI0AVN (ORCPT ); Mon, 26 Sep 2022 20:21:13 -0400 Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2090EA4BB3 for ; Mon, 26 Sep 2022 17:21:12 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id bu4so3023943uab.6 for ; Mon, 26 Sep 2022 17:21:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=3IzVwXkFM8Cc1CGnFjsCxlD0U12h7ddTKb7YMIGDc+Y=; b=FHoiLztvWMF2A1g4txzIdEL8uHEeoKzqCsBlgtAgbqcWGbO5eT2RPRqkzg/7gbb20f tOFCAJQaaqyQIlps2L+scQhcMYoE0k4wEopripmBH+HTk/McETsoRzXzxDCD9Qhe5ArK vh36l184zkhDCUcQWVbeNV3PymI6FIw/4yDq0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=3IzVwXkFM8Cc1CGnFjsCxlD0U12h7ddTKb7YMIGDc+Y=; b=bxokL1K9UhDdWRMCGh0JthSeNuvLuiaMNGw8Ib1Ck44qvq9DOrY0JGgsUyAWkJAWgD mcKCxPPnp3VIi7vMXWR0Xl45cAhkq2QX0ihPwL2iuVIX9aIeMCjNNugbYzQ8rI/lqwiE Z/Ie4sPpqo8HRdty4sseiEfiS32BiTNQw3hDAG7gip25BFGv4QMaQ4Jh9IrxEX07eRHQ CqhxBeTzyA4ESjndTWprTxZzIhEiMqJg3kbrwFuUOjKhmBNmEjb2wXOpd5ZcGuQZGYJ+ KrAKk6DPhytUOa1Hk3QtbmvR1bS4tP3QBFdHZlpBPyJXrpURTyyPA7mNJlPEEtjH0el1 YpyA== X-Gm-Message-State: ACrzQf09dyK157dmEvTauyL0oqNcqwy3LmHXau3INqhh63dUJoxJqPZu rq5ij37d0LxqDaHTJvQ8G8uc9NRNiEOcyqMY4PrmZA== X-Received: by 2002:ab0:7697:0:b0:3d0:26e9:fc3 with SMTP id v23-20020ab07697000000b003d026e90fc3mr1057414uaq.85.1664238071188; Mon, 26 Sep 2022 17:21:11 -0700 (PDT) MIME-Version: 1.0 References: <20220926164358.v2.1.Ic8eabc8ed89a07c3d52726dd017539069faac6c4@changeid> In-Reply-To: From: Abhishek Pandit-Subedi Date: Mon, 26 Sep 2022 17:20:59 -0700 Message-ID: Subject: Re: [PATCH v2] Bluetooth: Call shutdown for HCI_USER_CHANNEL To: Luiz Augusto von Dentz Cc: Abhishek Pandit-Subedi , linux-bluetooth@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Johan Hedberg , Marcel Holtmann , Paolo Abeni , linux-kernel@vger.kernel.org, netdev@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-bluetooth@vger.kernel.org On Mon, Sep 26, 2022 at 5:10 PM Luiz Augusto von Dentz wrote: > > Hi Abhishek, > > On Mon, Sep 26, 2022 at 4:44 PM Abhishek Pandit-Subedi > wrote: > > > > From: Abhishek Pandit-Subedi > > > > Some drivers depend on shutdown being called for proper operation. > > Unset HCI_USER_CHANNEL and call the full close routine since shutdown is > > complementary to setup. > > > > Signed-off-by: Abhishek Pandit-Subedi > > --- > > > > Using hci_qca, we can get the controller into a bad state simply by > > trying to bind to userchannel twice (open+bind+close, then open+bind). > > Without running the shutdown routine, the device seems to get into a bad > > state. A similar bug also occurs with btmtksdio (using MT7921). > > > > This change properly runs the shutdown routine, which should be > > complementary to setup. The reason it unsets the HCI_USER_CHANNEL flag > > is that some drivers have complex operations in their shutdown routine > > (including sending hci packets) and we need to support the normal data > > path for them (including cmd_timeout + recovery mechanisms). > > > > Note for v2: I've gotten a chance to test this on more devices > > and figure out why it wasn't working before in v1. I found two problems: > > I had a signal pending (SIGTERM) that was messing things up in the > > socket release function and the HCI_USER_CHANNEL flag was preventing > > hci_sync from operating properly during shutdown on Intel chipsets > > (which use the sync functions to send a reset command + other commands > > sometimes). > > > > This was tested with hci_qca (QCA6174-A-3), btmtksdio (MT7921-SDIO) > > and btusb (with AX200). > > > > > > Changes in v2: > > - Clear HCI_USER_CHANNEL flag at start of close and restore at end. > > - Add comment explaning why we need to clear flag and run shutdown. > > > > net/bluetooth/hci_sync.c | 19 ++++++++++++++++--- > > 1 file changed, 16 insertions(+), 3 deletions(-) > > > > diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c > > index 422f7c6911d9..f9591fcefb8d 100644 > > --- a/net/bluetooth/hci_sync.c > > +++ b/net/bluetooth/hci_sync.c > > @@ -4731,9 +4731,18 @@ int hci_dev_close_sync(struct hci_dev *hdev) > > { > > bool auto_off; > > int err = 0; > > + bool was_userchannel; > > > > bt_dev_dbg(hdev, ""); > > > > + /* Similar to how we first do setup and then set the exclusive access > > + * bit for userspace, we must first unset userchannel and then clean up. > > + * Otherwise, the kernel can't properly use the hci channel to clean up > > + * the controller (some shutdown routines require sending additional > > + * commands to the controller for example). > > + */ > > + was_userchannel = hci_dev_test_and_clear_flag(hdev, HCI_USER_CHANNEL); > > + > > cancel_delayed_work(&hdev->power_off); > > cancel_delayed_work(&hdev->ncmd_timer); > > cancel_delayed_work(&hdev->le_scan_disable); > > @@ -4747,7 +4756,6 @@ int hci_dev_close_sync(struct hci_dev *hdev) > > } > > > > if (!hci_dev_test_flag(hdev, HCI_UNREGISTER) && > > - !hci_dev_test_flag(hdev, HCI_USER_CHANNEL) && > > test_bit(HCI_UP, &hdev->flags)) { > > /* Execute vendor specific shutdown routine */ > > if (hdev->shutdown) > > I guess the idea here is that shutdown can be run without the > HCI_USER_CHANNEL flag since the hdev is closing we don't expect any > traffic from socket/user channel? In that case I'd probably suggest > having this on its own function e.g. hci_dev_shutdown which can have > the logic of resetting the flag and restoring at the end. Also it is > probably a good idea to have some test mimicking this behavior on > userchan-tester so we do not accidentally break it. Yup, that sounds reasonable. I'll look into userchan-tester before sending up a v3. > > > @@ -4756,6 +4764,8 @@ int hci_dev_close_sync(struct hci_dev *hdev) > > > > if (!test_and_clear_bit(HCI_UP, &hdev->flags)) { > > cancel_delayed_work_sync(&hdev->cmd_timer); > > + if (was_userchannel) > > + hci_dev_set_flag(hdev, HCI_USER_CHANNEL); > > return err; > > } > > > > @@ -4795,7 +4805,7 @@ int hci_dev_close_sync(struct hci_dev *hdev) > > auto_off = hci_dev_test_and_clear_flag(hdev, HCI_AUTO_OFF); > > > > if (!auto_off && hdev->dev_type == HCI_PRIMARY && > > - !hci_dev_test_flag(hdev, HCI_USER_CHANNEL) && > > + !was_userchannel && > > hci_dev_test_flag(hdev, HCI_MGMT)) > > __mgmt_power_off(hdev); > > > > @@ -4808,7 +4818,7 @@ int hci_dev_close_sync(struct hci_dev *hdev) > > > > hci_sock_dev_event(hdev, HCI_DEV_DOWN); > > > > - if (!hci_dev_test_flag(hdev, HCI_USER_CHANNEL)) { > > + if (!was_userchannel) > > aosp_do_close(hdev); > > msft_do_close(hdev); > > } > > @@ -4858,6 +4868,9 @@ int hci_dev_close_sync(struct hci_dev *hdev) > > memset(hdev->dev_class, 0, sizeof(hdev->dev_class)); > > bacpy(&hdev->random_addr, BDADDR_ANY); > > > > + if (was_userchannel) > > + hci_dev_set_flag(hdev, HCI_USER_CHANNEL); > > + > > hci_dev_put(hdev); > > return err; > > } > > -- > > 2.37.3.998.g577e59143f-goog > > > > > -- > Luiz Augusto von Dentz