Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp1842001pxb; Wed, 9 Feb 2022 05:45:51 -0800 (PST) X-Google-Smtp-Source: ABdhPJzY0EM8JLfNTzz++AIdG31koHQqKtbz9g+3uSDkr6N6t2WUdWGqoKm4EnNkYvCzbwZlrU4Q X-Received: by 2002:a17:90a:8a13:: with SMTP id w19mr3570829pjn.22.1644414351245; Wed, 09 Feb 2022 05:45:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644414351; cv=none; d=google.com; s=arc-20160816; b=qndP6NSCzPhAbTxqLHcVZrF63ZP+Ww2XTIQey8u07UF/DUszG3yKZq/2diCl1pUQoR 5o/3cVSrLVYy4hDkCUosx2GJbn92FF25bbk4ym2uQLiUo9qvcVI7BUSTeHRTbsIDfznL 8AE+9VoGDipdLVpzQnNka1eObwXIe+aJPePPLKhBLHe1+h0w04DrqRPIU0JdLR/ZCuEp CY2XA9gkuVh+gDEwK6xLWhBQQyrHjbRF4+A0frqLHYnVQpYEfKbnxMHC2jn3QN9e/wK+ S0XYBOkjJiSUVEOe8Enbv9DnjOH5RpQ3REjx+dgt38RH2ODXn8h37IY8VSIhR5uWkBPV 7bjA== 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=MLYjiOVPKhgNDOuYW/VTkzO6TMLwooskMLT94QS4iQA=; b=lTfiVK/4Ya0YnLcAjZYoi1ko5TtwaTrGnbw6qrZtFXPjONMimnbLt4+usw02TYQAnm t8HBWzDV4ZZE0fVs50mAvH+TKpk4CjM6xT5PlYXpzR1jQzS4pFadSvFCI+Hl7oeQAYL3 nJj771sJQMjYCOtgXqWFWOhEnybFJnZR1VsyMbGejmPO+mQTAM2l200ViG27W0HZXVh1 kRBKa1cR9CZqWvL/MwWP9IDKg36q1FKz4ZG0u4NDSJvXtwZ+J6CqCBYxUAPS0v5f5ERe zELDpTqwT3UY1Kw5tgEoL0rdfrTLKjhNF2Y0Ipmj3XBg83YMJ5KGqED6GNjkaEdlc3EA cNxw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=E4VMwXJ0; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:18 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 lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id x19si16086898pgf.225.2022.02.09.05.45.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 09 Feb 2022 05:45:51 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=E4VMwXJ0; spf=pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-bluetooth-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 68C2EE09DD96; Wed, 9 Feb 2022 02:26:44 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232439AbiBIGnc (ORCPT + 99 others); Wed, 9 Feb 2022 01:43:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232653AbiBIGnb (ORCPT ); Wed, 9 Feb 2022 01:43:31 -0500 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A023CC0401C7 for ; Tue, 8 Feb 2022 22:43:33 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id l123-20020a1c2581000000b0037b9d960079so2609285wml.0 for ; Tue, 08 Feb 2022 22:43:33 -0800 (PST) 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=MLYjiOVPKhgNDOuYW/VTkzO6TMLwooskMLT94QS4iQA=; b=E4VMwXJ0L2RIg+JWnsFqYky6/ZvCzNWTTPH8FQlSGYUDLrKQIUjsyfUvhSy+Rhooq0 XoqNwJnhYK4+ieT+hXHly/T2Qc+fLrWrwr2FSWgSFAQyO0tyzjZ8b9+Bnz3CL2Ew+aTO 4JgonE6Fap7X7t8X6kw0FI18JbopoQs2odSAF2eQ3s87MINR5htRIeya/dBvfqsrwWBi R1bwQoSF4aCqXi/KM+feyF2Rv3q3pEtazUMLkIVmVwK2whzHwlHtnAmLVv5MbQupVkq6 12fx56d0L6Jx8fkoVTjK0q/tl5VPiZx4AzY0dsYZoQA7gEIdeBpoj15dLSC7hpYXxSwR klxg== 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=MLYjiOVPKhgNDOuYW/VTkzO6TMLwooskMLT94QS4iQA=; b=5YYKBSVXzjyobdO1wtvLTp39X0Qr17jNZ8WDJl8NXXRZwMN9LaW45kYckTkxewM1ii s0/8ZwHfw7F0vF8JKSea8KIbpZ6Xp9/IrCVSaqUVq4x6g+qNbUJwPUjkkZ+i+00KxpSq e4vp/x4P0GgLxtlkbpNPTN9aemuYknVHnnK0XrWtQ0rkn5M4YbjhQ2+Y7Mh4ZCgbMnxT Fg8JadQebhhvSzsq8R/aRLcRNDc9D5FNwgkCSitNA/9W9nyo0uPSfURtcOaz7b7ZrtEJ N7LFqy5mvwn5nYTs4nB9x+qVvqtBH9yupIY3C8WIFpndTPtB++33PFl9nSe5xQAQyi8O ++Hg== X-Gm-Message-State: AOAM533wrHoOdiqxH4+Q6scoAQWGDSLgE5C7mQsvcplC1aFgocpG9bcF pzeJSIwDec/+MTwXtZBCPGBFEJW8VhEjE9c4bMAigPFnj3X5iQ== X-Received: by 2002:a05:600c:1c87:: with SMTP id k7mr1233953wms.60.1644388659305; Tue, 08 Feb 2022 22:37:39 -0800 (PST) MIME-Version: 1.0 References: <20200915110347.Bluez.v3.1.If16fd16b4a629ec4d4093a974256225a95b58044@changeid> In-Reply-To: From: Archie Pusaka Date: Wed, 9 Feb 2022 14:37:28 +0800 Message-ID: Subject: Re: [Bluez PATCH v3] device: don't wait for timeout if RemoveDevice is called To: Luiz Augusto von Dentz Cc: linux-bluetooth , CrosBT Upstreaming , Daniel Winkler Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-9.5 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=no 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, On Wed, 9 Feb 2022 at 10:39, Luiz Augusto von Dentz wrote: > > Hi Archie, > > On Tue, Sep 15, 2020 at 9:51 AM Luiz Augusto von Dentz > wrote: > > > > Hi Archie, > > > > On Mon, Sep 14, 2020 at 8:04 PM Archie Pusaka wrote: > > > > > > From: Archie Pusaka > > > > > > RemoveDevice on adapter interface used to remove a device, even when > > > the device is connected. However, since the introduction of the new > > > 30 seconds timeout when setting a device as temporary, RemoveDevice > > > doesn't immediately remove a connected device, but only disconnects > > > it and waits for the timer to expire before effectively removes it. > > > > > > This patch removes the device as soon as it gets disconnected, > > > provided the disconnection is triggered by a call to RemoveDevice. > > > The regular timeout still applies for other cases. > > > > > > Tested manually by calling RemoveDevice on a connected device, > > > and with ChromeOS autotest setup. > > > > > > Reviewed-by: Daniel Winkler > > > --- > > > > > > Changes in v3: > > > * Rebasing again > > > > > > Changes in v2: > > > * Rebasing to HEAD > > > > > > src/adapter.c | 2 -- > > > src/adapter.h | 2 ++ > > > src/device.c | 11 +++++++++++ > > > 3 files changed, 13 insertions(+), 2 deletions(-) > > > > > > diff --git a/src/adapter.c b/src/adapter.c > > > index df628a7fd..4e27bd74b 100644 > > > --- a/src/adapter.c > > > +++ b/src/adapter.c > > > @@ -80,8 +80,6 @@ > > > #include "adv_monitor.h" > > > #include "eir.h" > > > > > > -#define ADAPTER_INTERFACE "org.bluez.Adapter1" > > > - > > > #define MODE_OFF 0x00 > > > #define MODE_CONNECTABLE 0x01 > > > #define MODE_DISCOVERABLE 0x02 > > > diff --git a/src/adapter.h b/src/adapter.h > > > index c70a7b0da..2f1e4b737 100644 > > > --- a/src/adapter.h > > > +++ b/src/adapter.h > > > @@ -29,6 +29,8 @@ > > > #include > > > #include > > > > > > +#define ADAPTER_INTERFACE "org.bluez.Adapter1" > > > + > > > #define MAX_NAME_LENGTH 248 > > > > > > /* Invalid SSP passkey value used to indicate negative replies */ > > > diff --git a/src/device.c b/src/device.c > > > index 8f73ce4d3..3e7784034 100644 > > > --- a/src/device.c > > > +++ b/src/device.c > > > @@ -3007,6 +3007,7 @@ void device_remove_connection(struct btd_device *device, uint8_t bdaddr_type) > > > { > > > struct bearer_state *state = get_state(device, bdaddr_type); > > > DBusMessage *reply; > > > + bool remove_device = false; > > > > > > if (!state->connected) > > > return; > > > @@ -3036,6 +3037,10 @@ void device_remove_connection(struct btd_device *device, uint8_t bdaddr_type) > > > while (device->disconnects) { > > > DBusMessage *msg = device->disconnects->data; > > > > > > + if (dbus_message_is_method_call(msg, ADAPTER_INTERFACE, > > > + "RemoveDevice")) > > > + remove_device = true; > > > + > > > g_dbus_send_reply(dbus_conn, msg, DBUS_TYPE_INVALID); > > > device->disconnects = g_slist_remove(device->disconnects, msg); > > > dbus_message_unref(msg); > > > @@ -3061,6 +3066,9 @@ void device_remove_connection(struct btd_device *device, uint8_t bdaddr_type) > > > > > > g_dbus_emit_property_changed(dbus_conn, device->path, > > > DEVICE_INTERFACE, "Connected"); > > > + > > > + if (remove_device) > > > + btd_adapter_remove_device(device->adapter, device); > > It looks like there are instances where device_remove_connection is > called that can lead to the following trace: > > ==4030336== Invalid read of size 8 > ==4030336== at 0x40B8A1: device_is_authenticating (device.c:6975) > ==4030336== by 0x3ABA2F: adapter_remove_connection (adapter.c:7166) > ==4030336== by 0x3C2A60: dev_disconnected (adapter.c:8123) > ==4030336== by 0x45C6B4: request_complete (mgmt.c:298) > ==4030336== by 0x45FF74: can_read_data (mgmt.c:390) > ==4030336== by 0x49B28F: watch_callback (io-glib.c:157) > ==4030336== by 0x495312F: g_main_context_dispatch (in > /usr/lib64/libglib-2.0.so.0.7000.2) > ==4030336== by 0x49A8207: ??? (in /usr/lib64/libglib-2.0.so.0.7000.2) > ==4030336== by 0x4952852: g_main_loop_run (in > /usr/lib64/libglib-2.0.so.0.7000.2) > ==4030336== by 0x49C814: mainloop_run (mainloop-glib.c:66) > ==4030336== by 0x49CD0B: mainloop_run_with_signal (mainloop-notify.c:188) > ==4030336== by 0x29B18B: main (main.c:1239) > ==4030336== Address 0x771bfe0 is 448 bytes inside a block of size 656 free'd > ==4030336== at 0x48440E4: free (vg_replace_malloc.c:872) > ==4030336== by 0x4954DAC: g_free (in /usr/lib64/libglib-2.0.so.0.7000.2) > ==4030336== by 0x44D166: remove_interface (object.c:660) > ==4030336== by 0x44DEDA: g_dbus_unregister_interface (object.c:1394) > ==4030336== by 0x3ABA27: adapter_remove_connection (adapter.c:7164) > ==4030336== by 0x3C2A60: dev_disconnected (adapter.c:8123) > ==4030336== by 0x45C6B4: request_complete (mgmt.c:298) > ==4030336== by 0x45FF74: can_read_data (mgmt.c:390) > ==4030336== by 0x49B28F: watch_callback (io-glib.c:157) > ==4030336== by 0x495312F: g_main_context_dispatch (in > /usr/lib64/libglib-2.0.so.0.7000.2) > ==4030336== by 0x49A8207: ??? (in /usr/lib64/libglib-2.0.so.0.7000.2) > ==4030336== by 0x4952852: g_main_loop_run (in > /usr/lib64/libglib-2.0.so.0.7000.2) > > So it appeared to be unsafe to call btd_adapter_remove_device, btw > this happened when Ive attempted to pair 2 emulator instances > (btvirt). Does this happen after calling Adapter1.RemoveDevice? I suppose if that's true then adapter_remove_connection shouldn't have been called since the device should have been removed at this point. Perhaps I misunderstood your message? > > > > } > > > > > > guint device_add_disconnect_watch(struct btd_device *device, > > > @@ -4482,6 +4490,9 @@ void device_remove(struct btd_device *device, gboolean remove_stored) > > > disconnect_all(device); > > > } > > > > > > + if (device->temporary_timer > 0) > > > + g_source_remove(device->temporary_timer); > > > + > > > if (device->store_id > 0) { > > > g_source_remove(device->store_id); > > > device->store_id = 0; > > > -- > > > 2.28.0.618.gf4bc123cb7-goog > > > > > > > Applied, thanks. > > > > -- > > Luiz Augusto von Dentz > > > > -- > Luiz Augusto von Dentz Thanks, Archie