Received-SPF: pass (google.com: domain of linux-bluetooth+bounces-3191-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <b7769335-3af4-469a-bf58-a3a51f03c842@gmail.com>
Date: Wed, 3 Apr 2024 23:35:56 -0700
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH BlueZ 1/1] Revert "device: Consider service state on
 device_is_connected"
To: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: linux-bluetooth@vger.kernel.org
References: <20240403205252.71978-1-dimitris.on.linux@gmail.com>
 <20240403205252.71978-2-dimitris.on.linux@gmail.com>
 <06c64895-a99b-4705-8965-d8ea66eef74a@molgen.mpg.de>
Content-Language: en-US
From: Dimitris <dimitris.on.linux@gmail.com>
In-Reply-To: <06c64895-a99b-4705-8965-d8ea66eef74a@molgen.mpg.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi Paul,

> Please document the reason for the revert.

I've since done a narrower change; instead of the revert I'm only 
factoring out the state check that avoids the busy loop at "rfkill block 
bluetooth" time.

Updated cover letter and patch under the "V2" part of the thread:

https://lore.kernel.org/linux-bluetooth/20240404024521.120349-1-dimitris.on.linux@gmail.com/T/#u

Issue steps to reproduce from e.g. 
https://github.com/bluez/bluez/issues/785 :

- Connect at least one device. Tried this with either one of: Logitech 
MX Master 3, Google Pixel Buds Pro.
- Run rfkill block bluetooth
- bluetoothd takes a whole core, GNOME quick settings and status still 
shows bluetooth as "active". I have to kill -9 the process to get the 
block to really complete.
- Turning off the connected device does not break the loop.

Busy loop stack looks like:

> #0  adapter_remove_connection (adapter=0x55a17e6889d0, device=0x55a17e698d30, bdaddr_type=2 '\002') at src/adapter.c:7476
> #1  0x000055a17e55979f in adapter_stop (adapter=0x55a17e6889d0) at src/adapter.c:7527
> #2  settings_changed (settings=<optimized out>, adapter=0x55a17e6889d0) at src/adapter.c:622
> #3  new_settings_callback (index=<optimized out>, length=<optimized out>, param=<optimized out>, user_data=0x55a17e6889d0) at src/adapter.c:705
> #4  0x000055a17e59981e in queue_foreach (user_data=0x7ffe49a7ef20, function=0x55a17e591e60 <notify_handler>, queue=0x55a17e683280) at src/shared/queue.c:207
> #5  queue_foreach (user_data=0x7ffe49a7ef20, function=0x55a17e591e60 <notify_handler>, queue=0x55a17e683280) at src/shared/queue.c:190
> #6  process_notify (param=<optimized out>, length=<optimized out>, index=<optimized out>, event=<optimized out>, mgmt=0x55a17e682f30) at src/shared/mgmt.c:349
> #7  can_read_data (io=<optimized out>, user_data=0x55a17e682f30) at src/shared/mgmt.c:409
> #8  0x000055a17e5bb679 in watch_callback (channel=<optimized out>, cond=<optimized out>, user_data=<optimized out>) at src/shared/io-glib.c:157
> #9  0x00007f876edd4e5c in g_main_context_dispatch_unlocked.lto_priv () from target:/lib64/libglib-2.0.so.0
> #10 0x00007f876ee2ff18 in g_main_context_iterate_unlocked.isra () from target:/lib64/libglib-2.0.so.0
> #11 0x00007f876edd6447 in g_main_loop_run () from target:/lib64/libglib-2.0.so.0
> #12 0x000055a17e4f1d64 in mainloop_run () at src/shared/mainloop-glib.c:66
> #13 mainloop_run_with_signal (func=0x55a17e544740 <signal_callback>, user_data=0x0) at src/shared/mainloop-notify.c:188
> #14 main (argc=<optimized out>, argv=<optimized out>) at src/main.c:1455

First time submitter here, should I resubmit/start a new thread for this 
"V2" approach?

Thanks

D.