ath9k: fix possible hang on flush

If a flush is requested, make sure to clear the descriptor once we've processed it.

This resolves a hang that will occur if all RX descriptors are full when a flush is requested.

Signed-off-by Tim Harvey <[email protected]>

---
 drivers/net/wireless/ath/ath9k/recv.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

drivers/net/wireless/ath/ath9k/recv.c +2 -4

index 6c9accd..e77a253 100644
@@ -1113,14 +1113,13 @@ requeue_drop_frag:
                }
 requeue:
                list_add_tail(&bf->list, &sc->rx.rxbuf);
-               if (flush)
-                       continue;
 
                if (edma) {
                        ath_rx_edma_buf_link(sc, qtype);
                } else {
                        ath_rx_buf_relink(sc, bf);
-                       ath9k_hw_rxena(ah);
+                       if (!flush)
+                               ath9k_hw_rxena(ah);
                }
        } while (1);
 
--

1.8.3.2

Implement a recv budget so that in cases of high traffic we still allow other taskets to get processed.

Without this, we can encounter a host of issues during high wireless traffic reception depending on system load including rcu stall's detected (ARM), soft lockups, failure to service critical tasks such as watchdog resets, and triggering of the tx stuck tasklet.

The same thing was proposed previously by Ben:
http://www.spinics.net/lists/linux-wireless/msg112891.html

The only difference here is that I make sure only processed packets are counted in the budget by checking at the end of the rx loop.

Signed-off-by Tim Harvey <[email protected]>

Quoted 11 lines · Tim Harvey

Implement a recv budget so that in cases of high traffic we still allow other taskets to get processed.

Without this, we can encounter a host of issues during high wireless traffic reception depending on system load including rcu stall's detected (ARM), soft lockups, failure to service critical tasks such as watchdog resets, and triggering of the tx stuck tasklet.

The same thing was proposed previously by Ben:
http://www.spinics.net/lists/linux-wireless/msg112891.html

Quoted 4 lines

The only difference here is that I make sure only processed packets are counted in the budget by checking at the end of the rx loop.

Signed-off-by Tim Harvey <[email protected]>

For both patches:

Acked-by Felix Fietkau <[email protected]>

Quoted 19 lines · Felix Fietkau

Quoted 8 lines · Tim Harvey

Implement a recv budget so that in cases of high traffic we still allow other taskets to get processed.

Without this, we can encounter a host of issues during high wireless traffic reception depending on system load including rcu stall's detected (ARM), soft lockups, failure to service critical tasks such as watchdog resets, and triggering of the tx stuck tasklet.

Quoted 7 lines

The same thing was proposed previously by Ben:
http://www.spinics.net/lists/linux-wireless/msg112891.html

The only difference here is that I make sure only processed packets are counted in the budget by checking at the end of the rx loop.

Signed-off-by Tim Harvey <[email protected]>

For both patches:

Acked-by Felix Fietkau <[email protected]>

(quoted diff) +2 -0

+cc ath9k-devel at lists.ath9k.org
+cc Ben Greear

Any other ack's or comments on these? These address some fairly long-standing bugs.

Implement a recv budget so that in cases of high traffic we still allow other taskets to get processed.

Without this, we can encounter a host of issues during high wireless traffic reception depending on system load including rcu stall's detected (ARM), soft lockups, failure to service critical tasks such as watchdog resets, and triggering of the tx stuck tasklet.