Suspicious kernel behavior in third_party/kernel/v4.4/net/bluetooth/mgmt.c |
||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.119 Safari/537.36 Steps to reproduce the problem: 1. Setup client A and start LE bluetooth scanning 2. Setup client B and start BREDR bluetooth scanning 3. Note that we probably need two distinct scripts to act as client A and B in this case. What is the expected behavior? Both client A and B start scanning successfully. What went wrong? client B could potentially fail. Take a look at "third_party/kernel/v4.4/net/bluetooth/mgmt.c" start_discovery_internal() is the handler for MGMT_START_DISCOVERY_SIZE. We check DISCOVERY_STOPPED and return error early before we check cp->type. This indicates that if client B starts another type of discovery, it would possibly fail. Did this work before? N/A Chrome version: 64.0.3282.119 Channel: n/a OS Version: Flash Version: I haven't verified yet with actual testing. This is just a theory after scanning the code. If someone can help on testing this, I would greatly appreciate that.
,
Feb 2 2018
Hi, Joseph! Can you help us on the verification of this one? Thanks a lot!
,
Feb 16 2018
Won't both clients A & B be "merged" first by bluetoothd? That way bluetoothd only issue START_DISCOVERY mgmt to kernel once, the second client's request will probably turn into some kind of filter update to kernel. If I understand bluez userspace and kernel coordination correctly.
,
Feb 17 2018
In most of cases, requests from A and B are handled correctly as the request from B would only trigger MGMT_OP_STOP_DISCOVERY when adapter->discovery_enable = true. https://cs.corp.google.com/chromeos_public/src/third_party/bluez/src/adapter.c?q=adapter.c+package:%5Echromeos_public$&dr=CSs&l=1523 However, notice that adapter->discovery_enable is only set to true in the complete callback of start discovery. https://cs.corp.google.com/chromeos_public/src/third_party/bluez/src/adapter.c?q=adapter.c+package:%5Echromeos_public$&dr=CSs&l=1475 Now, what happens if the request from B comes before start_discovery_complete() is called for the request from A?
,
Feb 17 2018
Then I think it should be bluetoothd's bug. bluetoothd is responsible for making sure it doesn't call mgmt's START_DISCOVERY twice.
,
Apr 4 2018
,
Apr 19 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by qiyuh@chromium.org
, Feb 2 2018Components: OS>Systems>Bluetooth
Owner: josephsih@chromium.org