• Rajkumar Manoharan's avatar
    ath10k: fix deadlock while processing rx_in_ord_ind · e50525be
    Rajkumar Manoharan authored
    commit 5c86d97b ("ath10k: combine txrx and replenish task")
    introduced deadlock while processing rx in order indication message
    for qca6174 based devices. While merging replenish and txrx tasklets,
    replenish task should be called out of htt rx ring locking since it
    is also try to acquire the same lock.
    
    Unfortunately this issue is not exposed by other solutions (qca988x,
    qca99x0 & qca4019), as rx_in_ord_ind message is specific to qca6174
    based devices. This patch fixes
    
    =============================================
    [ INFO: possible recursive locking detected ]
    4.7.0-rc2-wt-ath+ #1353 Tainted: G            E
    ---------------------------------------------
    swapper/3/0 is trying to acquire lock:
     (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d7ef19>]
    ath10k_htt_rx_msdu_buff_replenish+0x29/0x90 [ath10k_core]
    
    but task is already holding lock:
     (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
    ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
    
    other info that might help us debug this:
     Possible unsafe locking scenario:
    
           CPU0
           ----
      lock(&(&htt->rx_ring.lock)->rlock);
      lock(&(&htt->rx_ring.lock)->rlock);
    
     *** DEADLOCK ***
    
     May be due to missing lock nesting notation
    
    1 lock held by swapper/3/0:
     #0:  (&(&htt->rx_ring.lock)->rlock){+.-...}, at: [<f8d82cab>]
    ath10k_htt_txrx_compl_task+0x21b/0x250 [ath10k_core]
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=119151
    Fixes: 5c86d97b ("ath10k: combine txrx and replenish task")
    Reported-by: default avatarMike Lothian <mike@fireburn.co.uk>
    Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qti.qualcomm.com>
    Signed-off-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
    e50525be
htt_rx.c 66 KB