linux.git/drivers/staging/rtl8723bs, branch v5.17

staging: rtl8723bs: Improve the comment explaining the locking rules

2022-03-02T15:38:24+00:00

rtw_mlme.h has a comment which briefly describes the locking rules for
the rtl8723bs driver, improve this to also mention the locking order
of xmit_priv.lock vs the lock(s) embedded in the various queues.

Cc: Fabio Aiuto 
Signed-off-by: Hans de Goede 
Link: https://lore.kernel.org/r/20220302101637.26542-2-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman

staging: rtl8723bs: Fix access-point mode deadlock

2022-03-02T15:38:19+00:00

Commit 54659ca026e5 ("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 a7ac783c338b ("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: 54659ca026e5 ("staging: rtl8723bs: remove possible deadlock when disconnect (v2)")
Cc: stable 
Cc: Fabio Aiuto 
Signed-off-by: Hans de Goede 
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

staging: rtl8723bs: removed unused if blocks

2021-12-28T16:08:07+00:00

Deleted the commented if blocks that weren't being used as suggested by
the maintainers.

Signed-off-by: Ismayil Mirzali 
Link: https://lore.kernel.org/r/b4652b7490f3574445d567ef662270605533bfa4.1640197297.git.ismayilmirzeli@gmail.com
Signed-off-by: Greg Kroah-Hartman

staging: rtl8723bs: fix typo in a comment

2021-12-20T16:47:27+00:00

The double `for' in the comment in line 2203 is repeated. Remove one
of them from the comment.

Signed-off-by: Jason Wang 
Link: https://lore.kernel.org/r/20211211091632.264035-1-wangborong@cdjrlc.com
Signed-off-by: Greg Kroah-Hartman

staging: rtl8723bs: core: avoid unnecessary if condition

2021-11-15T09:02:04+00:00

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 
Link: https://lore.kernel.org/r/YYgWHt+PpyqOv40R@Sauravs-MacBook-Air.local
Signed-off-by: Greg Kroah-Hartman

staging: rtl8723bs: core: remove unused local variable padapter

2021-11-15T09:02:02+00:00

Remove the unused variable padapter from Efuse_Write1ByteToFakeContent
This variable is not used in the function.

Signed-off-by: Saurav Girepunje 
Link: https://lore.kernel.org/r/20211105165330.78524-3-saurav.girepunje@gmail.com
Signed-off-by: Greg Kroah-Hartman

staging: rtl8723bs: core: remove unused variable pAdapter

2021-11-15T09:02:02+00:00

Remove the unused variable pAdapter from Efuse_Read1ByteFromFakeContent
This variable is not used in the function.

Signed-off-by: Saurav Girepunje 
Link: https://lore.kernel.org/r/20211105165330.78524-2-saurav.girepunje@gmail.com
Signed-off-by: Greg Kroah-Hartman

Merge branch 'exit-cleanups-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace

2021-11-11T00:15:54+00:00

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
  ...

Merge tag 'staging-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

2021-11-04T14:56:22+00:00

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
  ...

staging: rtl8723bs: hal remove the assignment to itself

2021-10-30T09:14:53+00:00

Remove the assignment of variable to itself.
Assigning the variable to itself not make any difference on value.

Signed-off-by: Saurav Girepunje 
Link: https://lore.kernel.org/r/YXoq2ViLxPVwAgLq@Sauravs-MacBook-Air.local
Signed-off-by: Greg Kroah-Hartman