Comment Re:More naunced (Score 1) 36
The fun part of this Bluetooth crash in an embedded ARM system was that a particular test bench doing a software update procedure on the ARM system had a Linux kernel crash in the Bluetooth RFCOMM sub-system but Bluetooth was not used or required for the software update procedure. The failure was only observed on this test bench.
It transpired that a previous tester had put a paired Bluetooth enabled smartphone in the desk draw underneath the test rig. The guy running the software update procedure was unaware of the presence of the other guy's smartphone that was still connected to the ARM system under test. The software update procedure was very CPU intensive and triggered the race condition in the Bluetooth stack.
Once we understood the failure scenario, we could trigger the failure case by adding a sleep in one of the Bluetooth threads so that kernel would always crash.
The morale of the story, do not blindly use reference counters for abrupt protocol disconnect handling. Meaning that immediate clean-up can take place, no need to delay the freeing via a reference counter.