Re: [Bug] [Deadlock] Kernel thread deadlock in rfcomm socket release when connect interrupted

[Thorsten Leemhuis <regressions@leemhuis.info>]

On 12.09.22 07:23, Paul Menzel wrote:
> [Cc: +regressions]
> 
> #regzbot ^introduced: b7ce436a5d798bc59e71797952566608a4b4626b

thx for this

> #regzbot title: [Bug] [Deadlock] Kernel thread deadlock in rfcomm socket
> release when connect interrupted

BTW & JFYI: regzbot will automatically use the mail's subject as title
by default, so it seems in this case that "#regzbot title:" is superfluous.

> Am 11.09.22 um 17:42 schrieb Peter Sutton:
>> Just following this up. Is there anything I can do to help fix this?
>> Running a custom kernel is a real pain. I've been running with the
>> commit revert and upgrading with Arch Linux kernel releases with no
>> issue.
> 
> (Please do not top post.)
> 
> Have you tested bluetooth-next already? Regardless, the offending commit
> present in Linux since 5.15-rc1 should be reverted.

Well, I'd be a bit more careful here, as reverting commits after so much
time easily can cause other regressions.

>> On Mon, 30 May 2022 at 12:44, Peter Sutton <peter@foxdogstudios.com>
>> wrote:
>>>
>>> Commit b7ce436a5d798bc59e71797952566608a4b4626b is the probable cause.
>>> I compiled a custom Arch Linux kernel package [1] and the bug was
>>> present. Reverting the commit fixed the bug. Below is the reply I was
>>> writing before Matt found the suspect commit and I tested with the
>>> custom kernel.

Anyway, the main reason why I write this: I'm currently traveling and
only took a very quick look into this, but a fix for a deadlock for
RFCOMM sk state change was posted last year already:

https://lore.kernel.org/all/20211004180734.434511-1-desmondcheongzx@gmail.com/

It seems it never went anywhere, unless I'm missing something. Is that
maybe the same problem or somehow related?

>>>> What hardware is that?
>>>
>>> $ dmesg | grep iwlwifi
>>> Me: Intel(R) Dual Band Wireless AC 8260, REV=0x204
>>> Matt: Intel(R) Dual Band Wireless AC 8265, REV=0x230
>>>
>>> We both get:
>>>
>>> $ lsusb | grep Bluetooth
>>> Me & Matt: Bus 001 Device 006: ID 8087:0a2b Intel Corp. Bluetooth
>>> wireless interface
>>>
>>>> As a lot of patches are also applied to the stable series, do you know,
>>>> if this is a regression? Does it work with Linux 5.15(.0) or 5.10?
>>>
>>> Bug is present on current Arch Linux LTS kernel:
>>>
>>> $ uname -a
>>> Linux taffer 5.15.43-1-lts #1 SMP Wed, 25 May 2022 14:08:34 +0000
>>> x86_64 GNU/Linux
>>>
>>> Matt tested on 5.10.115 and the bug is not present. So I guess it's a
>>> regression. Anecdotally, we encountered this behaviour 1 yr ago
>>> (difficult to say exactly), then it went away but came back about 1 or
>>> 2 months ago. All of this is on Arch Linux, I update about once a
>>> week.
>>>
>>> [1] https://wiki.archlinux.org/title/Kernel/Arch_Build_System

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)

P.S.: As the Linux kernel's regression tracker I deal with a lot of
reports and sometimes miss something important when writing mails like
this. If that's the case here, don't hesitate to tell me in a public
reply, it's in everyone's interest to set the public record straight.