[PATCH] adapter: Fix Discovering staying true after a rejected stop

[PATCH] adapter: Fix Discovering staying true after a rejected stop

[Kevin Dewald]

The kernel rejects Stop Discovery when no discovery is active by the
time it processes the command, because the discovery ended or another
mgmt client stopped it just before. stop_discovery_complete() then
removes the client but keeps the discovery state, so Discovering stays
true with no client left, and the next StartDiscovery with the same
filter returns without starting a discovery. The client that called
StopDiscovery also gets an InProgress error, and "No discovery started"
if it tries again.

Treat MGMT_STATUS_REJECTED as the discovery being stopped, as
stop_passive_scanning_complete() already does.

Closes: https://github.com/bluez/bluez/issues/2547
Link: https://github.com/bluez/bluez/issues/807
Fixes: c1226f79ec97 ("adapter: Fix not checking status of stop discovery command")
Assisted-by: Claude:claude-opus-5.5
---
Reproduced with a functional test that holds the emulated controller
while a second mgmt client stops the discovery, so the kernel rejects
the Stop Discovery bluetoothd sends for StopDiscovery: on master the
call fails with InProgress and Discovering stays true (3 of 3 runs);
with this patch it succeeds and Discovering goes false (5 of 5). I can
send the test as well if you want it.

 src/adapter.c | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/src/adapter.c b/src/adapter.c
index 1561ea3bf..4d753028a 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2194,6 +2194,14 @@ static void stop_discovery_complete(uint8_t status, uint16_t length,
 
 	DBG("status 0x%02x", status);
 
+	/*
+	 * MGMT_STATUS_REJECTED is returned from kernel when no discovery is
+	 * active, e.g. because it ended or another mgmt client stopped it
+	 * just before this command, so treat it as stopped as well.
+	 */
+	if (status == MGMT_STATUS_REJECTED)
+		status = MGMT_STATUS_SUCCESS;
+
 	client = discovery_complete(adapter, status);
 	if (client)
 		discovery_remove(client);

base-commit: b0bf49270d445da0852851f393cd67a0a1e5f05e
-- 
2.54.0 (Apple Git-157)

Re: [PATCH] adapter: Fix Discovering staying true after a rejected stop

[Kevin Dewald]

Hi Luiz,

Please ignore this one. It went out by mistake, without the BlueZ
prefix, before the series it belongs to. The same patch is 1/2 of:

https://lore.kernel.org/linux-bluetooth/20261027171923.82919-1-kevin@simpleble.org/

Kevin

RE: adapter: Fix Discovering staying true after a rejected stop

[bluez.test.bot]

[-- Attachment #1: Type: text/plain, Size: 859 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/series/1194777/

---Test result---

Test Summary:
CheckPatch                    PASS      0.50 seconds
GitLint                       PASS      0.35 seconds
BuildEll                      PASS      20.88 seconds
BluezMake                     PASS      305.85 seconds
CheckSmatch                   PASS      315.84 seconds
bluezmakeextell               PASS      102.07 seconds
TestFunctional                PASS      1164.26 seconds
IncrementalBuild              PASS      313.31 seconds
ScanBuild                     PASS      1169.73 seconds



https://github.com/bluez/bluez/pull/2723

---
Regards,
Linux Bluetooth

Re: [PATCH] adapter: Fix Discovering staying true after a rejected stop

[patchwork-bot+bluetooth]

Hello:

This patch was applied to bluetooth/bluez.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel.com>:

On Tue, 27 Oct 2026 09:08:52 -0700 you wrote:
> The kernel rejects Stop Discovery when no discovery is active by the
> time it processes the command, because the discovery ended or another
> mgmt client stopped it just before. stop_discovery_complete() then
> removes the client but keeps the discovery state, so Discovering stays
> true with no client left, and the next StartDiscovery with the same
> filter returns without starting a discovery. The client that called
> StopDiscovery also gets an InProgress error, and "No discovery started"
> if it tries again.
> 
> [...]

Here is the summary with links:
  - adapter: Fix Discovering staying true after a rejected stop
    https://git.kernel.org/pub/scm/bluetooth/bluez.git/?id=4f3428e9df2f

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html