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@xxxxxxxxxxxxxxxxx> >> 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@xxxxxxxxx/ 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.
