mac80211: don't use napi_gro_receive() outside NAPI context
No matter how the driver manages its NAPI context, there's no way sending frames to it from a timer can be correct, since it would corrupt the internal GRO lists. To avoid that, always use the non-NAPI path when releasing frames from the timer. Cc: stable@vger.kernel.org Reported-by: Jean Trivelly <jean.trivelly@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This commit is contained in:
parent
47b4e1fc49
commit
22d3a3c829
|
@ -205,6 +205,8 @@ enum ieee80211_packet_rx_flags {
|
|||
* @IEEE80211_RX_CMNTR: received on cooked monitor already
|
||||
* @IEEE80211_RX_BEACON_REPORTED: This frame was already reported
|
||||
* to cfg80211_report_obss_beacon().
|
||||
* @IEEE80211_RX_REORDER_TIMER: this frame is released by the
|
||||
* reorder buffer timeout timer, not the normal RX path
|
||||
*
|
||||
* These flags are used across handling multiple interfaces
|
||||
* for a single frame.
|
||||
|
@ -212,6 +214,7 @@ enum ieee80211_packet_rx_flags {
|
|||
enum ieee80211_rx_flags {
|
||||
IEEE80211_RX_CMNTR = BIT(0),
|
||||
IEEE80211_RX_BEACON_REPORTED = BIT(1),
|
||||
IEEE80211_RX_REORDER_TIMER = BIT(2),
|
||||
};
|
||||
|
||||
struct ieee80211_rx_data {
|
||||
|
|
|
@ -2121,7 +2121,8 @@ ieee80211_deliver_skb(struct ieee80211_rx_data *rx)
|
|||
/* deliver to local stack */
|
||||
skb->protocol = eth_type_trans(skb, dev);
|
||||
memset(skb->cb, 0, sizeof(skb->cb));
|
||||
if (rx->local->napi)
|
||||
if (!(rx->flags & IEEE80211_RX_REORDER_TIMER) &&
|
||||
rx->local->napi)
|
||||
napi_gro_receive(rx->local->napi, skb);
|
||||
else
|
||||
netif_receive_skb(skb);
|
||||
|
@ -3231,7 +3232,7 @@ void ieee80211_release_reorder_timeout(struct sta_info *sta, int tid)
|
|||
/* This is OK -- must be QoS data frame */
|
||||
.security_idx = tid,
|
||||
.seqno_idx = tid,
|
||||
.flags = 0,
|
||||
.flags = IEEE80211_RX_REORDER_TIMER,
|
||||
};
|
||||
struct tid_ampdu_rx *tid_agg_rx;
|
||||
|
||||
|
|
Loading…
Reference in New Issue