Commit 54659ca026 ("staging: rtl8723bs: remove possible deadlock when
disconnect (v2)") split the locking of pxmitpriv->lock vs sleep_q/lock
into 2 locks in attempt to fix a lockdep reported issue with the locking
order of the sta_hash_lock vs pxmitpriv->lock.
But in the end this turned out to not fully solve the sta_hash_lock issue
so commit a7ac783c33 ("staging: rtl8723bs: remove a second possible
deadlock") was added to fix this in another way.
The original fix was kept as it was still seen as a good thing to have,
but now it turns out that it creates a deadlock in access-point mode:
[Feb20 23:47] ======================================================
[ +0.074085] WARNING: possible circular locking dependency detected
[ +0.074077] 5.16.0-1-amd64 #1 Tainted: G C E
[ +0.064710] ------------------------------------------------------
[ +0.074075] ksoftirqd/3/29 is trying to acquire lock:
[ +0.060542] ffffb8b30062ab00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_xmit_classifier+0x8a/0x140 [r8723bs]
[ +0.114921]
but task is already holding lock:
[ +0.069908] ffffb8b3007ab704 (&psta->sleep_q.lock){+.-.}-{2:2}, at: wakeup_sta_to_xmit+0x3b/0x300 [r8723bs]
[ +0.116976]
which lock already depends on the new lock.
[ +0.098037]
the existing dependency chain (in reverse order) is:
[ +0.089704]
-> #1 (&psta->sleep_q.lock){+.-.}-{2:2}:
[ +0.077232] _raw_spin_lock_bh+0x34/0x40
[ +0.053261] xmitframe_enqueue_for_sleeping_sta+0xc1/0x2f0 [r8723bs]
[ +0.082572] rtw_xmit+0x58b/0x940 [r8723bs]
[ +0.056528] _rtw_xmit_entry+0xba/0x350 [r8723bs]
[ +0.062755] dev_hard_start_xmit+0xf1/0x320
[ +0.056381] sch_direct_xmit+0x9e/0x360
[ +0.052212] __dev_queue_xmit+0xce4/0x1080
[ +0.055334] ip6_finish_output2+0x18f/0x6e0
[ +0.056378] ndisc_send_skb+0x2c8/0x870
[ +0.052209] ndisc_send_ns+0xd3/0x210
[ +0.050130] addrconf_dad_work+0x3df/0x5a0
[ +0.055338] process_one_work+0x274/0x5a0
[ +0.054296] worker_thread+0x52/0x3b0
[ +0.050124] kthread+0x16c/0x1a0
[ +0.044925] ret_from_fork+0x1f/0x30
[ +0.049092]
-> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[ +0.074101] __lock_acquire+0x10f5/0x1d80
[ +0.054298] lock_acquire+0xd7/0x300
[ +0.049088] _raw_spin_lock_bh+0x34/0x40
[ +0.053248] rtw_xmit_classifier+0x8a/0x140 [r8723bs]
[ +0.066949] rtw_xmitframe_enqueue+0xa/0x20 [r8723bs]
[ +0.066946] rtl8723bs_hal_xmitframe_enqueue+0x14/0x50 [r8723bs]
[ +0.078386] wakeup_sta_to_xmit+0xa6/0x300 [r8723bs]
[ +0.065903] rtw_recv_entry+0xe36/0x1160 [r8723bs]
[ +0.063809] rtl8723bs_recv_tasklet+0x349/0x6c0 [r8723bs]
[ +0.071093] tasklet_action_common.constprop.0+0xe5/0x110
[ +0.070966] __do_softirq+0x16f/0x50a
[ +0.050134] __irq_exit_rcu+0xeb/0x140
[ +0.051172] irq_exit_rcu+0xa/0x20
[ +0.047006] common_interrupt+0xb8/0xd0
[ +0.052214] asm_common_interrupt+0x1e/0x40
[ +0.056381] finish_task_switch.isra.0+0x100/0x3a0
[ +0.063670] __schedule+0x3ad/0xd20
[ +0.048047] schedule+0x4e/0xc0
[ +0.043880] smpboot_thread_fn+0xc4/0x220
[ +0.054298] kthread+0x16c/0x1a0
[ +0.044922] ret_from_fork+0x1f/0x30
[ +0.049088]
other info that might help us debug this:
[ +0.095950] Possible unsafe locking scenario:
[ +0.070952] CPU0 CPU1
[ +0.054282] ---- ----
[ +0.054285] lock(&psta->sleep_q.lock);
[ +0.047004] lock(&pxmitpriv->lock);
[ +0.074082] lock(&psta->sleep_q.lock);
[ +0.077209] lock(&pxmitpriv->lock);
[ +0.043873]
*** DEADLOCK ***
[ +0.070950] 1 lock held by ksoftirqd/3/29:
[ +0.049082] #0: ffffb8b3007ab704 (&psta->sleep_q.lock){+.-.}-{2:2}, at: wakeup_sta_to_xmit+0x3b/0x300 [r8723bs]
Analysis shows that in hindsight the splitting of the lock was not
a good idea, so revert this to fix the access-point mode deadlock.
Note this is a straight-forward revert done with git revert, the commented
out "/* spin_lock_bh(&psta_bmc->sleep_q.lock); */" lines were part of the
code before the reverted changes.
Fixes: 54659ca026 ("staging: rtl8723bs: remove possible deadlock when disconnect (v2)")
Cc: stable <stable@vger.kernel.org>
Cc: Fabio Aiuto <fabioaiuto83@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=215542
Link: https://lore.kernel.org/r/20220302101637.26542-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In function rtw_lps_change_dtim_hdl remove the if condition check
to compare the pwrpriv->dtim to dtim . If both are not equal dtim
is getting assign to pwrpriv->dtim. But if both are equal assigning
dtim to pwrpriv->dtim will not make any difference on value. So remove
the unnecessary if condition check.
Signed-off-by: Saurav Girepunje <saurav.girepunje@gmail.com>
Link: https://lore.kernel.org/r/YYgWHt+PpyqOv40R@Sauravs-MacBook-Air.local
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull exit cleanups from Eric Biederman:
"While looking at some issues related to the exit path in the kernel I
found several instances where the code is not using the existing
abstractions properly.
This set of changes introduces force_fatal_sig a way of sending a
signal and not allowing it to be caught, and corrects the misuse of
the existing abstractions that I found.
A lot of the misuse of the existing abstractions are silly things such
as doing something after calling a no return function, rolling BUG by
hand, doing more work than necessary to terminate a kernel thread, or
calling do_exit(SIGKILL) instead of calling force_sig(SIGKILL).
In the review a deficiency in force_fatal_sig and force_sig_seccomp
where ptrace or sigaction could prevent the delivery of the signal was
found. I have added a change that adds SA_IMMUTABLE to change that
makes it impossible to interrupt the delivery of those signals, and
allows backporting to fix force_sig_seccomp
And Arnd found an issue where a function passed to kthread_run had the
wrong prototype, and after my cleanup was failing to build."
* 'exit-cleanups-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (23 commits)
soc: ti: fix wkup_m3_rproc_boot_thread return type
signal: Add SA_IMMUTABLE to ensure forced siganls do not get changed
signal: Replace force_sigsegv(SIGSEGV) with force_fatal_sig(SIGSEGV)
exit/r8188eu: Replace the macro thread_exit with a simple return 0
exit/rtl8712: Replace the macro thread_exit with a simple return 0
exit/rtl8723bs: Replace the macro thread_exit with a simple return 0
signal/x86: In emulate_vsyscall force a signal instead of calling do_exit
signal/sparc32: In setup_rt_frame and setup_fram use force_fatal_sig
signal/sparc32: Exit with a fatal signal when try_to_clear_window_buffer fails
exit/syscall_user_dispatch: Send ordinary signals on failure
signal: Implement force_fatal_sig
exit/kthread: Have kernel threads return instead of calling do_exit
signal/s390: Use force_sigsegv in default_trap_handler
signal/vm86_32: Properly send SIGSEGV when the vm86 state cannot be saved.
signal/vm86_32: Replace open coded BUG_ON with an actual BUG_ON
signal/sparc: In setup_tsb_params convert open coded BUG into BUG
signal/powerpc: On swapcontext failure force SIGSEGV
signal/sh: Use force_sig(SIGKILL) instead of do_group_exit(SIGKILL)
signal/mips: Update (_save|_restore)_fp_context to fail with -EFAULT
signal/sparc32: Remove unreachable do_exit in do_sparc_fault
...
Pull staging driver updates from Greg KH:
"Here is the big set of staging driver updates and cleanups for
5.16-rc1.
Overall we ended up removing a lot of code this time, a bit over
20,000 lines are now gone thanks to a lot of cleanup work by many
developers.
Nothing huge in here functionality wise, just loads of cleanups:
- r8188eu driver major cleanups and removal of unused and dead code
- wlan-ng minor cleanups
- fbtft driver cleanups
- most driver cleanups
- rtl8* drivers cleanups
- rts5208 driver cleanups
- vt6655 driver cleanups
- vc04_services drivers cleanups
- wfx cleanups on the way to almost getting this merged out of
staging (it's close!)
- tiny mips changes needed for the mt7621 drivers, they have been
acked by the respective subsystem maintainers to go through this
tree.
All of these have been in linux-next for a while with no reported
issues"
* tag 'staging-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (622 commits)
staging: r8188eu: hal: remove goto statement and local variable
staging: rtl8723bs: hal remove the assignment to itself
staging: rtl8723bs: fix unmet dependency on CRYPTO for CRYPTO_LIB_ARC4
staging: vchiq_core: get rid of typedef
staging: fieldbus: anybus: reframe comment to avoid warning
staging: r8188eu: fix missing unlock in rtw_resume()
staging: r8188eu: core: remove the goto from rtw_IOL_accquire_xmit_frame
staging: r8188eu: core: remove goto statement
staging: vt6655: Rename `dwAL7230InitTable` array
staging: vt6655: Rename `dwAL2230PowerTable` array
staging: vt6655: Rename `dwAL7230InitTableAMode` array
staging: vt6655: Rename `dwAL7230ChannelTable2` array
staging: vt6655: Rename `dwAL7230ChannelTable1` array
staging: vt6655: Rename `dwAL7230ChannelTable0` array
staging: vt6655: Rename `dwAL2230ChannelTable1` array
staging: vt6655: Rename `dwAL2230ChannelTable0` array
staging: r8712u: fix control-message timeout
staging: rtl8192u: fix control-message timeouts
staging: mt7621-dts: add missing SPDX license to files
staging: vchiq_core: fix quoted strings split across lines
...
When RTL8723BS is selected, and CRYPTO is not selected,
Kbuild gives the following warning:
WARNING: unmet direct dependencies detected for CRYPTO_LIB_ARC4
Depends on [n]: CRYPTO [=n]
Selected by [m]:
- RTL8723BS [=m] && STAGING [=y] && WLAN [=y] && MMC [=y] && CFG80211 [=y] && m && MODULES [=y]
- RTLLIB_CRYPTO_WEP [=m] && STAGING [=y] && RTLLIB [=m]
This is because RTL8723BS selects CRYPTO_LIB_ARC4
without selecting CRYPTO, despite CRYPTO_LIB_ARC4
depending on CRYPTO.
This unmet dependency bug was detected by Kismet,
a static analysis tool for Kconfig. Please advise
if this is not the appropriate solution.
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Julian Braha <julianbraha@gmail.com>
Link: https://lore.kernel.org/r/20211029214244.17341-1-julianbraha@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Every place thread_exit is called is at the end of a function started
with kthread_run. The code in kthread_run has arranged things so a
kernel thread can just return and do_exit will be called.
So just have the threads return instead of calling complete_and_exit.
Link: https://lkml.kernel.org/r/20211020174406.17889-18-ebiederm@xmission.com
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Commit 406f42fa0d ("net-next: When a bond have a massive amount
of VLANs...") introduced a rbtree for faster Ethernet address look
up. To maintain netdev->dev_addr in this tree we need to make all
the writes to it got through appropriate helpers.
Convert staging drivers from memcpy(... ETH_ADDR) to eth_hw_addr_set():
@@
expression dev, np;
@@
- memcpy(dev->dev_addr, np, ETH_ALEN)
+ eth_hw_addr_set(dev, np)
@@
- memcpy(dev->dev_addr, np, 6)
+ eth_hw_addr_set(dev, np)
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Link: https://lore.kernel.org/r/20211019171243.1412240-2-kuba@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lockdep complains about rtw_free_assoc_resources() taking the sta_hash_lock
followed by it calling rtw_free_stainfo() which takes xmitpriv->lock.
While the rtl8723bs_xmit_thread takes the sta_hash_lock while already
holding the xmitpriv->lock:
[ 103.849756] ======================================================
[ 103.849761] WARNING: possible circular locking dependency detected
[ 103.849767] 5.15.0-rc1+ #470 Tainted: G C E
[ 103.849773] ------------------------------------------------------
[ 103.849776] wpa_supplicant/695 is trying to acquire lock:
[ 103.849781] ffffa5d0c0562b00 (&pxmitpriv->lock){+.-.}-{2:2}, at: rtw_free_stainfo+0x8a/0x510 [r8723bs]
[ 103.849840]
but task is already holding lock:
[ 103.849843] ffffa5d0c05636a8 (&pstapriv->sta_hash_lock){+.-.}-{2:2}, at: rtw_free_assoc_resources+0x48/0x110 [r8723bs]
[ 103.849881]
which lock already depends on the new lock.
[ 103.849884]
the existing dependency chain (in reverse order) is:
[ 103.849887]
-> #1 (&pstapriv->sta_hash_lock){+.-.}-{2:2}:
[ 103.849898] _raw_spin_lock_bh+0x34/0x40
[ 103.849913] rtw_get_stainfo+0x93/0x110 [r8723bs]
[ 103.849948] rtw_make_wlanhdr+0x14a/0x270 [r8723bs]
[ 103.849983] rtw_xmitframe_coalesce+0x5c/0x6c0 [r8723bs]
[ 103.850019] rtl8723bs_xmit_thread+0x4ac/0x620 [r8723bs]
[ 103.850050] kthread+0x143/0x160
[ 103.850058] ret_from_fork+0x22/0x30
[ 103.850067]
-> #0 (&pxmitpriv->lock){+.-.}-{2:2}:
[ 103.850077] __lock_acquire+0x1158/0x1de0
[ 103.850084] lock_acquire+0xb5/0x2b0
[ 103.850090] _raw_spin_lock_bh+0x34/0x40
[ 103.850095] rtw_free_stainfo+0x8a/0x510 [r8723bs]
[ 103.850130] rtw_free_assoc_resources+0x53/0x110 [r8723bs]
[ 103.850159] PHY_IQCalibrate_8723B+0x122b/0x36a0 [r8723bs]
[ 103.850189] cfg80211_disconnect+0x173/0x320 [cfg80211]
[ 103.850331] nl80211_disconnect+0x6e/0xb0 [cfg80211]
[ 103.850422] genl_family_rcv_msg_doit+0xcd/0x110
[ 103.850430] genl_rcv_msg+0xce/0x1c0
[ 103.850435] netlink_rcv_skb+0x50/0xf0
[ 103.850441] genl_rcv+0x24/0x40
[ 103.850446] netlink_unicast+0x16d/0x230
[ 103.850452] netlink_sendmsg+0x22b/0x450
[ 103.850457] sock_sendmsg+0x5e/0x60
[ 103.850465] ____sys_sendmsg+0x22f/0x270
[ 103.850472] ___sys_sendmsg+0x81/0xc0
[ 103.850479] __sys_sendmsg+0x49/0x80
[ 103.850485] do_syscall_64+0x3b/0x90
[ 103.850493] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 103.850500]
other info that might help us debug this:
[ 103.850504] Possible unsafe locking scenario:
[ 103.850507] CPU0 CPU1
[ 103.850510] ---- ----
[ 103.850512] lock(&pstapriv->sta_hash_lock);
[ 103.850518] lock(&pxmitpriv->lock);
[ 103.850524] lock(&pstapriv->sta_hash_lock);
[ 103.850530] lock(&pxmitpriv->lock);
[ 103.850535]
*** DEADLOCK ***
Push the taking of sta_hash_lock down into rtw_free_stainfo(),
where the critical section is, this allows taking the lock after
rtw_free_stainfo() has released pxmitpriv->lock.
This requires changing rtw_free_all_stainfo() so that it does its freeing
in 2 steps, first moving all stainfo-s to free to a local list while
holding the sta_hash_lock and then walking that list to call
rtw_free_stainfo() on them without holding the sta_hash_lock.
Pushing the taking of sta_hash_lock down into rtw_free_stainfo(),
also fixes a whole bunch of callers of rtw_free_stainfo() which
were not holding that lock even though they should.
Note that this also fixes the deadlock from the "remove possible
deadlock when disconnect" patch in a different way. But the
changes from that patch offer a nice locking cleanup regardless.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20210920145502.155454-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The wake-on-wlan stub is unused when the device power management
functionality is disabled in the kernel, creating a warning when
building the driver.
drivers/staging/rtl8723bs/os_dep/ioctl_cfg80211.c:50:42: warning: ‘wowlan_stub’ defined but not used [-Wunused-const-variable=]
Add the __maybe_unused annotation to silence this warning.
Signed-off-by: Bryan Brattlof <hello@bryanbrattlof.com>
Link: https://lore.kernel.org/r/20210916231928.2021584-1-hello@bryanbrattlof.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The header file ehternet.h defines only two constants.
#define ETHERNET_HEADER_SIZE 14 /* Ethernet Header Length */
#define LLC_HEADER_SIZE 6 /* LLC Header Length */
Both are only used in the file core/rtw_recv.c and ETHERNET_HEADER_SIZE
just duplicates the in-kernel constant ETH_HLEN. Replace the usage of
ETHERNET_HEADER_SIZE with ETH_HLEN, move the definition of LLC_HEADER_SIZE
into rtw_rev.h (renamed to LLC_HEADER_LENGTH) and remove the now unused
header file ethernet.h.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20210825100842.13217-1-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fix the following post-commit hook checkpatch issue:
CHECK: Logical continuations should be on the previous line
52: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:389:
+ if (padapter->securitypriv.dot11PrivacyAlgrthm == _TKIP_
+ || padapter->securitypriv.dot11PrivacyAlgrthm
== _TKIP_WTMIC_
CHECK: Logical continuations should be on the previous line
53: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:390:
+ || padapter->securitypriv.dot11PrivacyAlgrthm
== _TKIP_WTMIC_
+ || padapter->securitypriv.dot11PrivacyAlgrthm
== _AES_)
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/5d4e7ab18005e69e8cc162619149d6fa93568875.1629727333.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fix the following post commit hook checkpatch issues:
ERROR: code indent should use tabs where possible
2463: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:388:
+ if (padapter->securitypriv.dot11PrivacyAlgrthm == _TKIP_$
ERROR: code indent should use tabs where possible
2464: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:389:
+ || padapter->securitypriv.dot11PrivacyAlgrthm
== _TKIP_WTMIC_$
ERROR: code indent should use tabs where possible
2465: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:390:
+ || padapter->securitypriv.dot11PrivacyAlgrthm == _AES_)$
ERROR: code indent should use tabs where possible
2466: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:391:
+ /* WPS open need to enable multicast */$
ERROR: code indent should use tabs where possible
2467: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:392:
+ /* check_fwstate(&padapter->mlmepriv,
WIFI_UNDER_WPS) == true) */$
ERROR: code indent should use tabs where possible
2468: FILE: drivers/staging/rtl8723bs/os_dep/ioctl_linux.c:393:
+ rtw_hal_set_hwreg(padapter, HW_VAR_OFF_RCR_AM,
null_addr);$
Signed-off-by: Fabio Aiuto <fabioaiuto83@gmail.com>
Link: https://lore.kernel.org/r/aa394052c8d81b4a00356adf5f98fc3c81f8b1d9.1629727333.git.fabioaiuto83@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
