All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Sonny Sasaka <sonnysasaka@chromium.org>
Cc: "linux-bluetooth@vger.kernel.org"
	<linux-bluetooth@vger.kernel.org>,
	Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Subject: Re: [PATCH BlueZ] Check whether device is connected before attaching EATT
Date: Thu, 10 Jun 2021 13:59:36 -0700	[thread overview]
Message-ID: <CABBYNZKG45JktXfxo=SkxrmykpKjTbDu34kz0NpaHhM0CqHTuQ@mail.gmail.com> (raw)
In-Reply-To: <20210610181756.430-1-sonnysasaka@chromium.org>

Hi Sonny,

On Thu, Jun 10, 2021 at 11:20 AM Sonny Sasaka <sonnysasaka@chromium.org> wrote:
>
> Due to a race condition, device_attach_att() may be reached when the
> dev is actually already disconnected but dev->att is not yet cleaned up
> by att_disconnect_cb(). Therefore we should check whether the dev is
> connected before attaching EATT.
>
> The race condition is discovered at rare cases when there is a very
> quick reconnection after disconnection so that device_attach_att() is
> called even before att_disconnect_cb(). This case is more probable to
> happen when the host goes to suspend right before dev_disconnected() is
> invoked and when the host is woken up by a reconnection the reconnection
> is processed earlier than the cleanup in att_disconnect_cb().
>
> Reviewed-by: Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
>
> ---
>  src/device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/device.c b/src/device.c
> index 65838f59f..319a929ee 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -5306,7 +5306,7 @@ bool device_attach_att(struct btd_device *dev, GIOChannel *io)
>                 return false;
>         }
>
> -       if (dev->att) {
> +       if (btd_device_is_connected(dev) && dev->att) {
>                 if (btd_opts.gatt_channels == bt_att_get_channels(dev->att)) {
>                         DBG("EATT channel limit reached");
>                         return false;

Perhaps we should have this check earlier, also there seems to be
something wrong with att_io then, if the device is no longer connected
att_io shall have been unrefed as well.

> --
> 2.31.0
>


-- 
Luiz Augusto von Dentz

      parent reply	other threads:[~2021-06-10 20:59 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-10 18:17 [PATCH BlueZ] Check whether device is connected before attaching EATT Sonny Sasaka
2021-06-10 19:01 ` [BlueZ] " bluez.test.bot
2021-06-10 20:59 ` Luiz Augusto von Dentz [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABBYNZKG45JktXfxo=SkxrmykpKjTbDu34kz0NpaHhM0CqHTuQ@mail.gmail.com' \
    --to=luiz.dentz@gmail.com \
    --cc=abhishekpandit@chromium.org \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=sonnysasaka@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.