Received: by 2002:ac0:da4c:0:0:0:0:0 with SMTP id a12csp876333imi; Fri, 22 Jul 2022 11:29:12 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sxJN0Ur5MeXJEuTsi5nhUC9GWcCXsYY7uL4MMUBWWR87bPV3M+AdFUsJzUh+gL1qttjXfg X-Received: by 2002:a17:906:730a:b0:72f:6ce7:8acd with SMTP id di10-20020a170906730a00b0072f6ce78acdmr897491ejc.233.1658514551877; Fri, 22 Jul 2022 11:29:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1658514551; cv=none; d=google.com; s=arc-20160816; b=Vx6u7OPIZyXz9EnkjRITNP+BVPMP9xbhumO01+VVKtBp0N+7BL+yb3vU2XzEZa21E8 G9S+p6u7Fjda8sIAJYu5sKknapSKU3jqHmHNW8aXjWp2UJZnV7iku5RiKvsMjQbfjnO2 gYxWDqK0rRVZu68zcPmiJvwIxrlxz9AFa3I3idRij+wB2Vv4OI4qQXp/noQ9TRxWHsKP Fr5AflcRc5WxAH0CR9hcrEl2OyZa4W1iin9KGECVPmnlV2EWKE5KsKF5tsU/LNc0REDO XL/0yrtpS9CuCdxmgGckE21R9XRPseEaUpaBkz/Cki4oUjBURrk6Qw6HDAifDxWPeE2E 52+g== 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=vU+Bqfjo11RM8x8DZvLAsq6rgXc7xY0MqjAnVs4ra+A=; b=csaIdcccNBeo+GjEqRbRk+ZgKq/qehzodzN25OVsc6A37hn0bE+KTxssMxXQKfNjbP r69fQSNfRN7/79aus83e3AHDtpkh0S2JLqC6zn42pKthRg4ArBIL3qn0zMCP9FYJOLta 7Xmv8kwWqF7PywY3mSnyf2aO/knw76emSxIU5SJIenxoIpphM9w+o2ZRoo0RByfsja+W ZRXvb19qXZxl4T8lE/aZ/JEOfM2+5QS8wa92e4j8msxHYA6sRmarGUKaViYocO4tC9UL HpSk7ZjmmNIytpgMplUyxVkddQig3eGXBtj67em7Zq1oW1ZRj6+2kyxVTt0tx/LYwx2J SjvA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=Qch6JxXp; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id i4-20020a50fd04000000b0043b4ed8550bsi5498055eds.344.2022.07.22.11.28.43; Fri, 22 Jul 2022 11:29:11 -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=@google.com header.s=20210112 header.b=Qch6JxXp; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231421AbiGVSZK (ORCPT + 99 others); Fri, 22 Jul 2022 14:25:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236047AbiGVSZJ (ORCPT ); Fri, 22 Jul 2022 14:25:09 -0400 Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 37162235 for ; Fri, 22 Jul 2022 11:25:05 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id w22so2151228uau.7 for ; Fri, 22 Jul 2022 11:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vU+Bqfjo11RM8x8DZvLAsq6rgXc7xY0MqjAnVs4ra+A=; b=Qch6JxXpBVBc9a5l42d7o46lUVYCb8yjmtI75RofIFTIr+5sXJ464PNZLisufGzml9 Ja+WbJvYAaWcOTOH0gYzvemH2k3w7xzxioRq+tjNsZXJWtMPrNdQV5m2QaU7EF9djt2C Nn6LreQ4hV8ymTJcqYBTCKH/aU1QhZIg/uqXjo+YTdtyuo1CAnAVDmgyMrL92PoOeNfp 7hOXLPiQxHWIvJKvyBczUiSFRFyYvM6Ak4kuvF2X+WnpqAMF0W1hQHnbaHooz8sFUu6e 18flrqFLhl4hFXfO+3Jx9FCFqNjGZ588i6vIg0ESRB0PNC4ALULLOHNwcNKx/8DYQHCK JEEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vU+Bqfjo11RM8x8DZvLAsq6rgXc7xY0MqjAnVs4ra+A=; b=fefDlhjOmDXdbax6gOdUSIhF/7wsFVG1UnxduVT22UcQm0yGVtsvzAJGmqW7q3MdU7 opC0TFzO1OepQ1iPcfRkCcsg7G5fpuS2rCCXEQ71GJpPp8VNOI9YNV1zH749EkLGu1xt imSuwjx7P0uSijrVwguQiV3FBCDz4n9dMQmfO2z58X0mhMMXlHcBm3On6NBLnfUfnUUX KiKYsbMINAxE0OYVzf/W6ygXkQciIADlyhJ7vee3LKXDYk2ioiz+8k/MCRmwPor9b6pE EEE8iMwSp7qjSfxh9znWjtRfhUA1DK/AD2gn88WKDrNmtldLVXJzHZT2EViPh6yLD2cu QnIQ== X-Gm-Message-State: AJIora/mU9WFYarvjnXif3MSY1Qir5wivrlZbU6oZkOAXSUtWCZF2R+6 CWjIkzeYSXHha9kT7aPkbhFGkqzn818AjZMHi595qw== X-Received: by 2002:ab0:56c2:0:b0:374:67bd:fe1 with SMTP id c2-20020ab056c2000000b0037467bd0fe1mr516515uab.10.1658514304212; Fri, 22 Jul 2022 11:25:04 -0700 (PDT) MIME-Version: 1.0 References: <20220720233601.3648471-1-jiangzp@google.com> <20220720163548.kernel.v1.1.I4058a198aa4979ee74a219fe6e315fad1184d78d@changeid> In-Reply-To: From: Zhengping Jiang Date: Fri, 22 Jul 2022 11:24:50 -0700 Message-ID: Subject: Re: [kernel PATCH v1 1/1] Bluetooth: Fix get clock info To: Luiz Augusto von Dentz Cc: "linux-bluetooth@vger.kernel.org" , Marcel Holtmann , "Gix, Brian" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL 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 Hi Luiz, Thanks for the rework. This patch looks good. The function to get connection info was causing test regression in some hardware platforms, but not always. We don't currently have a test for getting clock info here. I was submitting the patch because it is using the same pattern as getting conn info. I tested the new patch and it is working well, so we can abandon my patch. Best, Zhengping On Thu, Jul 21, 2022 at 3:41 PM Luiz Augusto von Dentz wrote: > > Hi Zhengping, > > On Thu, Jul 21, 2022 at 3:20 PM Luiz Augusto von Dentz > wrote: > > > > Hi Zhengping, > > > > On Wed, Jul 20, 2022 at 4:36 PM Zhengping Jiang wrote: > > > > > > If connection exists, set the connection data before calling > > > get_clock_info_sync, so it can be verified the connection is still > > > connected, before retrieving clock info. > > > > > > Signed-off-by: Zhengping Jiang > > > --- > > > > > > Changes in v1: > > > - Fix input connection data > > > > > > net/bluetooth/mgmt.c | 13 +++++++------ > > > 1 file changed, 7 insertions(+), 6 deletions(-) > > > > > > diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c > > > index ef8371975c4eb..947d700574c54 100644 > > > --- a/net/bluetooth/mgmt.c > > > +++ b/net/bluetooth/mgmt.c > > > @@ -6971,11 +6971,16 @@ static int get_clock_info(struct sock *sk, struct hci_dev *hdev, void *data, > > > } > > > > > > cmd = mgmt_pending_new(sk, MGMT_OP_GET_CLOCK_INFO, hdev, data, len); > > > - if (!cmd) > > > + if (!cmd) { > > > err = -ENOMEM; > > > - else > > > + } else { > > > + if (conn) { > > > + hci_conn_hold(conn); > > > + cmd->user_data = hci_conn_get(conn); > > > + } > > > err = hci_cmd_sync_queue(hdev, get_clock_info_sync, cmd, > > > get_clock_info_complete); > > > + } > > > > Having seconds though if this is actually the right thing to do, > > hci_cmd_sync_queue will queue the command so get_clock_info_sync > > shouldn't execute immediately if that happens that actually would be > > quite a problem since we are holding the hci_dev_lock so if the > > callback executes and blocks waiting a command that would likely cause > > a deadlock because no command can be completed while hci_dev_lock is > > being held, in fact I don't really like the idea of holding hci_conn > > reference either since we are doing a lookup by address on > > get_clock_info_sync Id probably just remove this code as it seem > > unnecessary. > > > > Btw, there are tests for this command in mgmt-tester so if this is > > actually attempting to fix a problem Id like to have a test to > > reproduce it. > > Looks at the other change you submitted that has a similar code > pattern I did the following change: > > https://gist.github.com/Vudentz/91cd57373d5b0116e2c34b6fb6adaa07 > > And mgmt-tester seems to run just fine with these changes. > > > > > > if (err < 0) { > > > err = mgmt_cmd_complete(sk, hdev->id, MGMT_OP_GET_CLOCK_INFO, > > > @@ -6984,12 +6989,8 @@ static int get_clock_info(struct sock *sk, struct hci_dev *hdev, void *data, > > > if (cmd) > > > mgmt_pending_free(cmd); > > > > > > - } else if (conn) { > > > - hci_conn_hold(conn); > > > - cmd->user_data = hci_conn_get(conn); > > > } > > > > > > - > > > unlock: > > > hci_dev_unlock(hdev); > > > return err; > > > -- > > > 2.37.0.170.g444d1eabd0-goog > > > > > > > > > -- > > Luiz Augusto von Dentz > > > > -- > Luiz Augusto von Dentz