Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
MIME-Version: 1.0
References: <20220601151115.1.Ia503b15be0f366563b4e7c9f93cbec5e756bb0ae@changeid>
In-Reply-To: <20220601151115.1.Ia503b15be0f366563b4e7c9f93cbec5e756bb0ae@changeid>
From:   Luiz Augusto von Dentz <luiz.dentz@gmail.com>
Date:   Wed, 1 Jun 2022 14:45:08 -0700
Message-ID: <CABBYNZK8=RCC0bS3KVyn8y93nW_rSR0DDb=Yyp6CgFLaJGz5bA@mail.gmail.com>
Subject: Re: [PATCH] Bluetooth: clear the temporary linkkey in hci_conn_cleanup
To:     Alain Michaud <alainmichaud@google.com>
Cc:     "linux-bluetooth@vger.kernel.org" <linux-bluetooth@vger.kernel.org>,
        ChromeOS Bluetooth Upstreaming 
        <chromeos-bluetooth-upstreaming@chromium.org>,
        Alain Michaud <alainm@chromium.org>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Johan Hedberg <johan.hedberg@gmail.com>,
        Marcel Holtmann <marcel@holtmann.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        "open list:NETWORKING [GENERAL]" <netdev@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi Alain,

On Wed, Jun 1, 2022 at 8:12 AM Alain Michaud <alainmichaud@google.com> wrote:
>
> From: Alain Michaud <alainm@chromium.org>
>
> If a hardware error occurs and the connections are flushed without a
> disconnection_complete event being signaled, the temporary linkkeys are
> not flushed.
>
> This change ensures that any outstanding flushable linkkeys are flushed
> when the connection are flushed from the hash table.
>
> Signed-off-by: Alain Michaud <alainm@chromium.org>
>
> ---
>
>  net/bluetooth/hci_conn.c  | 3 +++
>  net/bluetooth/hci_event.c | 4 +++-
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 352d7d612128..85dc1af90fcb 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -118,6 +118,9 @@ static void hci_conn_cleanup(struct hci_conn *conn)
>         if (test_bit(HCI_CONN_PARAM_REMOVAL_PEND, &conn->flags))
>                 hci_conn_params_del(conn->hdev, &conn->dst, conn->dst_type);
>
> +       if (test_bit(HCI_CONN_FLUSH_KEY, &conn->flags))
> +               hci_remove_link_key(hdev, &conn->dst);
> +
>         hci_chan_list_flush(conn);
>
>         hci_conn_hash_del(hdev, conn);
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 6b83f9b0082c..09f4ff71e747 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -3372,8 +3372,10 @@ static void hci_disconn_complete_evt(struct hci_dev *hdev, void *data,
>                                 reason, mgmt_connected);
>
>         if (conn->type == ACL_LINK) {
> -               if (test_bit(HCI_CONN_FLUSH_KEY, &conn->flags))
> +               if (test_bit(HCI_CONN_FLUSH_KEY, &conn->flags)) {
>                         hci_remove_link_key(hdev, &conn->dst);
> +                       clear_bit(HCI_CONN_FLUSH_KEY, &conn->flags);
> +               }

Could we use test_and_clean_bit instead? In theory there could be
other threads trying to clean up so I guess it would be safer to
reduce the risk of having concurrency problems although hci_dev_lock
would prevent that, better to be safe than sorry.

>                 hci_req_update_scan(hdev);
>         }
> --
> 2.36.1.255.ge46751e96f-goog
>


-- 
Luiz Augusto von Dentz