Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp626435pxf; Wed, 24 Mar 2021 11:53:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyt/yYGqcmXnqC9MLf/YtSulCYZxH1D38ZUgkDnCCj+UFGxYT1/WtuDNetK1VTpjkF4OmvH X-Received: by 2002:a05:6402:b21:: with SMTP id bo1mr5039295edb.368.1616611984486; Wed, 24 Mar 2021 11:53:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1616611984; cv=none; d=google.com; s=arc-20160816; b=GR8A2rShhv6fqLul/hhh2iwvTYUMgkLdfCfv/b5BKuMoEhdYUQ/RQzlNMhm6g93X90 2WfZP73P8Pa2Ai8b3gKuPsEHuDWNSCCghPuM6d+W2SQU1buLAPXyCBLTtHHi6GwAg6Os IwqsO4VviE7i7g3uAh+JtvRX1KhPOqPkUgqCCrpQfxJvIUsJhNo8VNWA6SlJalkafsM5 Ln8SVy08DP/0ML3WAYqFwux3K+WEkJeNoGiItX1V7tqUh9/Dsu/jfJDPojP7O//ynKu5 JjYqUgdKwPBJXCRE5LglqbLdWxJoyI1gzOfdFbW3o1wSv08jTfEZJcGdjD48Ui3CC9hd 5X3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=2xQeOsBIewt8ZgUK9t8HEZ9lSbkOzfS8qbc/ekQA/6k=; b=lhFcmvKVaoXODmZDZ2HUC5gMhMn2GZvAL0LpyZ4up+gjH+IRhGVlZFhzLUbQKBL7Rq RLXbnEr84a05Wkdn9kR+FOb5YLAueOXeAyAmCLW7CaqvcoCSGvqYk1ctGIHTxYO7oykY TaLvZ0iFA9wujBRXM7W9cjxCYiCIChBg+KGj3ITWVoFKoYP00SV/dNJbsMSAOtI5nKrE RQXK4mmwV0ATh+h8dwXhWjQYszpwagYeYZ8456qOj923nwZhYPy2bXqvtHOfewxFZFxM 7r8tw+PEMsrzih8XfsT4BYu8cZVVDwZPl+sCKbZL1BJ+7VTJhz0MgqT0NpMVmk6FUbPX wavg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=g1SQTFNn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u24si2264481edy.585.2021.03.24.11.52.40; Wed, 24 Mar 2021 11:53:04 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=g1SQTFNn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 S237571AbhCXStn (ORCPT + 99 others); Wed, 24 Mar 2021 14:49:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237391AbhCXStP (ORCPT ); Wed, 24 Mar 2021 14:49:15 -0400 Received: from mail-vs1-xe2b.google.com (mail-vs1-xe2b.google.com [IPv6:2607:f8b0:4864:20::e2b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8850C061763 for ; Wed, 24 Mar 2021 11:49:14 -0700 (PDT) Received: by mail-vs1-xe2b.google.com with SMTP id e72so6438117vsc.6 for ; Wed, 24 Mar 2021 11:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2xQeOsBIewt8ZgUK9t8HEZ9lSbkOzfS8qbc/ekQA/6k=; b=g1SQTFNnKeuOKt+oNIwnqTljgmASJYgdu5HhzDRCfulgYaksQOv1CpA9JUWHEOfsR9 wKr4dgj9ZG60AbA1Fsm8lRvR59XN7+YXCws1G9lufH3Jl8jbRmB4BYe50pM+CxhjlFAB /xeeke8NCCswPdWLTCsP1b/aGDLHAZ+O+sEfG79G0kj9OhB//aspZvJ/5SnCQOzLAXOZ vc4v9yBFQB7v9p9EnqMbT05rVP4X2aDqbXB/XObhWh5Iutjr9o4MH+gUdM3sCeSVjbdo roRVYwhEW5M8pzT7jlKxjjvfX80Onh1Xx3nDlOV5W6hW6NRPd44XuiTmdwVrbDFPYQyz tcWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2xQeOsBIewt8ZgUK9t8HEZ9lSbkOzfS8qbc/ekQA/6k=; b=ITQQilWwOuYXDq9xVUHjfYkXvoInwNsPiuCwkuSTDx5ayS7a0AUgvdOGGg3DLzwPF6 ciHBebKJzfRsfz7dVE5ajKWrNpMJVQzPsxqojmc6ZueEcQGBQuTGA5EdiyjJALSkjEnC DyeGATDSipn9iVxnJe+w0v74oH9SJ+MQtceTKUCihx53H4OJMGG18/Xk5E0rIzYKDEaO Z7FGLLAZyWdZxKpiUrNkOBb9ahzstrrWxrGaBnQkKJH7eGRlrEImvFuXt+ELwTVVaelT +3wlocDcunkDUWatk4sCAlaVI8J+fKch1G1F0DxM0VbD7L1auEAftno1fGNGVH1WvxuZ xfPA== X-Gm-Message-State: AOAM533FfilyGLdoXbtlIDA7qyPqdj6/I5IA/bbxuYgPRA/dpem7gkO0 hWCJV1l0oN2iZceKVAWw6PldnziUDnErAoz3vKjtSw== X-Received: by 2002:a67:6786:: with SMTP id b128mr3102602vsc.9.1616611753841; Wed, 24 Mar 2021 11:49:13 -0700 (PDT) MIME-Version: 1.0 References: <20210323141653.1.I53e6be1f7df0be198b7e55ae9fc45c7f5760132d@changeid> <8E70C497-BDCE-471F-9ECD-790E2FE3B024@holtmann.org> In-Reply-To: <8E70C497-BDCE-471F-9ECD-790E2FE3B024@holtmann.org> From: Daniel Winkler Date: Wed, 24 Mar 2021 11:49:02 -0700 Message-ID: Subject: Re: [PATCH] Bluetooth: Always call advertising disable before setting params To: Marcel Holtmann Cc: linux-bluetooth , CrosBT Upstreaming , Miao-chen Chou , "David S. Miller" , Jakub Kicinski , Johan Hedberg , Luiz Augusto von Dentz , LKML , "open list:NETWORKING [GENERAL]" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello Marcel, Thank you for the feedback. I have just sent a V2 with a btmon snippet showing the HCI Set Advertising Parameters "Command Disallowed" failure that occurs as a result of this issue. I tried to provide some annotation for context. Please take a look. Thanks! Daniel On Wed, Mar 24, 2021 at 12:06 AM Marcel Holtmann wrot= e: > > Hi Daniel, > > > In __hci_req_enable_advertising, the HCI_LE_ADV hdev flag is temporaril= y > > cleared to allow the random address to be set, which exposes a race > > condition when an advertisement is configured immediately (<10ms) after > > software rotation starts to refresh an advertisement. > > > > In normal operation, the HCI_LE_ADV flag is updated as follows: > > > > 1. adv_timeout_expire is called, HCI_LE_ADV gets cleared in > > __hci_req_enable_advertising, but hci_req configures an enable > > request > > 2. hci_req is run, enable callback re-sets HCI_LE_ADV flag > > > > However, in this race condition, the following occurs: > > > > 1. adv_timeout_expire is called, HCI_LE_ADV gets cleared in > > __hci_req_enable_advertising, but hci_req configures an enable > > request > > 2. add_advertising is called, which also calls > > __hci_req_enable_advertising. Because HCI_LE_ADV was cleared in Step > > 1, no "disable" command is queued. > > 3. hci_req for adv_timeout_expire is run, which enables advertising and > > re-sets HCI_LE_ADV > > 4. hci_req for add_advertising is run, but because no "disable" command > > was queued, we try to set advertising parameters while advertising is > > active, causing a Command Disallowed error, failing the registration. > > > > To resolve the issue, this patch removes the check for the HCI_LE_ADV > > flag, and always queues the "disable" request, since HCI_LE_ADV could b= e > > very temporarily out-of-sync. According to the spec, there is no harm i= n > > calling "disable" when advertising is not active. > > > > Reviewed-by: Miao-chen Chou > > Signed-off-by: Daniel Winkler > > --- > > > > net/bluetooth/hci_request.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/net/bluetooth/hci_request.c b/net/bluetooth/hci_request.c > > index 8ace5d34b01efe..2b4b99f4cedf21 100644 > > --- a/net/bluetooth/hci_request.c > > +++ b/net/bluetooth/hci_request.c > > @@ -1547,8 +1547,10 @@ void __hci_req_enable_advertising(struct hci_req= uest *req) > > if (!is_advertising_allowed(hdev, connectable)) > > return; > > > > - if (hci_dev_test_flag(hdev, HCI_LE_ADV)) > > - __hci_req_disable_advertising(req); > > + /* Request that the controller stop advertising. This can be call= ed > > + * whether or not there is an active advertisement. > > + */ > > + __hci_req_disable_advertising(req); > > can you include a btmon trace that shows that we don=E2=80=99t get a HCI = error. Since if we get one, then the complete request will fail. And that h= as further side effects. > > Regards > > Marcel >