[PATCH BlueZ 0/2] adapter: Fix Discovering staying true when stopping fails

[Kevin Dewald <kevin@simpleble.org>]

When the Stop Discovery bluetoothd sends for the last discovery client
fails, stop_discovery_complete() removes the client but leaves
Discovering true. The next StartDiscovery with the same filter then
returns success without starting a discovery, as reported in
bluez/bluez#2547 and, before it, #807.

The first patch treats Rejected as stopped: the kernel returns it when
the discovery already ended, or another mgmt client stopped it, just
before the command was processed. The second clears Discovering when
the kernel reports the discovery as stopped with no client left, which
covers the other failures, such as the scan disable timing out. That
needs the kernel to leave the stopping state after a failed stop, which
"Bluetooth: MGMT: Fix discovery stuck after a failed Stop Discovery",
posted separately, does.

I reproduced both with functional tests that hold the emulated
controller by stopping btvirt with SIGSTOP. In the first, a second mgmt
client stops the discovery before bluetoothd does, so the kernel
rejects bluetoothd's stop; in the second, the controller stays held
until the kernel times out the scan disable. Without its patch, the
first fails with InProgress from StopDiscovery and the second with
Discovering staying true (3 of 3 runs each); with them both pass (5 of
5 each, the second on bluetooth-next with the kernel fix). I can send
the tests as well if you want them.

make check passes, and so do the functional tests that use discovery.

Kevin Dewald (2):
  adapter: Fix Discovering staying true after a rejected stop
  adapter: Fix Discovering staying true after a failed stop

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


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