Bug 215542 - rtl8723bs (SDIO) - Access point mode causes a kernel panic
Summary: rtl8723bs (SDIO) - Access point mode causes a kernel panic
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Staging (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: drivers_staging@kernel-bugs.osdl.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-01-28 12:48 UTC by José Ángel Pastrana
Modified: 2022-06-20 05:48 UTC (History)
2 users (show)

See Also:
Kernel Version: 5.15.15
Subsystem:
Regression: No
Bisected commit-id:


Attachments
kernel panic (14.59 KB, text/plain)
2022-01-28 12:48 UTC, José Ángel Pastrana
Details
CONFIG_LOCKDEP=y (5.79 KB, text/plain)
2022-02-20 23:06 UTC, José Ángel Pastrana
Details
Patch removing unneeded lock (811 bytes, patch)
2022-02-26 11:31 UTC, Fabio Aiuto
Details | Diff
[PATCH] staging: rtl8723bs: Fix access-point mode deadlock (13.83 KB, patch)
2022-03-01 21:46 UTC, Hans de Goede
Details | Diff
Configuration files (1.13 KB, application/x-compressed-tar)
2022-03-03 10:29 UTC, José Ángel Pastrana
Details

Description José Ángel Pastrana 2022-01-28 12:48:46 UTC
Created attachment 300343 [details]
kernel panic

When I use r8723bs (sdio) as access point and a client begins a intensive download or speed test, a kernel panic ocurrs (see attachment). I can reproduce this bug consistently.

Also, I have bisected the kernel source code and happens for first time with the following commit:

commit 54659ca026e586bbb33a7e60daa6443a3ac6b5df
Author: Fabio Aiuto <fabioaiuto83@gmail.com>
Date:   Mon Sep 20 16:55:00 2021 +0200

    staging: rtl8723bs: remove possible deadlock when disconnect (v2)
Comment 1 Hans de Goede 2022-02-17 13:13:08 UTC
Thank you for your bug-report. Can you please enable the kernel's lockdep feature (CONFIG_LOCKDEP=y) and then reproduce with that enabled and collect logs again ?

That should help with figuring out what is going on here.
Comment 2 José Ángel Pastrana 2022-02-20 23:06:38 UTC
Created attachment 300495 [details]
CONFIG_LOCKDEP=y

I uploaded a new attachment: lockdep.txt. Kernel 5.16.7 recompiled with CONFIG_LOCKDEP=y as you suggested.
Comment 3 Fabio Aiuto 2022-02-26 11:31:57 UTC
Created attachment 300510 [details]
Patch removing unneeded lock
Comment 4 Fabio Aiuto 2022-02-26 11:34:11 UTC
Hello Jose Angel,

thanks for filing this. Could you tell me if the patch fixes the issue?
Thanks a lot.
Comment 5 José Ángel Pastrana 2022-03-01 08:20:09 UTC
Thanks Fabio, I have tested your patch and the kernel panic has gone!

I am going to use it daily, this patch is enough fine for me.

Thanks a lot again, Fabio and Hans.
Comment 6 Fabio Aiuto 2022-03-01 08:36:23 UTC
Hello José,

On Tue, Mar 01, 2022 at 08:20:09AM +0000, bugzilla-daemon@kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=215542
> 
> --- Comment #5 from José Ángel Pastrana (japp.debian@gmail.com) ---
> Thanks Fabio, I have tested your patch and the kernel panic has gone!

good to hear. Please feel free to do some stress tests if you need and
try in STA mode, anyway STA mode should be fine.

> 
> I am going to use it daily, this patch is enough fine for me.
> 
> Thanks a lot again, Fabio and Hans.

Happy to help,

fabio

> 
> -- 
> You may reply to this email to add a comment.
> 
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 7 Hans de Goede 2022-03-01 21:45:53 UTC
Hi José,

Thank you for reporting and testing this. Unfortunately Fabio's fix only fixes one possible deadlock and further analysis has shown that there are other problematic parts also introduced by the commit your bisect found.

Since that commit another, extra fix for the same locking issue has landed:
commit a7ac783c338b ("staging: rtl8723bs: remove a second possible deadlock")

which should fix the original issue even if the bad commit you found is reverted.

So after some further analysis, I believe it is best to just revert the bad commit.

I'm attaching a patch which does the revert (untested so far) if you can give this a test in access-point mode that would be great. I will run some tests in normal client mode myself tomorrow.
Comment 8 Hans de Goede 2022-03-01 21:46:21 UTC
Created attachment 300516 [details]
[PATCH] staging: rtl8723bs: Fix access-point mode deadlock
Comment 9 José Ángel Pastrana 2022-03-03 07:31:44 UTC
Hi Hans and Fabio,

Fabio, I had no problems with sta mode, but also I was testing both sta and access point mode.

Hans, about your latest patch, it worked pretty well and I didn't find any problem.
Comment 10 Fabio Aiuto 2022-03-03 07:38:31 UTC
Hello José,

good to hear, anyway Hans's patches works better, are cleaner and cover
all known cases, they have just been accepted upstream and soon will be
mainline.

Thank you for your testing.

Please could you share the setup you have for AP mode testing?
(configuration files)

Thanks a lot,

Fabio
Comment 11 José Ángel Pastrana 2022-03-03 10:29:05 UTC
Created attachment 300525 [details]
Configuration files

Hello Fabio,

I use hostapd 2.9 and dnsmasq 2.86. Check out the attachment file: setup-ap.tgz
Comment 12 Fabio Aiuto 2022-03-03 10:36:00 UTC
Thanks!

fabio
Comment 13 José Ángel Pastrana 2022-06-20 05:48:56 UTC
The code fix was merged into the Linux kernel 5.18 several months ago [1] and I have been testing it since it was released until today. As this issue was solved finally, I am closing the bug report now.

Thanks to all

[1] https://github.com/torvalds/linux/commit/8f4347081be32e67b0873827e0138ab0fdaaf450

Note You need to log in before you can comment on or make changes to this bug.