* [PATCH BlueZ 0/1] Fixes busy loop when disabling @ 2024-04-03 20:52 Dimitris 2024-04-03 20:52 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Dimitris 2024-04-04 2:45 ` [PATCH BlueZ 0/1] V2: Fix busy loop when disabling BT Dimitris 0 siblings, 2 replies; 16+ messages in thread From: Dimitris @ 2024-04-03 20:52 UTC (permalink / raw) To: linux-bluetooth; +Cc: Dimitris Reverts a commit which causes bluetoothd to enter a busy loop if BT is disabled (eg. rfkill block bluetooth) when one or more devices are connected. Steps to reproduce are described in these reports: https://github.com/bluez/bluez/issues/785 https://bugzilla.redhat.com/show_bug.cgi?id=2269516 Dimitris (1): Revert "device: Consider service state on device_is_connected" src/device.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) -- 2.44.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" 2024-04-03 20:52 [PATCH BlueZ 0/1] Fixes busy loop when disabling Dimitris @ 2024-04-03 20:52 ` Dimitris 2024-04-03 22:39 ` Fixes busy loop when disabling bluez.test.bot 2024-04-04 6:24 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Paul Menzel 2024-04-04 2:45 ` [PATCH BlueZ 0/1] V2: Fix busy loop when disabling BT Dimitris 1 sibling, 2 replies; 16+ messages in thread From: Dimitris @ 2024-04-03 20:52 UTC (permalink / raw) To: linux-bluetooth; +Cc: Dimitris This reverts commit 44d3f67277f83983e1e9697eda7b9aeb40ca231d. --- src/device.c | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/src/device.c b/src/device.c index 5e74633c6..de5f94c7d 100644 --- a/src/device.c +++ b/src/device.c @@ -3273,11 +3273,7 @@ uint8_t btd_device_get_bdaddr_type(struct btd_device *dev) bool btd_device_is_connected(struct btd_device *dev) { - if (dev->bredr_state.connected || dev->le_state.connected) - return true; - - return find_service_with_state(dev->services, - BTD_SERVICE_STATE_CONNECTED); + return dev->bredr_state.connected || dev->le_state.connected; } static void clear_temporary_timer(struct btd_device *dev) -- 2.44.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* RE: Fixes busy loop when disabling 2024-04-03 20:52 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Dimitris @ 2024-04-03 22:39 ` bluez.test.bot 2024-04-04 6:24 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Paul Menzel 1 sibling, 0 replies; 16+ messages in thread From: bluez.test.bot @ 2024-04-03 22:39 UTC (permalink / raw) To: linux-bluetooth, dimitris.on.linux [-- Attachment #1: Type: text/plain, Size: 1915 bytes --] This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=841223 ---Test result--- Test Summary: CheckPatch FAIL 0.63 seconds GitLint PASS 0.32 seconds BuildEll PASS 24.58 seconds BluezMake PASS 1713.67 seconds MakeCheck PASS 13.57 seconds MakeDistcheck PASS 176.41 seconds CheckValgrind PASS 243.68 seconds CheckSmatch PASS 345.98 seconds bluezmakeextell PASS 117.79 seconds IncrementalBuild PASS 1567.24 seconds ScanBuild PASS 965.21 seconds Details ############################## Test: CheckPatch - FAIL Desc: Run checkpatch.pl script Output: [BlueZ,1/1] Revert "device: Consider service state on device_is_connected" WARNING:UNKNOWN_COMMIT_ID: Unknown commit id '44d3f67277f83983e1e9697eda7b9aeb40ca231d', maybe rebased or not pulled? #94: This reverts commit 44d3f67277f83983e1e9697eda7b9aeb40ca231d. /github/workspace/src/src/13616707.patch total: 0 errors, 1 warnings, 12 lines checked NOTE: For some of the reported defects, checkpatch may be able to mechanically convert to the typical style using --fix or --fix-inplace. /github/workspace/src/src/13616707.patch has style problems, please review. NOTE: Ignored message types: COMMIT_MESSAGE COMPLEX_MACRO CONST_STRUCT FILE_PATH_CHANGES MISSING_SIGN_OFF PREFER_PACKED SPDX_LICENSE_TAG SPLIT_STRING SSCANF_TO_KSTRTO NOTE: If any of the errors are false positives, please report them to the maintainer, see CHECKPATCH in MAINTAINERS. --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" 2024-04-03 20:52 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Dimitris 2024-04-03 22:39 ` Fixes busy loop when disabling bluez.test.bot @ 2024-04-04 6:24 ` Paul Menzel 2024-04-04 6:35 ` Dimitris 1 sibling, 1 reply; 16+ messages in thread From: Paul Menzel @ 2024-04-04 6:24 UTC (permalink / raw) To: Dimitris; +Cc: linux-bluetooth Dear Dimitris, Am 03.04.24 um 22:52 schrieb Dimitris: > This reverts commit 44d3f67277f83983e1e9697eda7b9aeb40ca231d. Please document the reason for the revert. > --- > src/device.c | 6 +----- > 1 file changed, 1 insertion(+), 5 deletions(-) […] Kind regards, Paul ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" 2024-04-04 6:24 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Paul Menzel @ 2024-04-04 6:35 ` Dimitris 0 siblings, 0 replies; 16+ messages in thread From: Dimitris @ 2024-04-04 6:35 UTC (permalink / raw) To: Paul Menzel; +Cc: linux-bluetooth 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH BlueZ 0/1] V2: Fix busy loop when disabling BT 2024-04-03 20:52 [PATCH BlueZ 0/1] Fixes busy loop when disabling Dimitris 2024-04-03 20:52 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Dimitris @ 2024-04-04 2:45 ` Dimitris 2024-04-04 2:45 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Dimitris 1 sibling, 1 reply; 16+ messages in thread From: Dimitris @ 2024-04-04 2:45 UTC (permalink / raw) To: linux-bluetooth; +Cc: Dimitris Second attempt with a more narrow change footprint. Dimitris (1): Refactor btd_device_is_connected src/adapter.c | 2 +- src/device.c | 7 ++++++- src/device.h | 1 + 3 files changed, 8 insertions(+), 2 deletions(-) -- 2.44.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH BlueZ 1/1] Refactor btd_device_is_connected 2024-04-04 2:45 ` [PATCH BlueZ 0/1] V2: Fix busy loop when disabling BT Dimitris @ 2024-04-04 2:45 ` Dimitris 2024-04-04 4:40 ` V2: Fix busy loop when disabling BT bluez.test.bot 2024-04-04 14:59 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Luiz Augusto von Dentz 0 siblings, 2 replies; 16+ messages in thread From: Dimitris @ 2024-04-04 2:45 UTC (permalink / raw) To: linux-bluetooth; +Cc: Dimitris Splitting the service state test out of btd_device_is_connected and using the state-specific test from adapter_remove_connection. This intends to fix a busy loop that happens when BT is disabled from userspace with e.g. "rfkill block bluetooth". --- src/adapter.c | 2 +- src/device.c | 7 ++++++- src/device.h | 1 + 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/adapter.c b/src/adapter.c index 4bcc464de..0b7aab4b5 100644 --- a/src/adapter.c +++ b/src/adapter.c @@ -7486,7 +7486,7 @@ static void adapter_remove_connection(struct btd_adapter *adapter, device_cancel_authentication(device, TRUE); /* If another bearer is still connected */ - if (btd_device_is_connected(device)) + if (btd_device_state_is_connected(device)) return; adapter->connections = g_slist_remove(adapter->connections, device); diff --git a/src/device.c b/src/device.c index 5e74633c6..123b1b796 100644 --- a/src/device.c +++ b/src/device.c @@ -3273,13 +3273,18 @@ uint8_t btd_device_get_bdaddr_type(struct btd_device *dev) bool btd_device_is_connected(struct btd_device *dev) { - if (dev->bredr_state.connected || dev->le_state.connected) + if (btd_device_state_is_connected(dev)) return true; return find_service_with_state(dev->services, BTD_SERVICE_STATE_CONNECTED); } +bool btd_device_state_is_connected(struct btd_device *dev) +{ + return dev->bredr_state.connected || dev->le_state.connected; +} + static void clear_temporary_timer(struct btd_device *dev) { if (dev->temporary_timer) { diff --git a/src/device.h b/src/device.h index d4e70b7ef..e3191f2a4 100644 --- a/src/device.h +++ b/src/device.h @@ -104,6 +104,7 @@ void device_set_rssi(struct btd_device *device, int8_t rssi); void device_set_tx_power(struct btd_device *device, int8_t tx_power); void device_set_flags(struct btd_device *device, uint8_t flags); bool btd_device_is_connected(struct btd_device *dev); +bool btd_device_state_is_connected(struct btd_device *dev); uint8_t btd_device_get_bdaddr_type(struct btd_device *dev); bool device_is_retrying(struct btd_device *device); void device_bonding_complete(struct btd_device *device, uint8_t bdaddr_type, -- 2.44.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* RE: V2: Fix busy loop when disabling BT 2024-04-04 2:45 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Dimitris @ 2024-04-04 4:40 ` bluez.test.bot 2024-04-04 14:59 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Luiz Augusto von Dentz 1 sibling, 0 replies; 16+ messages in thread From: bluez.test.bot @ 2024-04-04 4:40 UTC (permalink / raw) To: linux-bluetooth, dimitris.on.linux [-- Attachment #1: Type: text/plain, Size: 948 bytes --] This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=841263 ---Test result--- Test Summary: CheckPatch PASS 0.45 seconds GitLint PASS 0.31 seconds BuildEll PASS 25.64 seconds BluezMake PASS 1663.82 seconds MakeCheck PASS 13.49 seconds MakeDistcheck PASS 190.09 seconds CheckValgrind PASS 247.23 seconds CheckSmatch PASS 348.43 seconds bluezmakeextell PASS 118.28 seconds IncrementalBuild PASS 1436.09 seconds ScanBuild PASS 991.93 seconds --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH BlueZ 1/1] Refactor btd_device_is_connected 2024-04-04 2:45 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Dimitris 2024-04-04 4:40 ` V2: Fix busy loop when disabling BT bluez.test.bot @ 2024-04-04 14:59 ` Luiz Augusto von Dentz 2024-04-04 15:52 ` Dimitris 2024-04-04 18:30 ` [PATCH BlueZ 0/1] V3: Fix busy loop when disabling BT Dimitris 1 sibling, 2 replies; 16+ messages in thread From: Luiz Augusto von Dentz @ 2024-04-04 14:59 UTC (permalink / raw) To: Dimitris; +Cc: linux-bluetooth Hi Dimitris, On Wed, Apr 3, 2024 at 10:46 PM Dimitris <dimitris.on.linux@gmail.com> wrote: > > Splitting the service state test out of btd_device_is_connected > and using the state-specific test from adapter_remove_connection. > > This intends to fix a busy loop that happens when BT is disabled > from userspace with e.g. "rfkill block bluetooth". > --- > src/adapter.c | 2 +- > src/device.c | 7 ++++++- > src/device.h | 1 + > 3 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/src/adapter.c b/src/adapter.c > index 4bcc464de..0b7aab4b5 100644 > --- a/src/adapter.c > +++ b/src/adapter.c > @@ -7486,7 +7486,7 @@ static void adapter_remove_connection(struct btd_adapter *adapter, > device_cancel_authentication(device, TRUE); > > /* If another bearer is still connected */ > - if (btd_device_is_connected(device)) > + if (btd_device_state_is_connected(device)) Perhaps btd_device_bearer_is_connected would be a better name. > return; > > adapter->connections = g_slist_remove(adapter->connections, device); > diff --git a/src/device.c b/src/device.c > index 5e74633c6..123b1b796 100644 > --- a/src/device.c > +++ b/src/device.c > @@ -3273,13 +3273,18 @@ uint8_t btd_device_get_bdaddr_type(struct btd_device *dev) > > bool btd_device_is_connected(struct btd_device *dev) > { > - if (dev->bredr_state.connected || dev->le_state.connected) > + if (btd_device_state_is_connected(dev)) > return true; > > return find_service_with_state(dev->services, > BTD_SERVICE_STATE_CONNECTED); I guess the problem is that some service is indicating it is still connected though? > } > > +bool btd_device_state_is_connected(struct btd_device *dev) > +{ > + return dev->bredr_state.connected || dev->le_state.connected; > +} > + > static void clear_temporary_timer(struct btd_device *dev) > { > if (dev->temporary_timer) { > diff --git a/src/device.h b/src/device.h > index d4e70b7ef..e3191f2a4 100644 > --- a/src/device.h > +++ b/src/device.h > @@ -104,6 +104,7 @@ void device_set_rssi(struct btd_device *device, int8_t rssi); > void device_set_tx_power(struct btd_device *device, int8_t tx_power); > void device_set_flags(struct btd_device *device, uint8_t flags); > bool btd_device_is_connected(struct btd_device *dev); > +bool btd_device_state_is_connected(struct btd_device *dev); > uint8_t btd_device_get_bdaddr_type(struct btd_device *dev); > bool device_is_retrying(struct btd_device *device); > void device_bonding_complete(struct btd_device *device, uint8_t bdaddr_type, > -- > 2.44.0 > > -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH BlueZ 1/1] Refactor btd_device_is_connected 2024-04-04 14:59 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Luiz Augusto von Dentz @ 2024-04-04 15:52 ` Dimitris 2024-04-04 16:16 ` Luiz Augusto von Dentz 2024-04-04 18:30 ` [PATCH BlueZ 0/1] V3: Fix busy loop when disabling BT Dimitris 1 sibling, 1 reply; 16+ messages in thread From: Dimitris @ 2024-04-04 15:52 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth On 4/4/24 07:59, Luiz Augusto von Dentz wrote: >> diff --git a/src/adapter.c b/src/adapter.c >> index 4bcc464de..0b7aab4b5 100644 >> --- a/src/adapter.c >> +++ b/src/adapter.c >> @@ -7486,7 +7486,7 @@ static void adapter_remove_connection(struct btd_adapter *adapter, >> device_cancel_authentication(device, TRUE); >> >> /* If another bearer is still connected */ >> - if (btd_device_is_connected(device)) >> + if (btd_device_state_is_connected(device)) > > Perhaps btd_device_bearer_is_connected would be a better name. Thanks, I'll rename. > I guess the problem is that some service is indicating it is still > connected though? Newbie question for sure, but: As this is happening in the code path for "disabling bluetooth", shouldn't services already be disconnected here? D. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH BlueZ 1/1] Refactor btd_device_is_connected 2024-04-04 15:52 ` Dimitris @ 2024-04-04 16:16 ` Luiz Augusto von Dentz 2024-04-04 18:25 ` Dimitris 0 siblings, 1 reply; 16+ messages in thread From: Luiz Augusto von Dentz @ 2024-04-04 16:16 UTC (permalink / raw) To: Dimitris; +Cc: linux-bluetooth Hi Dimitris, On Thu, Apr 4, 2024 at 11:52 AM Dimitris <dimitris.on.linux@gmail.com> wrote: > > On 4/4/24 07:59, Luiz Augusto von Dentz wrote: > > >> diff --git a/src/adapter.c b/src/adapter.c > >> index 4bcc464de..0b7aab4b5 100644 > >> --- a/src/adapter.c > >> +++ b/src/adapter.c > >> @@ -7486,7 +7486,7 @@ static void adapter_remove_connection(struct btd_adapter *adapter, > >> device_cancel_authentication(device, TRUE); > >> > >> /* If another bearer is still connected */ > >> - if (btd_device_is_connected(device)) > >> + if (btd_device_state_is_connected(device)) > > > > Perhaps btd_device_bearer_is_connected would be a better name. > > Thanks, I'll rename. > > > I guess the problem is that some service is indicating it is still > > connected though? > > Newbie question for sure, but: As this is happening in the code path for > "disabling bluetooth", shouldn't services already be disconnected here? That is exactly what I would like to know, why is there a service still indicating it is connected if the controller is rfkilled, so while this should break it back to the old behavior we still need to fix the service that is causing the problem so perhaps we need to print its profile/drive name and figure out what is the driver that is causing it. > D. -- Luiz Augusto von Dentz ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH BlueZ 1/1] Refactor btd_device_is_connected 2024-04-04 16:16 ` Luiz Augusto von Dentz @ 2024-04-04 18:25 ` Dimitris 0 siblings, 0 replies; 16+ messages in thread From: Dimitris @ 2024-04-04 18:25 UTC (permalink / raw) To: Luiz Augusto von Dentz; +Cc: linux-bluetooth Hi Luiz, On 4/4/24 09:16, Luiz Augusto von Dentz wrote: >>> I guess the problem is that some service is indicating it is still >>> connected though? >> >> Newbie question for sure, but: As this is happening in the code path for >> "disabling bluetooth", shouldn't services already be disconnected here? > > That is exactly what I would like to know, why is there a service > still indicating it is connected if the controller is rfkilled, so > while this should break it back to the old behavior we still need to > fix the service that is causing the problem so perhaps we need to > print its profile/drive name and figure out what is the driver that is > causing it. > I added a debug kludge: > diff --git a/src/device.c b/src/device.c > index 74dd67a09..c461a6a3a 100644 > --- a/src/device.c > +++ b/src/device.c > @@ -344,7 +344,15 @@ static GSList *find_service_with_state(GSList *list, > struct btd_service *service = l->data; > > if (btd_service_get_state(service) == state) > + { > + char name[256]; > + device_get_name(btd_service_get_device(service), name, 256); > + info("Found service: err: %d, device: %s", > + btd_service_get_error(service), > + name > + ); > return l; > + } > } > > return NULL; > @@ -3282,7 +3290,12 @@ bool btd_device_is_connected(struct btd_device *dev) > > bool btd_device_bearer_is_connected(struct btd_device *dev) > { > - return dev->bredr_state.connected || dev->le_state.connected; > + if(dev->bredr_state.connected || dev->le_state.connected) > + return true; > + else { > + find_service_with_state(dev->services, BTD_SERVICE_STATE_CONNECTED); > + return false; > + }; > } > > static void clear_temporary_timer(struct btd_device *dev) And it seems that every device I have available triggers this: MX Master 3 mouse, Google Pixel Buds Pro, Google Pixel 7. Ran experiments with each one of the devices being connected when running rfkill block: > Apr 04 11:06:31 bluetoothd[331222]: Found service: err: 0, device: MX Master 3 > Apr 04 11:06:46 bluetoothd[331222]: Found service: err: 0, device: MX Master 3 > Apr 04 11:06:58 bluetoothd[331222]: Found service: err: 0, device: MX Master 3 > Apr 04 11:07:28 bluetoothd[331222]: Found service: err: 0, device: coral buds > Apr 04 11:07:29 bluetoothd[331222]: Found service: err: 0, device: coral buds > Apr 04 11:07:29 bluetoothd[331222]: Found service: err: 0, device: coral buds > Apr 04 11:07:29 bluetoothd[331222]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107) > Apr 04 11:08:01 bluetoothd[331222]: Found service: err: 0, device: coral buds > Apr 04 11:08:01 bluetoothd[331222]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107) > Apr 04 11:08:40 bluetoothd[331222]: Found service: err: 0, device: coral buds > Apr 04 11:08:40 bluetoothd[331222]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free Voice gateway: getpeername: Transport endpoint is not connected (107) > Apr 04 11:09:47 bluetoothd[331222]: Found service: err: 0, device: p7 > Apr 04 11:09:47 bluetoothd[331222]: src/profile.c:ext_io_disconnected() Unable to get io data for Hands-Free unit: getpeername: Transport endpoint is not connected (107) The BT adapter is a Mediatek MT7922 WiFi/BT M2 adapter, seems to be using the btmtk driver. In parallel, I've sent a V3 of the "bring back previous behavior" patch with the new function named btd_device_bearer_is_connected. D. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH BlueZ 0/1] V3: Fix busy loop when disabling BT 2024-04-04 14:59 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Luiz Augusto von Dentz 2024-04-04 15:52 ` Dimitris @ 2024-04-04 18:30 ` Dimitris 2024-04-04 18:30 ` [PATCH BlueZ 1/1] refactor bearer connected test Dimitris 2024-04-04 18:50 ` [PATCH BlueZ 0/1] " patchwork-bot+bluetooth 1 sibling, 2 replies; 16+ messages in thread From: Dimitris @ 2024-04-04 18:30 UTC (permalink / raw) To: linux-bluetooth; +Cc: Dimitris Splitting the service state test out of btd_device_is_connected and using only the bearer-specific test from adapter_remove_connection. This intends to fix a busy loop that happens when BT is disabled from userspace with e.g. "rfkill block bluetooth": 1. Connect at least one device. 2. Run rfkill block bluetooth. 3. bluetoothd takes 100% CPU. Bug reports: https://github.com/bluez/bluez/issues/785 https://bugzilla.redhat.com/show_bug.cgi?id=2269516 Dimitris (1): refactor bearer connected test src/adapter.c | 2 +- src/device.c | 7 ++++++- src/device.h | 1 + 3 files changed, 8 insertions(+), 2 deletions(-) -- 2.44.0 ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH BlueZ 1/1] refactor bearer connected test 2024-04-04 18:30 ` [PATCH BlueZ 0/1] V3: Fix busy loop when disabling BT Dimitris @ 2024-04-04 18:30 ` Dimitris 2024-04-04 20:07 ` V3: Fix busy loop when disabling BT bluez.test.bot 2024-04-04 18:50 ` [PATCH BlueZ 0/1] " patchwork-bot+bluetooth 1 sibling, 1 reply; 16+ messages in thread From: Dimitris @ 2024-04-04 18:30 UTC (permalink / raw) To: linux-bluetooth; +Cc: Dimitris --- src/adapter.c | 2 +- src/device.c | 7 ++++++- src/device.h | 1 + 3 files changed, 8 insertions(+), 2 deletions(-) diff --git a/src/adapter.c b/src/adapter.c index 4bcc464de..017e60233 100644 --- a/src/adapter.c +++ b/src/adapter.c @@ -7486,7 +7486,7 @@ static void adapter_remove_connection(struct btd_adapter *adapter, device_cancel_authentication(device, TRUE); /* If another bearer is still connected */ - if (btd_device_is_connected(device)) + if (btd_device_bearer_is_connected(device)) return; adapter->connections = g_slist_remove(adapter->connections, device); diff --git a/src/device.c b/src/device.c index 5e74633c6..74dd67a09 100644 --- a/src/device.c +++ b/src/device.c @@ -3273,13 +3273,18 @@ uint8_t btd_device_get_bdaddr_type(struct btd_device *dev) bool btd_device_is_connected(struct btd_device *dev) { - if (dev->bredr_state.connected || dev->le_state.connected) + if (btd_device_bearer_is_connected(dev)) return true; return find_service_with_state(dev->services, BTD_SERVICE_STATE_CONNECTED); } +bool btd_device_bearer_is_connected(struct btd_device *dev) +{ + return dev->bredr_state.connected || dev->le_state.connected; +} + static void clear_temporary_timer(struct btd_device *dev) { if (dev->temporary_timer) { diff --git a/src/device.h b/src/device.h index d4e70b7ef..5722ca9ca 100644 --- a/src/device.h +++ b/src/device.h @@ -104,6 +104,7 @@ void device_set_rssi(struct btd_device *device, int8_t rssi); void device_set_tx_power(struct btd_device *device, int8_t tx_power); void device_set_flags(struct btd_device *device, uint8_t flags); bool btd_device_is_connected(struct btd_device *dev); +bool btd_device_bearer_is_connected(struct btd_device *dev); uint8_t btd_device_get_bdaddr_type(struct btd_device *dev); bool device_is_retrying(struct btd_device *device); void device_bonding_complete(struct btd_device *device, uint8_t bdaddr_type, -- 2.44.0 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* RE: V3: Fix busy loop when disabling BT 2024-04-04 18:30 ` [PATCH BlueZ 1/1] refactor bearer connected test Dimitris @ 2024-04-04 20:07 ` bluez.test.bot 0 siblings, 0 replies; 16+ messages in thread From: bluez.test.bot @ 2024-04-04 20:07 UTC (permalink / raw) To: linux-bluetooth, dimitris.on.linux [-- Attachment #1: Type: text/plain, Size: 949 bytes --] This is automated email and please do not reply to this email! Dear submitter, Thank you for submitting the patches to the linux bluetooth mailing list. This is a CI test results with your patch series: PW Link:https://patchwork.kernel.org/project/bluetooth/list/?series=841538 ---Test result--- Test Summary: CheckPatch PASS 0.29 seconds GitLint PASS 0.21 seconds BuildEll PASS 25.69 seconds BluezMake PASS 1667.53 seconds MakeCheck PASS 13.17 seconds MakeDistcheck PASS 178.45 seconds CheckValgrind PASS 247.55 seconds CheckSmatch PASS 351.41 seconds bluezmakeextell PASS 119.51 seconds IncrementalBuild PASS 1690.57 seconds ScanBuild PASS 1063.67 seconds --- Regards, Linux Bluetooth ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH BlueZ 0/1] V3: Fix busy loop when disabling BT 2024-04-04 18:30 ` [PATCH BlueZ 0/1] V3: Fix busy loop when disabling BT Dimitris 2024-04-04 18:30 ` [PATCH BlueZ 1/1] refactor bearer connected test Dimitris @ 2024-04-04 18:50 ` patchwork-bot+bluetooth 1 sibling, 0 replies; 16+ messages in thread From: patchwork-bot+bluetooth @ 2024-04-04 18:50 UTC (permalink / raw) To: Dimitris; +Cc: linux-bluetooth Hello: This patch was applied to bluetooth/bluez.git (master) by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>: On Thu, 4 Apr 2024 11:30:49 -0700 you wrote: > Splitting the service state test out of btd_device_is_connected > and using only the bearer-specific test from adapter_remove_connection. > > This intends to fix a busy loop that happens when BT is disabled > from userspace with e.g. "rfkill block bluetooth": > > 1. Connect at least one device. > 2. Run rfkill block bluetooth. > 3. bluetoothd takes 100% CPU. > > [...] Here is the summary with links: - [BlueZ,1/1] refactor bearer connected test https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=036583f9bbec You are awesome, thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/patchwork/pwbot.html ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2024-04-04 20:07 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-04-03 20:52 [PATCH BlueZ 0/1] Fixes busy loop when disabling Dimitris 2024-04-03 20:52 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Dimitris 2024-04-03 22:39 ` Fixes busy loop when disabling bluez.test.bot 2024-04-04 6:24 ` [PATCH BlueZ 1/1] Revert "device: Consider service state on device_is_connected" Paul Menzel 2024-04-04 6:35 ` Dimitris 2024-04-04 2:45 ` [PATCH BlueZ 0/1] V2: Fix busy loop when disabling BT Dimitris 2024-04-04 2:45 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Dimitris 2024-04-04 4:40 ` V2: Fix busy loop when disabling BT bluez.test.bot 2024-04-04 14:59 ` [PATCH BlueZ 1/1] Refactor btd_device_is_connected Luiz Augusto von Dentz 2024-04-04 15:52 ` Dimitris 2024-04-04 16:16 ` Luiz Augusto von Dentz 2024-04-04 18:25 ` Dimitris 2024-04-04 18:30 ` [PATCH BlueZ 0/1] V3: Fix busy loop when disabling BT Dimitris 2024-04-04 18:30 ` [PATCH BlueZ 1/1] refactor bearer connected test Dimitris 2024-04-04 20:07 ` V3: Fix busy loop when disabling BT bluez.test.bot 2024-04-04 18:50 ` [PATCH BlueZ 0/1] " patchwork-bot+bluetooth
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).