Hi Luiz, On 10 December 2014 at 09:56, Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > Hi Lukasz, > > On Wed, Dec 10, 2014 at 10:53 AM, Lukasz Rymanowski > <lukasz.rymanowski@xxxxxxxxx> wrote: >> Hi Luiz, >> >> On 10 December 2014 at 09:46, Luiz Augusto von Dentz >> <luiz.dentz@xxxxxxxxx> wrote: >>> Hi Lukasz, >>> >>> On Wed, Dec 10, 2014 at 10:38 AM, Lukasz Rymanowski >>> <lukasz.rymanowski@xxxxxxxxx> wrote: >>>> Hi Luiz, >>>> >>>> On 10 December 2014 at 08:23, Luiz Augusto von Dentz >>>> <luiz.dentz@xxxxxxxxx> wrote: >>>>> Hi Lukasz, >>>>> >>>>> On Tue, Dec 9, 2014 at 5:11 PM, Lukasz Rymanowski >>>>> <lukasz.rymanowski@xxxxxxxxx> wrote: >>>>>> When testing HOG against PTS we got failing testes if devices were >>>>>> not bonded before the test. >>>>>> With those patches this issue is not valid anymore. >>>>>> >>>>>> This set address couple of issues: >>>>>> * Some minor fixes found during work on those patches (first 4 patches) >>>>>> >>>>>> * Changed GATT behaviour during dedicated bonding. Now GATT will not start >>>>>> search services until bonding is done. That fixes PTS connection issue >>>>>> (patches 5-8) >>>>>> >>>>>> * Tracking of GATT operations in hog/dis/bas/scpp. After I solved PTS >>>>>> connection issue I could very easily observe many of crashes in BfA when >>>>>> disconnecting HOG during service search session. This is because HOG >>>>>> talks directly to gattrib and clear his attrib instance on HOG disconnect >>>>>> even there are ongoing GATT operations. Patches 9 - 25 solve this issue. >>>>> >>>>> I remember applying a patch from Arman that should have fixed the >>>>> problem above: shared/att: cancel_all before calling disconnect cb. In >>>>> any if that doesn't really solve the problem the client should cancel >>>>> their pending operations before releasing its reference which means no >>>>> callback should be called after that. >>>> >>>> This is problem above bt_att, but It might be worth to consider such >>>> scenario in shared/gatt. >>>> Anyway, In Android attrib is used by HOG and also GATT with all the >>>> applications above. GATT controls registered clients so if one client >>>> unregister we should not see the problem. But if HOG and GATT have >>>> ongoing gatt operations and in this point of time we disconnect HOG, >>>> we should not break ongoing gatt operations for GATT (Android apps). >>>> Note that link LE link can be still up because of some other GATT >>>> application so no disconnect_cb will be called by shared/add. Thats >>>> why attrib client should take care for its operations >>> >>> Yep, but that why I said you should probably cancel any operations, >>> which seems you did, but then why you keep checking for disconnected >>> in the callbacks? There looks like there another bug going on. >> >> Canceling operation might not succeed, in that case callback will be >> called anyway but unfortunately e.g. hog->attrib will be not valid >> anymore and that's we need that additional check. > > Not succeed? bt_att_cancel should always succeed except if we cannot > find the id. Just checked bt_att code and indeed, after calling cancel we should be sure that callback will not be called. However, I've seen something else during testing. That might be other bug then. Will look into it probably tomorrow. \Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
