Hi All,
On 12.08.2022 14:33, Marek Szyprowski wrote:
> Hi Luiz,
>
> On 10.08.2022 22:04, Luiz Augusto von Dentz wrote:
>> Hi Marek,
>>
>> On Wed, Aug 10, 2022 at 7:18 AM Marek Szyprowski
>> <m.szyprowski@xxxxxxxxxxx> wrote:
>>> Hi Luiz,
>>>
>>> On 09.08.2022 21:24, Luiz Augusto von Dentz wrote:
>>>> On Tue, Aug 9, 2022 at 1:55 AM Marek Szyprowski
>>>> <m.szyprowski@xxxxxxxxxxx> wrote:
>>>>> On 12.07.2022 01:35, Luiz Augusto von Dentz wrote:
>>>>>> From: Luiz Augusto von Dentz<luiz.von.dentz@xxxxxxxxx>
>>>>>>
>>>>>> This adds the initial implementation of CIS connections and
>>>>>> introduces
>>>>>> the ISO packets/links.
>>>>>>
>>>>>> == Central: Set CIG Parameters, create a CIS and Setup Data Path ==
>>>>>>
>>>>>>> tools/isotest -s <address>
>>>>>> < HCI Command: LE Extended Create... (0x08|0x0043) plen 26
>>>>>> ...
>>>>>>> HCI Event: Command Status (0x0f) plen 4
>>>>>> LE Extended Create Connection (0x08|0x0043) ncmd 1
>>>>>> Status: Success (0x00)
>>>>>>> HCI Event: LE Meta Event (0x3e) plen 31
>>>>>> LE Enhanced Connection Complete (0x0a)
>>>>>> ...
>>>>>> < HCI Command: LE Create Connected... (0x08|0x0064) plen 5
>>>>>> ...
>>>>>>> HCI Event: Command Status (0x0f) plen 4
>>>>>> LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1
>>>>>> Status: Success (0x00)
>>>>>>> HCI Event: LE Meta Event (0x3e) plen 29
>>>>>> LE Connected Isochronous Stream Established (0x19)
>>>>>> ...
>>>>>> < HCI Command: LE Setup Isochronou.. (0x08|0x006e) plen 13
>>>>>> ...
>>>>>>> HCI Event: Command Complete (0x0e) plen 6
>>>>>> LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
>>>>>> Status: Success (0x00)
>>>>>> Handle: 257
>>>>>> < HCI Command: LE Setup Isochronou.. (0x08|0x006e) plen 13
>>>>>> ...
>>>>>>> HCI Event: Command Complete (0x0e) plen 6
>>>>>> LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
>>>>>> Status: Success (0x00)
>>>>>> Handle: 257
>>>>>>
>>>>>> == Peripheral: Accept CIS and Setup Data Path ==
>>>>>>
>>>>>>> tools/isotest -d
>>>>>> HCI Event: LE Meta Event (0x3e) plen 7
>>>>>> LE Connected Isochronous Stream Request (0x1a)
>>>>>> ...
>>>>>> < HCI Command: LE Accept Co.. (0x08|0x0066) plen 2
>>>>>> ...
>>>>>>> HCI Event: LE Meta Event (0x3e) plen 29
>>>>>> LE Connected Isochronous Stream Established (0x19)
>>>>>> ...
>>>>>> < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13
>>>>>> ...
>>>>>>> HCI Event: Command Complete (0x0e) plen 6
>>>>>> LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
>>>>>> Status: Success (0x00)
>>>>>> Handle: 257
>>>>>> < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13
>>>>>> ...
>>>>>>> HCI Event: Command Complete (0x0e) plen 6
>>>>>> LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1
>>>>>> Status: Success (0x00)
>>>>>> Handle: 257
>>>>>>
>>>>>> Signed-off-by: Luiz Augusto von Dentz<luiz.von.dentz@xxxxxxxxx>
>>>>> This patch landed recently in linux-next as commit 26afbd826ee3
>>>>> ("Bluetooth: Add initial implementation of CIS connections").
>>>>> Unfortunately it causes a regression on my test systems. On almost
>>>>> all
>>>>> I've observed that calling a simple 'hcitool scan' command in a shell
>>>>> fails in an unexpected way:
>>>>>
>>>>> $ hcitool scan
>>>>> *** stack smashing detected ***: <unknown> terminated
>>>>> Aborted
>>>> Not really sure how it would be related to ISO changes though, have
>>>> you even enabled ISO sockets UUID? Perhaps check if there is something
>>>> on dmesg indicating what is going on since I tried here and that
>>>> doesn't seem to cause any problem:
>>>>
>>>> tools/hcitool scan
>>>> Scanning ...
>>>>
>>>> Perhaps it is a combination of using old userspace tools with new
>>>> kernel, but then again these changes should affect something like
>>>> hcitool.
>>> Indeed my userspace is old, but still, the kernel changes shouldn't
>>> make
>>> it to crash. I didn't change anything in userspace since ages, so I
>>> assume that ISO sockets UUIDs are not enabled. Maybe it is somehow
>>> architecture related or specific? It looks that only ARM 32bit
>>> userspace
>>> apps crashes. I've just checked 64bit userspace on ARM64 (RPi4) and it
>>> works fine with that commit.
>> That would be the first time it happens to me that a change in kernel
>> would crash the userspace in such odd fashion, btw perhaps run with
>> valgrind so it generates a backtrace of where it would be crashing,
>> well if that is reproducible with valgrind.
>
> Well, its not that easy. I've checked and Debian doesn't provide a
> valgrind package for the buster/armel arch, which I use on my test
> systems (for some historical reasons). Building everything from the
> source will take some time, though. I will try to do this after
> getting back from my holidays after 24th Aug.
Unfortunately my holidays trip didn't start, so I had a chance to play a
bit with this issue.
Valgrind doesn't really provide any useful information here:
$ valgrind hcitool scan
==1391== Memcheck, a memory error detector
==1391== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==1391== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==1391== Command: hcitool scan
==1391==
*** stack smashing detected ***: <unknown> terminated
==1391==
==1391== Process terminating with default action of signal 6 (SIGABRT)
==1391== at 0x48EB6AC: raise (raise.c:51)
==1391== by 0x48D6283: abort (abort.c:79)
==1391== by 0x4928E3B: __libc_message (libc_fatal.c:181)
==1391== by 0x49ACFE3: __fortify_fail_abort (fortify_fail.c:33)
==1391== by 0x49ACFA7: __stack_chk_fail (stack_chk_fail.c:29)
==1391== by 0x117DFB: ??? (in /usr/bin/hcitool)
==1391==
==1391== HEAP SUMMARY:
==1391== in use at exit: 132 bytes in 1 blocks
==1391== total heap usage: 1 allocs, 0 frees, 132 bytes allocated
==1391==
==1391== LEAK SUMMARY:
==1391== definitely lost: 0 bytes in 0 blocks
==1391== indirectly lost: 0 bytes in 0 blocks
==1391== possibly lost: 0 bytes in 0 blocks
==1391== still reachable: 132 bytes in 1 blocks
==1391== suppressed: 0 bytes in 0 blocks
==1391== Rerun with --leak-check=full to see details of leaked memory
==1391==
==1391== For counts of detected and suppressed errors, rerun with: -v
==1391== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Aborted
I've also checked the ARM 32bit 'armhf' userspace abi on vanilla
Raspberry Pi OS Lite 32-bit image (from April 4th 2022). The issue is same:
$ hcitool scan
*** stack smashing detected ***: terminated
Aborted
It is enough to boot that image with init=/bin/bash and run 'hcitool
scan' to reproduce the issue...
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
