2019-06-04 10:11:33 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-09-03 15:24:57 +03:00
|
|
|
|
2025-06-17 10:49:01 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-22 11:52:18 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
[MAC80211]: fix race conditions with keys
During receive processing, we select the key long before using it and
because there's no locking it is possible that we kfree() the key
after having selected it but before using it for crypto operations.
Obviously, this is bad.
Secondly, during transmit processing, there are two possible races: We
have a similar race between select_key() and using it for encryption,
but we also have a race here between select_key() and hardware
encryption (both when a key is removed.)
This patch solves these issues by using RCU: when a key is to be freed,
we first remove the pointer from the appropriate places (sdata->keys,
sdata->default_key, sta->key) using rcu_assign_pointer() and then
synchronize_rcu(). Then, we can safely kfree() the key and remove it
from the hardware. There's a window here where the hardware may still
be using it for decryption, but we can't work around that without having
two hardware callbacks, one to disable the key for RX and one to disable
it for TX; but the worst thing that will happen is that we receive a
packet decrypted that we don't find a key for any more and then drop it.
When we add a key, we first need to upload it to the hardware and then,
using rcu_assign_pointer() again, link it into our structures.
In the code using keys (TX/RX paths) we use rcu_dereference() to get the
key and enclose the whole tx/rx section in a rcu_read_lock() ...
rcu_read_unlock() block. Because we've uploaded the key to hardware
before linking it into internal structures, we can guarantee that it is
valid once get to into tx().
One possible race condition remains, however: when we have hardware
acceleration enabled and the driver shuts down the queues, we end up
queueing the frame. If now somebody removes the key, the key will be
removed from hwaccel and then then driver will be asked to encrypt the
frame with a key index that has been removed. Hence, drivers will need
to be aware that the hw_key_index they are passed might not be under
all circumstances. Most drivers will, however, simply ignore that
condition and encrypt the frame with the selected key anyway, this
only results in a frame being encrypted with a wrong key or dropped
(rightfully) because the key was not valid. There isn't much we can
do about it unless we want to walk the pending frame queue every time
a key is removed and remove all frames that used it.
This race condition, however, will most likely be solved once we add
multiqueue support to mac80211 because then frames will be queued
further up the stack instead of after being processed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-14 11:10:24 -04:00
|
|
|
|
2011-07-15 11:47:34 -04:00
|
|
|
|
2007-09-17 11:56:21 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
2024-10-01 15:35:57 -04:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2025-03-13 13:49:39 +01:00
|
|
|
|
2023-06-08 19:17:37 +00:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2009-04-23 18:52:52 +02:00
|
|
|
|
2008-04-08 15:14:40 -04:00
|
|
|
|
2008-02-23 15:17:10 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-04-08 15:14:40 -04:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
|
|
|
|
|
2008-06-25 14:36:27 +03:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2023-08-29 12:17:44 +02:00
|
|
|
|
2008-05-15 12:55:27 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2013-07-08 16:55:53 +02:00
|
|
|
|
2016-12-14 20:46:57 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2025-09-08 14:13:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-23 15:12:51 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2020-09-21 19:28:11 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-09-11 00:01:56 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-25 14:36:27 +03:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-29 19:34:35 +01:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-10-11 01:51:51 +02:00
|
|
|
|
2023-08-29 12:17:44 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2021-10-18 11:00:54 +01:00
|
|
|
|
2024-01-29 19:34:35 +01:00
|
|
|
|
2022-07-12 10:49:23 +02:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-04-12 15:56:15 +02:00
|
|
|
|
2019-08-02 13:30:58 +02:00
|
|
|
|
2024-01-29 19:34:35 +01:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2024-01-29 19:34:35 +01:00
|
|
|
|
|
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-29 19:34:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-29 12:17:44 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2011-11-21 21:34:30 +01:00
|
|
|
|
|
|
|
|
|
2012-05-28 13:06:25 +01:00
|
|
|
|
2011-11-21 21:34:30 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-11 08:47:56 +02:00
|
|
|
|
2023-08-29 12:17:44 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-11 08:47:56 +02:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2023-08-29 12:17:44 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-06-25 14:36:27 +03:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-12 10:42:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: check uapsd state for dynamic power save
To make U-APSD client mode effective, we must not wake up from dynamic power
save when transmitting frames. So if dynamic power save is enabled, it needs
check the queue the transmitted packet is in and decide if we need to wake
up or not.
In a perfect world, where all packets would have correct QoS tags, U-APSD
enabled queues should not trigger wakeup from power save. But in the real
world, where very few packets have correct QoS tags, this won't work. For
example, if only voip class has U-APSD enabled and we send a packet in voip
class, but the packets we receive are in best effort class, we would receive
the packets with the legacy power save method. And that would increase
latencies too much from a voip application point of view.
The workaround is to enable U-APSD for all qeueus and still use dynamic ps
wakeup for all other queues except voip. That way we can still save power
with a voip application and not sacrifice latency. Normal traffic (in
background, best effort or video class) would still trigger wakeup from
dynamic power save.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-12 10:42:53 +02:00
|
|
|
|
2018-09-05 08:06:14 +03:00
|
|
|
|
2010-01-12 10:42:46 +02:00
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2010-01-12 10:42:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2010-01-12 10:42:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: check uapsd state for dynamic power save
To make U-APSD client mode effective, we must not wake up from dynamic power
save when transmitting frames. So if dynamic power save is enabled, it needs
check the queue the transmitted packet is in and decide if we need to wake
up or not.
In a perfect world, where all packets would have correct QoS tags, U-APSD
enabled queues should not trigger wakeup from power save. But in the real
world, where very few packets have correct QoS tags, this won't work. For
example, if only voip class has U-APSD enabled and we send a packet in voip
class, but the packets we receive are in best effort class, we would receive
the packets with the legacy power save method. And that would increase
latencies too much from a voip application point of view.
The workaround is to enable U-APSD for all qeueus and still use dynamic ps
wakeup for all other queues except voip. That way we can still save power
with a voip application and not sacrifice latency. Normal traffic (in
background, best effort or video class) would still trigger wakeup from
dynamic power save.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-12 10:42:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-05 08:06:14 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: check uapsd state for dynamic power save
To make U-APSD client mode effective, we must not wake up from dynamic power
save when transmitting frames. So if dynamic power save is enabled, it needs
check the queue the transmitted packet is in and decide if we need to wake
up or not.
In a perfect world, where all packets would have correct QoS tags, U-APSD
enabled queues should not trigger wakeup from power save. But in the real
world, where very few packets have correct QoS tags, this won't work. For
example, if only voip class has U-APSD enabled and we send a packet in voip
class, but the packets we receive are in best effort class, we would receive
the packets with the legacy power save method. And that would increase
latencies too much from a voip application point of view.
The workaround is to enable U-APSD for all qeueus and still use dynamic ps
wakeup for all other queues except voip. That way we can still save power
with a voip application and not sacrifice latency. Normal traffic (in
background, best effort or video class) would still trigger wakeup from
dynamic power save.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-12 10:42:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-14 16:15:03 +02:00
|
|
|
|
mac80211: check uapsd state for dynamic power save
To make U-APSD client mode effective, we must not wake up from dynamic power
save when transmitting frames. So if dynamic power save is enabled, it needs
check the queue the transmitted packet is in and decide if we need to wake
up or not.
In a perfect world, where all packets would have correct QoS tags, U-APSD
enabled queues should not trigger wakeup from power save. But in the real
world, where very few packets have correct QoS tags, this won't work. For
example, if only voip class has U-APSD enabled and we send a packet in voip
class, but the packets we receive are in best effort class, we would receive
the packets with the legacy power save method. And that would increase
latencies too much from a voip application point of view.
The workaround is to enable U-APSD for all qeueus and still use dynamic ps
wakeup for all other queues except voip. That way we can still save power
with a voip application and not sacrifice latency. Normal traffic (in
background, best effort or video class) would still trigger wakeup from
dynamic power save.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-12 10:42:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-27 14:18:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: check uapsd state for dynamic power save
To make U-APSD client mode effective, we must not wake up from dynamic power
save when transmitting frames. So if dynamic power save is enabled, it needs
check the queue the transmitted packet is in and decide if we need to wake
up or not.
In a perfect world, where all packets would have correct QoS tags, U-APSD
enabled queues should not trigger wakeup from power save. But in the real
world, where very few packets have correct QoS tags, this won't work. For
example, if only voip class has U-APSD enabled and we send a packet in voip
class, but the packets we receive are in best effort class, we would receive
the packets with the legacy power save method. And that would increase
latencies too much from a voip application point of view.
The workaround is to enable U-APSD for all qeueus and still use dynamic ps
wakeup for all other queues except voip. That way we can still save power
with a voip application and not sacrifice latency. Normal traffic (in
background, best effort or video class) would still trigger wakeup from
dynamic power save.
Signed-off-by: Kalle Valo <kalle.valo@nokia.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2010-01-12 10:42:53 +02:00
|
|
|
|
|
|
|
|
|
2010-01-12 10:42:46 +02:00
|
|
|
|
|
|
|
|
|
2013-02-13 12:25:28 +01:00
|
|
|
|
2014-06-13 16:30:05 +03:00
|
|
|
|
|
|
|
|
|
2011-02-18 17:18:03 +05:30
|
|
|
|
2023-08-28 13:59:44 +02:00
|
|
|
|
|
|
|
|
|
2010-01-12 10:42:46 +02:00
|
|
|
|
|
|
|
|
|
2011-05-03 21:40:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-12 10:42:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
mac80211: Optimize scans on current operating channel.
This should decrease un-necessary flushes, on/off channel work,
and channel changes in cases where the only scanned channel is
the current operating channel.
* Removes SCAN_OFF_CHANNEL flag, uses SDATA_STATE_OFFCHANNEL
and is-scanning flags instead.
* Add helper method to determine if we are currently configured
for the operating channel.
* Do no blindly go off/on channel in work.c Instead, only call
appropriate on/off code when we really need to change channels.
Always enable offchannel-ps mode when starting work,
and disable it when we are done.
* Consolidate ieee80211_offchannel_stop_station and
ieee80211_offchannel_stop_beaconing, call it
ieee80211_offchannel_stop_vifs instead.
* Accept non-beacon frames when scanning on operating channel.
* Scan state machine optimized to minimize on/off channel
transitions. Also, when going on-channel, go ahead and
re-enable beaconing. We're going to be there for 200ms,
so seems like some useful beaconing could happen.
Always enable offchannel-ps mode when starting software
scan, and disable it when we are done.
* Grab local->mtx earlier in __ieee80211_scan_completed_finish
so that we are protected when calling hw_config(), etc.
* Pass probe-responses up the stack if scanning on local
channel, so that mlme can take a look.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2011-02-04 11:54:17 -08:00
|
|
|
|
|
|
|
|
|
2009-03-18 14:06:44 +02:00
|
|
|
|
2020-01-13 21:59:40 -08:00
|
|
|
|
2009-03-18 14:06:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2014-11-03 10:33:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-06-22 11:29:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2016-10-10 19:12:21 +02:00
|
|
|
|
|
|
|
|
|
2011-12-14 12:20:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-18 17:29:21 -04:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-30 18:14:08 +01:00
|
|
|
|
|
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2016-08-02 11:13:41 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:46 +01:00
|
|
|
|
2011-09-29 16:04:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2011-09-29 16:04:29 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:46 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-06-22 11:29:50 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-12-19 01:31:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-30 18:14:08 +01:00
|
|
|
|
2007-12-19 01:31:25 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-30 18:14:08 +01:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-30 18:14:08 +01:00
|
|
|
|
|
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
mac80211: make master netdev handling sane
Currently, almost every interface type has a 'bss' pointer
pointing to BSS information. This BSS information, however,
is for a _local_ BSS, not for the BSS we joined, so having
it on a STA mode interface makes little sense, but now they
have it pointing to the master device, which is an AP mode
virtual interface. However, except for some bitrate control
data, this pointer is only used in AP/VLAN modes (for power
saving stations.)
Overall, it is not necessary to even have the master netdev
be a valid virtual interface, and it doesn't have to be on
the list of interfaces either.
This patch changes the master netdev to be special, it now
- no longer is on the list of virtual interfaces, which
lets me remove a lot of tests for that
- no longer has sub_if_data attached, since that isn't used
Additionally, this patch changes some vlan/ap mode handling
that is related to these 'bss' pointers described above (but
in the VLAN case they actually make sense because there they
point to the AP they belong to); it also adds some debugging
code to IEEE80211_DEV_TO_SUB_IF to validate it is not called
on the master netdev any more.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 14:40:34 +02:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
|
|
|
|
|
mac80211: make master netdev handling sane
Currently, almost every interface type has a 'bss' pointer
pointing to BSS information. This BSS information, however,
is for a _local_ BSS, not for the BSS we joined, so having
it on a STA mode interface makes little sense, but now they
have it pointing to the master device, which is an AP mode
virtual interface. However, except for some bitrate control
data, this pointer is only used in AP/VLAN modes (for power
saving stations.)
Overall, it is not necessary to even have the master netdev
be a valid virtual interface, and it doesn't have to be on
the list of interfaces either.
This patch changes the master netdev to be special, it now
- no longer is on the list of virtual interfaces, which
lets me remove a lot of tests for that
- no longer has sub_if_data attached, since that isn't used
Additionally, this patch changes some vlan/ap mode handling
that is related to these 'bss' pointers described above (but
in the VLAN case they actually make sense because there they
point to the AP they belong to); it also adds some debugging
code to IEEE80211_DEV_TO_SUB_IF to validate it is not called
on the master netdev any more.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
2008-07-09 14:40:34 +02:00
|
|
|
|
|
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-12-19 01:31:25 +01:00
|
|
|
|
2014-07-07 12:01:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2013-05-28 17:24:15 +02:00
|
|
|
|
|
|
|
|
|
2018-11-28 22:39:16 +01:00
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-12-19 01:31:25 +01:00
|
|
|
|
2009-10-29 12:19:21 +01:00
|
|
|
|
2009-08-10 16:04:15 +02:00
|
|
|
|
2009-10-29 12:19:21 +01:00
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2009-08-10 16:04:15 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-08-10 16:04:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:25 +01:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2012-06-22 11:29:50 +02:00
|
|
|
|
|
|
|
|
|
2016-08-02 11:13:41 +02:00
|
|
|
|
2009-08-10 16:04:15 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2009-08-10 16:04:15 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2009-01-08 13:32:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
2009-01-08 13:32:00 +02:00
|
|
|
|
|
|
|
|
|
2014-01-23 16:20:29 +01:00
|
|
|
|
2009-01-08 13:32:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2014-07-07 12:01:11 +02:00
|
|
|
|
2010-04-19 10:12:52 +03:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-02-27 12:18:30 +01:00
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 16:32:27 +02:00
|
|
|
|
|
|
|
|
|
2012-02-27 12:18:30 +01:00
|
|
|
|
2011-09-29 16:04:29 +02:00
|
|
|
|
|
|
|
|
|
2014-07-07 12:01:11 +02:00
|
|
|
|
2023-03-31 16:59:08 +02:00
|
|
|
|
2014-07-07 12:01:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-06-22 11:29:50 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
mac80211: fix AP powersave TX vs. wakeup race
There is a race between the TX path and the STA wakeup: while
a station is sleeping, mac80211 buffers frames until it wakes
up, then the frames are transmitted. However, the RX and TX
path are concurrent, so the packet indicating wakeup can be
processed while a packet is being transmitted.
This can lead to a situation where the buffered frames list
is emptied on the one side, while a frame is being added on
the other side, as the station is still seen as sleeping in
the TX path.
As a result, the newly added frame will not be send anytime
soon. It might be sent much later (and out of order) when the
station goes to sleep and wakes up the next time.
Additionally, it can lead to the crash below.
Fix all this by synchronising both paths with a new lock.
Both path are not fastpath since they handle PS situations.
In a later patch we'll remove the extra skb queue locks to
reduce locking overhead.
BUG: unable to handle kernel
NULL pointer dereference at 000000b0
IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
*pde = 00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
Stack:
e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
Call Trace:
[<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
[<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
[<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
[<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
[<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
[<c149ef70>] dev_hard_start_xmit+0x450/0x950
[<c14b9aa9>] sch_direct_xmit+0xa9/0x250
[<c14b9c9b>] __qdisc_run+0x4b/0x150
[<c149f732>] dev_queue_xmit+0x2c2/0xca0
Cc: stable@vger.kernel.org
Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
[reword commit log, use a separate lock]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-02-20 09:22:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: fix station/driver powersave race
It is currently possible to have a race due to the station PS
unblock work like this:
* station goes to sleep with frames buffered in the driver
* driver blocks wakeup
* station wakes up again
* driver flushes/returns frames, and unblocks, which schedules
the unblock work
* unblock work starts to run, and checks that the station is
awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
* we process a received frame with PM=1, setting the flag again
* ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
to the driver, and then clearing the WLAN_STA_PS_DRIVER and
WLAN_STA_PS_STA flags
In this scenario, mac80211 will think that the station is awake,
while it really is asleep, and any TX'ed frames should be filtered
by the device (it will know that the station is sleeping) but then
passed to mac80211 again, which will not buffer it either as it
thinks the station is awake, and eventually the packets will be
dropped.
Fix this by moving the clearing of the flags to exactly where we
learn about the situation. This creates a problem of reordering,
so introduce another flag indicating that delivery is being done,
this new flag also queues frames and is cleared only while the
spinlock is held (which the queuing code also holds) so that any
concurrent delivery/TX is handled correctly.
Reported-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-05-27 16:32:27 +02:00
|
|
|
|
|
|
|
|
|
mac80211: fix AP powersave TX vs. wakeup race
There is a race between the TX path and the STA wakeup: while
a station is sleeping, mac80211 buffers frames until it wakes
up, then the frames are transmitted. However, the RX and TX
path are concurrent, so the packet indicating wakeup can be
processed while a packet is being transmitted.
This can lead to a situation where the buffered frames list
is emptied on the one side, while a frame is being added on
the other side, as the station is still seen as sleeping in
the TX path.
As a result, the newly added frame will not be send anytime
soon. It might be sent much later (and out of order) when the
station goes to sleep and wakes up the next time.
Additionally, it can lead to the crash below.
Fix all this by synchronising both paths with a new lock.
Both path are not fastpath since they handle PS situations.
In a later patch we'll remove the extra skb queue locks to
reduce locking overhead.
BUG: unable to handle kernel
NULL pointer dereference at 000000b0
IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
*pde = 00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
Stack:
e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
Call Trace:
[<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
[<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
[<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
[<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
[<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
[<c149ef70>] dev_hard_start_xmit+0x450/0x950
[<c14b9aa9>] sch_direct_xmit+0xa9/0x250
[<c14b9c9b>] __qdisc_run+0x4b/0x150
[<c149f732>] dev_queue_xmit+0x2c2/0xca0
Cc: stable@vger.kernel.org
Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
[reword commit log, use a separate lock]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-02-20 09:22:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:29 +02:00
|
|
|
|
|
|
|
|
|
2012-06-22 11:29:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-02-20 11:21:35 +01:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2009-07-14 00:33:34 +02:00
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2014-01-09 01:45:28 +01:00
|
|
|
|
2011-09-29 16:04:29 +02:00
|
|
|
|
mac80211: fix AP powersave TX vs. wakeup race
There is a race between the TX path and the STA wakeup: while
a station is sleeping, mac80211 buffers frames until it wakes
up, then the frames are transmitted. However, the RX and TX
path are concurrent, so the packet indicating wakeup can be
processed while a packet is being transmitted.
This can lead to a situation where the buffered frames list
is emptied on the one side, while a frame is being added on
the other side, as the station is still seen as sleeping in
the TX path.
As a result, the newly added frame will not be send anytime
soon. It might be sent much later (and out of order) when the
station goes to sleep and wakes up the next time.
Additionally, it can lead to the crash below.
Fix all this by synchronising both paths with a new lock.
Both path are not fastpath since they handle PS situations.
In a later patch we'll remove the extra skb queue locks to
reduce locking overhead.
BUG: unable to handle kernel
NULL pointer dereference at 000000b0
IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
*pde = 00000000
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
DR6: ffff0ff0 DR7: 00000400
Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
Stack:
e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
Call Trace:
[<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
[<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
[<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
[<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
[<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
[<c149ef70>] dev_hard_start_xmit+0x450/0x950
[<c14b9aa9>] sch_direct_xmit+0xa9/0x250
[<c14b9c9b>] __qdisc_run+0x4b/0x150
[<c149f732>] dev_queue_xmit+0x2c2/0xca0
Cc: stable@vger.kernel.org
Reported-by: Yaara Rozenblum <yaara.rozenblum@intel.com>
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Reviewed-by: Stanislaw Gruszka <sgruszka@redhat.com>
[reword commit log, use a separate lock]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2014-02-20 09:22:11 +02:00
|
|
|
|
2010-04-19 10:12:52 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:27 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2012-06-22 11:29:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-27 14:26:54 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-02 18:09:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: Send EAPOL frames at lowest rate
The current minstrel_ht rate control behavior is somewhat optimistic in
trying to find optimum TX rate. While this is usually fine for normal
Data frames, there are cases where a more conservative set of retry
parameters would be beneficial to make the connection more robust.
EAPOL frames are critical to the authentication and especially the
EAPOL-Key message 4/4 (the last message in the 4-way handshake) is
important to get through to the AP. If that message is lost, the only
recovery mechanism in many cases is to reassociate with the AP and start
from scratch. This can often be avoided by trying to send the frame with
more conservative rate and/or with more link layer retries.
In most cases, minstrel_ht is currently using the initial EAPOL-Key
frames for probing higher rates and this results in only five link layer
transmission attempts (one at high(ish) MCS and four at MCS0). While
this works with most APs, it looks like there are some deployed APs that
may have issues with the EAPOL frames using HT MCS immediately after
association. Similarly, there may be issues in cases where the signal
strength or radio environment is not good enough to be able to get
frames through even at couple of MCS 0 tries.
The best approach for this would likely to be to reduce the TX rate for
the last rate (3rd rate parameter in the set) to a low basic rate (say,
6 Mbps on 5 GHz and 2 or 5.5 Mbps on 2.4 GHz), but doing that cleanly
requires some more effort. For now, we can start with a simple one-liner
that forces the minimum rate to be used for EAPOL frames similarly how
the TX rate is selected for the IEEE 802.11 Management frames. This does
result in a small extra latency added to the cases where the AP would be
able to receive the higher rate, but taken into account how small number
of EAPOL frames are used, this is likely to be insignificant. A future
optimization in the minstrel_ht design can also allow this patch to be
reverted to get back to the more optimized initial TX rate.
It should also be noted that many drivers that do not use minstrel as
the rate control algorithm are already doing similar workarounds by
forcing the lowest TX rate to be used for EAPOL frames.
Cc: stable@vger.kernel.org
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Tested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2015-02-26 15:50:50 +02:00
|
|
|
|
2013-07-02 18:09:12 +02:00
|
|
|
|
2010-08-27 14:26:54 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-17 11:17:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-04 12:11:14 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-17 11:17:01 +02:00
|
|
|
|
2023-06-04 12:11:14 +03:00
|
|
|
|
2022-08-17 11:17:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-07-04 18:10:07 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
[MAC80211]: fix race conditions with keys
During receive processing, we select the key long before using it and
because there's no locking it is possible that we kfree() the key
after having selected it but before using it for crypto operations.
Obviously, this is bad.
Secondly, during transmit processing, there are two possible races: We
have a similar race between select_key() and using it for encryption,
but we also have a race here between select_key() and hardware
encryption (both when a key is removed.)
This patch solves these issues by using RCU: when a key is to be freed,
we first remove the pointer from the appropriate places (sdata->keys,
sdata->default_key, sta->key) using rcu_assign_pointer() and then
synchronize_rcu(). Then, we can safely kfree() the key and remove it
from the hardware. There's a window here where the hardware may still
be using it for decryption, but we can't work around that without having
two hardware callbacks, one to disable the key for RX and one to disable
it for TX; but the worst thing that will happen is that we receive a
packet decrypted that we don't find a key for any more and then drop it.
When we add a key, we first need to upload it to the hardware and then,
using rcu_assign_pointer() again, link it into our structures.
In the code using keys (TX/RX paths) we use rcu_dereference() to get the
key and enclose the whole tx/rx section in a rcu_read_lock() ...
rcu_read_unlock() block. Because we've uploaded the key to hardware
before linking it into internal structures, we can guarantee that it is
valid once get to into tx().
One possible race condition remains, however: when we have hardware
acceleration enabled and the driver shuts down the queues, we end up
queueing the frame. If now somebody removes the key, the key will be
removed from hwaccel and then then driver will be asked to encrypt the
frame with a key index that has been removed. Hence, drivers will need
to be aware that the hw_key_index they are passed might not be under
all circumstances. Most drivers will, however, simply ignore that
condition and encrypt the frame with the selected key anyway, this
only results in a frame being encrypted with a wrong key or dropped
(rightfully) because the key was not valid. There isn't much we can
do about it unless we want to walk the pending frame queue every time
a key is removed and remove all frames that used it.
This race condition, however, will most likely be solved once we add
multiqueue support to mac80211 because then frames will be queued
further up the stack instead of after being processed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-14 11:10:24 -04:00
|
|
|
|
2020-03-26 15:09:42 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2020-03-26 15:09:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[MAC80211]: fix race conditions with keys
During receive processing, we select the key long before using it and
because there's no locking it is possible that we kfree() the key
after having selected it but before using it for crypto operations.
Obviously, this is bad.
Secondly, during transmit processing, there are two possible races: We
have a similar race between select_key() and using it for encryption,
but we also have a race here between select_key() and hardware
encryption (both when a key is removed.)
This patch solves these issues by using RCU: when a key is to be freed,
we first remove the pointer from the appropriate places (sdata->keys,
sdata->default_key, sta->key) using rcu_assign_pointer() and then
synchronize_rcu(). Then, we can safely kfree() the key and remove it
from the hardware. There's a window here where the hardware may still
be using it for decryption, but we can't work around that without having
two hardware callbacks, one to disable the key for RX and one to disable
it for TX; but the worst thing that will happen is that we receive a
packet decrypted that we don't find a key for any more and then drop it.
When we add a key, we first need to upload it to the hardware and then,
using rcu_assign_pointer() again, link it into our structures.
In the code using keys (TX/RX paths) we use rcu_dereference() to get the
key and enclose the whole tx/rx section in a rcu_read_lock() ...
rcu_read_unlock() block. Because we've uploaded the key to hardware
before linking it into internal structures, we can guarantee that it is
valid once get to into tx().
One possible race condition remains, however: when we have hardware
acceleration enabled and the driver shuts down the queues, we end up
queueing the frame. If now somebody removes the key, the key will be
removed from hwaccel and then then driver will be asked to encrypt the
frame with a key index that has been removed. Hence, drivers will need
to be aware that the hw_key_index they are passed might not be under
all circumstances. Most drivers will, however, simply ignore that
condition and encrypt the frame with the selected key anyway, this
only results in a frame being encrypted with a wrong key or dropped
(rightfully) because the key was not valid. There isn't much we can
do about it unless we want to walk the pending frame queue every time
a key is removed and remove all frames that used it.
This race condition, however, will most likely be solved once we add
multiqueue support to mac80211 because then frames will be queued
further up the stack instead of after being processed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-14 11:10:24 -04:00
|
|
|
|
2022-08-17 11:17:01 +02:00
|
|
|
|
2010-12-09 19:49:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
[MAC80211]: fix race conditions with keys
During receive processing, we select the key long before using it and
because there's no locking it is possible that we kfree() the key
after having selected it but before using it for crypto operations.
Obviously, this is bad.
Secondly, during transmit processing, there are two possible races: We
have a similar race between select_key() and using it for encryption,
but we also have a race here between select_key() and hardware
encryption (both when a key is removed.)
This patch solves these issues by using RCU: when a key is to be freed,
we first remove the pointer from the appropriate places (sdata->keys,
sdata->default_key, sta->key) using rcu_assign_pointer() and then
synchronize_rcu(). Then, we can safely kfree() the key and remove it
from the hardware. There's a window here where the hardware may still
be using it for decryption, but we can't work around that without having
two hardware callbacks, one to disable the key for RX and one to disable
it for TX; but the worst thing that will happen is that we receive a
packet decrypted that we don't find a key for any more and then drop it.
When we add a key, we first need to upload it to the hardware and then,
using rcu_assign_pointer() again, link it into our structures.
In the code using keys (TX/RX paths) we use rcu_dereference() to get the
key and enclose the whole tx/rx section in a rcu_read_lock() ...
rcu_read_unlock() block. Because we've uploaded the key to hardware
before linking it into internal structures, we can guarantee that it is
valid once get to into tx().
One possible race condition remains, however: when we have hardware
acceleration enabled and the driver shuts down the queues, we end up
queueing the frame. If now somebody removes the key, the key will be
removed from hwaccel and then then driver will be asked to encrypt the
frame with a key index that has been removed. Hence, drivers will need
to be aware that the hw_key_index they are passed might not be under
all circumstances. Most drivers will, however, simply ignore that
condition and encrypt the frame with the selected key anyway, this
only results in a frame being encrypted with a wrong key or dropped
(rightfully) because the key was not valid. There isn't much we can
do about it unless we want to walk the pending frame queue every time
a key is removed and remove all frames that used it.
This race condition, however, will most likely be solved once we add
multiqueue support to mac80211 because then frames will be queued
further up the stack instead of after being processed.
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Michael Wu <flamingice@sourmilk.net>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2007-09-14 11:10:24 -04:00
|
|
|
|
2015-03-20 11:37:36 +01:00
|
|
|
|
2012-07-04 18:10:07 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2025-07-17 17:45:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2010-01-17 01:47:58 +01:00
|
|
|
|
|
|
|
|
|
2007-09-17 01:29:25 -04:00
|
|
|
|
2007-12-18 15:27:47 +01:00
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
2007-12-18 15:27:47 +01:00
|
|
|
|
|
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
2015-01-24 19:52:07 +02:00
|
|
|
|
2015-01-24 19:52:06 +02:00
|
|
|
|
|
|
|
|
|
2009-01-08 13:32:00 +02:00
|
|
|
|
|
|
|
|
|
2016-06-22 19:55:20 +09:00
|
|
|
|
2026-01-14 16:48:59 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-01-08 13:32:00 +02:00
|
|
|
|
2010-01-23 20:27:14 +02:00
|
|
|
|
|
|
|
|
|
2012-09-04 17:08:23 +02:00
|
|
|
|
2010-01-23 20:27:14 +02:00
|
|
|
|
2009-01-08 13:32:00 +02:00
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
2015-01-24 19:52:08 +02:00
|
|
|
|
2015-01-24 19:52:09 +02:00
|
|
|
|
|
|
|
|
|
2009-01-08 13:32:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-18 15:27:47 +01:00
|
|
|
|
2010-01-17 01:47:58 +01:00
|
|
|
|
2013-01-29 11:41:38 +01:00
|
|
|
|
wifi: mac80211: allow transmitting EAPOL frames with tainted key
Lower layer device driver stop/wake TX by calling ieee80211_stop_queue()/
ieee80211_wake_queue() while hw scan. Sometimes hw scan and PTK rekey are
running in parallel, when M4 sent from wpa_supplicant arrive while the TX
queue is stopped, then the M4 will pending send, and then new key install
from wpa_supplicant. After TX queue wake up by lower layer device driver,
the M4 will be dropped by below call stack.
When key install started, the current key flag is set KEY_FLAG_TAINTED in
ieee80211_pairwise_rekey(), and then mac80211 wait key install complete by
lower layer device driver. Meanwhile ieee80211_tx_h_select_key() will return
TX_DROP for the M4 in step 12 below, and then ieee80211_free_txskb() called
by ieee80211_tx_dequeue(), so the M4 will not send and free, then the rekey
process failed becaue AP not receive M4. Please see details in steps below.
There are a interval between KEY_FLAG_TAINTED set for current key flag and
install key complete by lower layer device driver, the KEY_FLAG_TAINTED is
set in this interval, all packet including M4 will be dropped in this
interval, the interval is step 8~13 as below.
issue steps:
TX thread install key thread
1. stop_queue -idle-
2. sending M4 -idle-
3. M4 pending -idle-
4. -idle- starting install key from wpa_supplicant
5. -idle- =>ieee80211_key_replace()
6. -idle- =>ieee80211_pairwise_rekey() and set
currently key->flags |= KEY_FLAG_TAINTED
7. -idle- =>ieee80211_key_enable_hw_accel()
8. -idle- =>drv_set_key() and waiting key install
complete from lower layer device driver
9. wake_queue -waiting state-
10. re-sending M4 -waiting state-
11. =>ieee80211_tx_h_select_key() -waiting state-
12. drop M4 by KEY_FLAG_TAINTED -waiting state-
13. -idle- install key complete with success/fail
success: clear flag KEY_FLAG_TAINTED
fail: start disconnect
Hence add check in step 11 above to allow the EAPOL send out in the
interval. If lower layer device driver use the old key/cipher to encrypt
the M4, then AP received/decrypt M4 correctly, after M4 send out, lower
layer device driver install the new key/cipher to hardware and return
success.
If lower layer device driver use new key/cipher to send the M4, then AP
will/should drop the M4, then it is same result with this issue, AP will/
should kick out station as well as this issue.
issue log:
kworker/u16:4-5238 [000] 6456.108926: stop_queue: phy1 queue:0, reason:0
wpa_supplicant-961 [003] 6456.119737: rdev_tx_control_port: wiphy_name=phy1 name=wlan0 ifindex=6 dest=ARRAY[9e, 05, 31, 20, 9b, d0] proto=36488 unencrypted=0
wpa_supplicant-961 [003] 6456.119839: rdev_return_int_cookie: phy1, returned 0, cookie: 504
wpa_supplicant-961 [003] 6456.120287: rdev_add_key: phy1, netdev:wlan0(6), key_index: 0, mode: 0, pairwise: true, mac addr: 9e:05:31:20:9b:d0
wpa_supplicant-961 [003] 6456.120453: drv_set_key: phy1 vif:wlan0(2) sta:9e:05:31:20:9b:d0 cipher:0xfac04, flags=0x9, keyidx=0, hw_key_idx=0
kworker/u16:9-3829 [001] 6456.168240: wake_queue: phy1 queue:0, reason:0
kworker/u16:9-3829 [001] 6456.168255: drv_wake_tx_queue: phy1 vif:wlan0(2) sta:9e:05:31:20:9b:d0 ac:0 tid:7
kworker/u16:9-3829 [001] 6456.168305: cfg80211_control_port_tx_status: wdev(1), cookie: 504, ack: false
wpa_supplicant-961 [003] 6459.167982: drv_return_int: phy1 - -110
issue call stack:
nl80211_frame_tx_status+0x230/0x340 [cfg80211]
cfg80211_control_port_tx_status+0x1c/0x28 [cfg80211]
ieee80211_report_used_skb+0x374/0x3e8 [mac80211]
ieee80211_free_txskb+0x24/0x40 [mac80211]
ieee80211_tx_dequeue+0x644/0x954 [mac80211]
ath10k_mac_tx_push_txq+0xac/0x238 [ath10k_core]
ath10k_mac_op_wake_tx_queue+0xac/0xe0 [ath10k_core]
drv_wake_tx_queue+0x80/0x168 [mac80211]
__ieee80211_wake_txqs+0xe8/0x1c8 [mac80211]
_ieee80211_wake_txqs+0xb4/0x120 [mac80211]
ieee80211_wake_txqs+0x48/0x80 [mac80211]
tasklet_action_common+0xa8/0x254
tasklet_action+0x2c/0x38
__do_softirq+0xdc/0x384
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Link: https://lore.kernel.org/r/20230801064751.25803-1-quic_wgong@quicinc.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-08-01 02:47:51 -04:00
|
|
|
|
|
|
|
|
|
2011-07-12 12:30:59 +02:00
|
|
|
|
|
|
|
|
|
2010-01-22 22:07:59 +01:00
|
|
|
|
2010-01-25 11:36:16 +01:00
|
|
|
|
2010-01-17 01:47:58 +01:00
|
|
|
|
2020-12-18 20:15:25 +01:00
|
|
|
|
2020-03-26 15:09:42 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2010-04-27 11:15:12 -07:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
2021-06-17 18:31:13 +02:00
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2025-09-08 14:13:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2010-04-27 11:15:12 -07:00
|
|
|
|
2009-04-20 18:39:05 +02:00
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2012-02-26 11:24:35 +01:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-16 13:38:42 +02:00
|
|
|
|
2024-07-29 15:48:16 +08:00
|
|
|
|
2024-03-26 22:08:54 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-04-16 13:38:42 +02:00
|
|
|
|
2010-11-11 15:07:23 +01:00
|
|
|
|
2011-11-24 17:15:20 -08:00
|
|
|
|
2015-08-05 16:02:28 +02:00
|
|
|
|
|
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2009-04-20 18:39:05 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
2013-04-16 13:38:43 +02:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 18:31:13 +02:00
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2009-07-16 10:15:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
2009-07-16 10:15:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 18:31:13 +02:00
|
|
|
|
|
|
|
|
|
2012-07-23 15:12:51 +02:00
|
|
|
|
2009-07-16 10:15:09 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2010-12-01 16:34:45 +01:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
2021-06-17 18:31:13 +02:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2010-12-01 16:34:45 +01:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2013-04-22 16:14:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-23 19:36:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-07-10 11:21:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-12 22:52:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-07-14 00:33:34 +02:00
|
|
|
|
2008-09-12 22:52:47 +02:00
|
|
|
|
|
|
|
|
|
2008-07-10 11:21:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:50 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-10 13:21:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-23 09:35:38 -04:00
|
|
|
|
|
|
|
|
|
2008-10-10 13:21:59 +02:00
|
|
|
|
2013-08-23 09:35:38 -04:00
|
|
|
|
|
|
|
|
|
2008-10-10 13:21:59 +02:00
|
|
|
|
2008-07-10 11:21:26 +02:00
|
|
|
|
2008-10-10 13:21:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-21 14:26:31 +01:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2008-07-10 11:21:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-02-19 14:48:40 +02:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2008-07-10 11:21:26 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2008-07-10 11:21:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2011-11-16 15:28:56 +01:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-09 13:14:26 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-24 14:23:27 +02:00
|
|
|
|
2022-02-09 13:14:26 +01:00
|
|
|
|
2013-03-24 14:23:27 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:56 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
networking: introduce and use skb_put_data()
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:20 +02:00
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2014-02-01 00:16:23 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-04-20 18:39:05 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-18 23:12:11 +03:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
|
|
|
|
|
2008-05-17 00:57:13 +02:00
|
|
|
|
|
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2008-06-12 15:42:29 +03:00
|
|
|
|
2008-05-17 00:57:13 +02:00
|
|
|
|
2008-10-24 09:55:27 +05:30
|
|
|
|
2008-05-17 00:57:13 +02:00
|
|
|
|
|
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
2011-10-07 14:01:25 +02:00
|
|
|
|
2009-04-29 23:35:56 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-02 19:46:16 +02:00
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-10 16:01:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2013-02-05 10:55:21 +01:00
|
|
|
|
2009-08-10 16:01:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2013-02-05 10:55:21 +01:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2013-02-05 10:55:21 +01:00
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2009-08-10 16:01:54 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
2015-01-24 19:52:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-08-10 09:46:38 +02:00
|
|
|
|
2025-11-13 22:05:11 +08:00
|
|
|
|
|
|
|
|
|
2015-01-24 19:52:08 +02:00
|
|
|
|
2025-11-13 22:05:11 +08:00
|
|
|
|
|
|
|
|
|
2015-01-24 19:52:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-24 19:52:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-15 12:55:28 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
2008-06-25 14:36:27 +03:00
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-25 14:36:27 +03:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2009-05-19 19:25:58 +03:00
|
|
|
|
|
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2008-06-25 14:36:27 +03:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
|
|
|
|
|
2008-06-25 14:36:27 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-22 21:50:28 -05:00
|
|
|
|
2012-03-07 17:20:30 +01:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
2011-11-22 21:50:28 -05:00
|
|
|
|
2010-06-10 10:21:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-05-13 14:15:49 +02:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-22 21:50:28 -05:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
2016-03-17 16:51:42 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2016-03-17 16:51:41 +02:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
2012-03-07 17:20:30 +01:00
|
|
|
|
|
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
2012-03-07 17:20:30 +01:00
|
|
|
|
|
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
2011-11-22 21:50:28 -05:00
|
|
|
|
2018-04-20 13:49:19 +03:00
|
|
|
|
2012-03-18 22:58:06 +01:00
|
|
|
|
2011-11-22 21:50:28 -05:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-14 10:59:54 +01:00
|
|
|
|
|
|
|
|
|
2021-06-29 13:28:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-05 11:39:24 +02:00
|
|
|
|
2025-06-17 18:06:10 +10:00
|
|
|
|
|
|
|
|
|
2021-06-29 13:28:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
|
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
|
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
|
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2021-06-29 13:28:53 +02:00
|
|
|
|
2011-10-07 14:01:24 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
|
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
|
|
|
|
|
2021-06-29 13:28:53 +02:00
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
2021-06-29 13:28:53 +02:00
|
|
|
|
|
|
|
|
|
2010-01-08 18:15:13 +01:00
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2011-09-29 16:04:41 +02:00
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
|
|
|
|
|
2018-02-19 14:48:40 +02:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
2021-06-29 13:28:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2010-06-10 10:21:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-10-24 09:55:27 +05:30
|
|
|
|
|
|
|
|
|
2007-08-28 17:01:54 -04:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2011-11-18 14:20:42 +01:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
2011-10-07 14:01:25 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2015-09-24 14:59:49 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2015-09-24 14:59:49 +02:00
|
|
|
|
|
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-01-31 19:48:20 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
|
|
|
|
|
2017-01-13 13:32:51 +01:00
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-28 15:19:53 +01:00
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
2023-03-31 16:59:08 +02:00
|
|
|
|
2018-09-05 08:06:09 +03:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
2017-01-13 13:32:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-07 17:13:28 +01:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
|
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 19:47:14 +01:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert "mac80211: Dynamically set CoDel parameters per station"
This reverts commit 484a54c2e597dbc4ace79c1687022282905afba0. The CoDel
parameter change essentially disables CoDel on slow stations, with some
questionable assumptions, as Dave pointed out in [0]. Quoting from
there:
But here are my pithy comments as to why this part of mac80211 is so
wrong...
static void sta_update_codel_params(struct sta_info *sta, u32 thr)
{
- if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
1) sta->local->num_sta is the number of associated, rather than
active, stations. "Active" stations in the last 50ms or so, might have
been a better thing to use, but as most people have far more than that
associated, we end up with really lousy codel parameters, all the
time. Mistake numero uno!
2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016.
- sta->cparams.target = MS2TIME(50);
This, by itself, was probably not too bad. 30ms might have been
better, at the time, when we were battling powersave etc, but 20ms was
enough, really, to cover most scenarios, even where we had low rate
2Ghz multicast to cope with. Even then, codel has a hard time finding
any sane drop rate at all, with a target this high.
- sta->cparams.interval = MS2TIME(300);
But this was horrible, a total mistake, that is leading to codel being
completely ineffective in almost any scenario on clients or APS.
100ms, even 80ms, here, would be vastly better than this insanity. I'm
seeing 5+seconds of delay accumulated in a bunch of otherwise happily
fq-ing APs....
100ms of observed jitter during a flow is enough. Certainly (in 2016)
there were interactions with powersave that I did not understand, and
still don't, but if you are transmitting in the first place, powersave
shouldn't be a problemmmm.....
- sta->cparams.ecn = false;
At the time we were pretty nervous about ecn, I'm kind of sanguine
about it now, and reliably indicating ecn seems better than turning it
off for any reason.
[...]
In production, on p2p wireless, I've had 8ms and 80ms for target and
interval for years now, and it works great.
I think Dave's arguments above are basically sound on the face of it,
and various experimentation with tighter CoDel parameters in the OpenWrt
community have show promising results[1]. So I don't think there's any
reason to keep this parameter fiddling; hence this revert.
[0] https://lore.kernel.org/linux-wireless/CAA93jw6NJ2cmLmMauz0xAgC2MGbBq6n0ZiZzAdkK0u4b+O2yXg@mail.gmail.com/
[1] https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/130
Suggested-By: Dave Taht <dave.taht@gmail.com>
In-memory-of: Dave Taht <dave.taht@gmail.com>
Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20250403183930.197716-1-toke@toke.dk
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2025-04-03 20:39:28 +02:00
|
|
|
|
2016-09-12 15:55:43 +02:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
2020-12-18 19:47:14 +01:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
2025-07-17 18:25:47 +02:00
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
2019-03-16 18:06:32 +01:00
|
|
|
|
|
|
|
|
|
2021-03-19 23:28:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-16 13:47:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-19 23:28:01 +01:00
|
|
|
|
2021-04-16 13:47:04 +02:00
|
|
|
|
2025-07-17 18:25:47 +02:00
|
|
|
|
2021-03-19 23:28:01 +01:00
|
|
|
|
|
|
|
|
|
2021-04-16 13:47:04 +02:00
|
|
|
|
2019-03-16 18:06:32 +01:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2017-10-06 11:53:33 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
2016-09-12 15:55:43 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
|
|
|
|
|
2018-09-05 08:06:09 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
2018-09-05 08:06:09 +03:00
|
|
|
|
2018-08-31 11:31:08 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
2025-06-15 13:53:09 +05:30
|
|
|
|
2018-05-08 13:03:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
2016-09-23 21:59:11 +02:00
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-23 21:59:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-21 16:37:42 -08:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
2016-06-29 14:00:34 +02:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
2016-06-29 14:00:34 +02:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-15 13:53:09 +05:30
|
|
|
|
2018-05-08 13:03:50 +02:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-03-25 15:05:03 +01:00
|
|
|
|
2016-05-19 10:37:51 +02:00
|
|
|
|
|
|
|
|
|
2016-06-29 14:00:34 +02:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2016-06-29 14:00:34 +02:00
|
|
|
|
2015-03-27 21:30:37 +01:00
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:40 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-01-13 13:32:51 +01:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
|
|
|
|
|
2019-10-01 23:26:35 +02:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-24 14:42:06 +01:00
|
|
|
|
2013-02-11 11:21:07 -06:00
|
|
|
|
2013-02-25 14:58:05 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-11 11:21:07 -06:00
|
|
|
|
2013-02-25 14:58:05 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-11 11:21:07 -06:00
|
|
|
|
2013-02-25 14:58:05 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-11 11:21:07 -06:00
|
|
|
|
2011-02-24 14:42:06 +01:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2008-07-24 18:46:44 +03:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
2019-10-01 23:26:35 +02:00
|
|
|
|
2010-07-22 17:11:28 +02:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2016-05-19 10:37:48 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-13 07:34:15 +01:00
|
|
|
|
|
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-28 22:37:29 +01:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-09 10:25:48 +02:00
|
|
|
|
|
|
|
|
|
2013-07-14 23:39:20 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-04-03 14:35:57 +02:00
|
|
|
|
2024-07-25 18:48:36 +02:00
|
|
|
|
2012-04-03 14:35:57 +02:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2015-11-24 15:41:50 +01:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
2012-04-03 14:35:57 +02:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-07 15:45:48 -05:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-01 23:26:35 +02:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
2011-11-24 14:47:36 +01:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2011-11-16 16:02:47 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-10-29 08:43:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
2010-01-12 10:42:46 +02:00
|
|
|
|
2009-10-29 08:43:48 +01:00
|
|
|
|
|
|
|
|
|
2010-08-27 14:26:54 +03:00
|
|
|
|
2009-10-29 08:43:48 +01:00
|
|
|
|
2010-01-17 01:47:59 +01:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
2025-08-22 10:51:10 +05:30
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-22 21:43:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-12-02 22:08:52 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-17 01:47:59 +01:00
|
|
|
|
2011-12-02 22:08:52 +01:00
|
|
|
|
2010-01-17 01:47:59 +01:00
|
|
|
|
|
|
|
|
|
2009-10-29 08:43:48 +01:00
|
|
|
|
|
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
2009-10-29 08:43:48 +01:00
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2011-01-31 22:29:12 +02:00
|
|
|
|
2008-06-30 15:10:44 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
2025-08-22 10:51:10 +05:30
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
2012-11-10 03:44:14 +01:00
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
|
|
|
|
|
2008-06-28 03:15:03 +03:00
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-14 18:01:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:12 +02:00
|
|
|
|
2013-10-14 18:01:00 +02:00
|
|
|
|
2026-03-14 06:54:55 +00:00
|
|
|
|
|
|
|
|
|
2013-10-14 18:01:00 +02:00
|
|
|
|
2026-03-14 06:54:55 +00:00
|
|
|
|
2013-10-14 18:01:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-01 09:10:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-14 18:01:00 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-24 14:42:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
2020-07-23 14:01:52 +04:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2011-02-24 14:42:06 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-24 14:42:06 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2007-09-26 17:53:18 +02:00
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2025-08-22 10:51:10 +05:30
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2018-09-05 06:22:59 -04:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-13 07:34:15 +01:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2011-02-24 14:42:06 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-06-28 18:41:37 +05:30
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
|
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
2011-06-28 18:41:37 +05:30
|
|
|
|
2019-01-29 11:10:57 +01:00
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
|
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-01-29 11:10:57 +01:00
|
|
|
|
|
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-07-29 15:39:14 +03:00
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2019-01-29 11:10:57 +01:00
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
2010-12-18 19:30:49 +01:00
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
2010-12-18 19:30:49 +01:00
|
|
|
|
|
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
|
|
|
|
|
2010-08-20 16:25:38 -07:00
|
|
|
|
|
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
2020-07-23 14:01:52 +04:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
2022-02-09 13:14:26 +01:00
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
2010-09-11 20:01:31 -07:00
|
|
|
|
2009-07-14 00:33:34 +02:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2013-01-30 18:14:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-15 14:40:31 +01:00
|
|
|
|
2013-01-30 18:14:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-27 14:18:36 +02:00
|
|
|
|
2009-08-10 17:29:29 -07:00
|
|
|
|
2011-09-07 17:49:53 -07:00
|
|
|
|
2020-07-23 14:01:52 +04:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2021-05-30 15:32:26 +02:00
|
|
|
|
2011-10-07 14:01:26 +02:00
|
|
|
|
|
|
|
|
|
2021-05-30 15:32:26 +02:00
|
|
|
|
2011-10-07 14:01:26 +02:00
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-30 15:32:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:49 +04:00
|
|
|
|
|
|
|
|
|
2020-11-04 10:18:19 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:26 +02:00
|
|
|
|
|
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-20 21:25:26 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-24 16:25:49 +01:00
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
2016-02-24 16:25:49 +01:00
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
2020-12-19 18:07:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-01-25 16:07:44 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
|
|
|
|
|
2016-02-23 15:43:35 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-09-20 14:45:22 +02:00
|
|
|
|
|
|
|
|
|
2016-02-23 15:43:35 +01:00
|
|
|
|
2021-09-20 14:45:22 +02:00
|
|
|
|
|
|
|
|
|
2016-02-23 15:43:35 +01:00
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:26 +02:00
|
|
|
|
|
|
|
|
|
2020-04-30 18:03:59 +02:00
|
|
|
|
2011-10-07 14:01:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
2021-05-30 15:32:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-20 21:25:26 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
2016-02-23 15:43:35 +01:00
|
|
|
|
2023-09-20 21:25:26 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-23 15:43:35 +01:00
|
|
|
|
|
|
|
|
|
2021-05-30 15:32:26 +02:00
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-02 15:54:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-01-26 17:11:13 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-31 19:50:57 +00:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2011-08-01 11:32:52 +02:00
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
2014-06-05 08:12:57 +02:00
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2022-09-20 17:55:41 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
2021-05-30 15:32:26 +02:00
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-01 11:32:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: Convert compare_ether_addr to ether_addr_equal
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-08 18:56:52 +00:00
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
|
|
|
|
|
2011-08-01 11:32:52 +02:00
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 10:57:46 +01:00
|
|
|
|
2019-11-22 12:42:42 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-09 10:57:46 +01:00
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
mac80211: Convert compare_ether_addr to ether_addr_equal
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-08 18:56:52 +00:00
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-19 01:08:30 +01:00
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 13:26:44 +02:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 13:26:44 +02:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
|
|
|
|
|
2013-01-13 23:10:26 +01:00
|
|
|
|
2014-06-05 08:12:57 +02:00
|
|
|
|
2025-12-16 11:52:42 +01:00
|
|
|
|
|
|
|
|
|
2013-01-13 23:10:26 +01:00
|
|
|
|
|
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2024-02-06 16:54:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-05 08:12:57 +02:00
|
|
|
|
|
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:09 +02:00
|
|
|
|
2016-02-19 12:18:01 +01:00
|
|
|
|
2021-04-01 18:44:55 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-05-30 15:32:26 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-23 14:01:53 +04:00
|
|
|
|
|
|
|
|
|
2016-02-19 12:18:01 +01:00
|
|
|
|
2020-07-23 14:01:52 +04:00
|
|
|
|
2011-10-07 14:01:23 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
2013-11-18 19:06:45 +02:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
2013-11-18 19:06:45 +02:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-07 15:45:48 -05:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-13 08:28:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-13 08:28:22 +02:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-01 21:17:34 +02:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-11-18 19:06:45 +02:00
|
|
|
|
|
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
2019-10-29 10:13:02 +01:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
|
|
|
|
|
2019-10-29 10:13:02 +01:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
2019-10-29 10:13:02 +01:00
|
|
|
|
|
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-29 10:13:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-01-15 12:25:50 +01:00
|
|
|
|
2019-10-29 10:13:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-10-29 10:13:02 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:07 +02:00
|
|
|
|
2020-09-24 19:25:11 +02:00
|
|
|
|
2019-04-11 13:47:25 -07:00
|
|
|
|
2020-09-24 19:25:11 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-09-16 14:18:59 +02:00
|
|
|
|
2010-12-18 19:30:48 +01:00
|
|
|
|
2012-07-30 15:11:56 +02:00
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2010-08-21 07:23:29 -07:00
|
|
|
|
2012-05-30 09:30:41 +08:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
2011-11-06 14:13:34 +01:00
|
|
|
|
|
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
2016-04-12 15:56:15 +02:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-28 21:01:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
2022-06-01 14:25:44 +02:00
|
|
|
|
2007-12-19 01:31:27 +01:00
|
|
|
|
2008-09-11 00:01:58 +02:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
2009-11-10 20:10:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-25 17:46:19 +01:00
|
|
|
|
2009-11-10 20:10:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
2014-07-22 14:50:47 +02:00
|
|
|
|
2009-11-10 20:10:05 +01:00
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
2009-11-10 20:10:05 +01:00
|
|
|
|
2020-07-07 15:45:48 -05:00
|
|
|
|
2009-11-10 20:10:05 +01:00
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2022-07-13 12:05:27 +03:00
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-07-13 12:05:27 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-24 12:30:16 +02:00
|
|
|
|
|
|
|
|
|
2022-07-13 12:05:27 +03:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-13 12:05:27 +03:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2007-08-28 17:01:54 -04:00
|
|
|
|
2008-02-23 15:17:10 +01:00
|
|
|
|
2008-09-11 00:01:58 +02:00
|
|
|
|
2012-05-30 09:30:41 +08:00
|
|
|
|
2013-02-19 10:04:50 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-15 14:40:31 +01:00
|
|
|
|
2013-02-19 10:04:50 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-02-03 13:58:37 +01:00
|
|
|
|
2013-02-15 14:40:31 +01:00
|
|
|
|
2016-02-03 13:58:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-02-19 10:04:50 +08:00
|
|
|
|
|
|
|
|
|
2016-02-28 20:03:56 -05:00
|
|
|
|
2012-05-30 09:30:41 +08:00
|
|
|
|
2008-09-22 13:30:32 +08:00
|
|
|
|
2010-12-28 19:28:11 -06:00
|
|
|
|
2011-01-10 00:44:23 -06:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-28 19:28:11 -06:00
|
|
|
|
mac80211: Convert compare_ether_addr to ether_addr_equal
Use the new bool function ether_addr_equal to add
some clarity and reduce the likelihood for misuse
of compare_ether_addr for sorting.
Done via cocci script:
$ cat compare_ether_addr.cocci
@@
expression a,b;
@@
- !compare_ether_addr(a, b)
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- compare_ether_addr(a, b)
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !ether_addr_equal(a, b) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) == 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- ether_addr_equal(a, b) != 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- !!ether_addr_equal(a, b)
+ ether_addr_equal(a, b)
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-08 18:56:52 +00:00
|
|
|
|
|
|
|
|
|
2009-08-10 12:15:48 -07:00
|
|
|
|
|
|
|
|
|
2013-02-15 14:40:31 +01:00
|
|
|
|
|
|
|
|
|
2008-09-22 13:30:32 +08:00
|
|
|
|
2012-08-20 11:28:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-22 13:30:32 +08:00
|
|
|
|
2009-08-10 12:15:48 -07:00
|
|
|
|
2009-11-25 17:46:19 +01:00
|
|
|
|
2012-08-20 11:28:25 -07:00
|
|
|
|
|
|
|
|
|
2013-02-15 14:40:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-08-10 12:15:48 -07:00
|
|
|
|
2012-08-20 11:28:25 -07:00
|
|
|
|
2013-02-15 14:40:31 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-22 13:30:32 +08:00
|
|
|
|
|
|
|
|
|
2019-04-11 13:47:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-23 15:17:10 +01:00
|
|
|
|
|
|
|
|
|
2008-09-11 00:01:58 +02:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
2011-09-28 14:12:54 +03:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
2023-06-16 09:53:52 +03:00
|
|
|
|
2024-06-12 14:35:56 +02:00
|
|
|
|
2023-06-16 09:53:52 +03:00
|
|
|
|
|
|
|
|
|
2011-09-28 14:12:54 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-16 09:53:52 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-28 14:12:54 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-10 20:10:05 +01:00
|
|
|
|
2022-05-16 15:00:15 +02:00
|
|
|
|
2009-11-25 17:46:19 +01:00
|
|
|
|
2009-11-10 20:10:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-15 15:37:23 +02:00
|
|
|
|
2009-11-10 20:10:05 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-08-28 17:01:54 -04:00
|
|
|
|
2014-11-03 10:33:19 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-09-11 00:01:58 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-02-15 12:44:28 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2007-08-28 17:01:54 -04:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2022-06-01 14:25:44 +02:00
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-01 14:25:44 +02:00
|
|
|
|
|
|
|
|
|
2011-11-06 14:13:34 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-09-29 16:04:36 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2015-03-21 08:09:55 +01:00
|
|
|
|
|
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
2007-12-19 01:31:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-01-28 17:19:37 +01:00
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:22 +01:00
|
|
|
|
2011-10-12 17:28:21 +02:00
|
|
|
|
2014-11-03 10:33:19 +01:00
|
|
|
|
2013-08-30 01:35:09 +04:00
|
|
|
|
2011-10-12 17:28:21 +02:00
|
|
|
|
2022-06-30 16:43:44 +03:00
|
|
|
|
2007-12-19 01:31:22 +01:00
|
|
|
|
2012-06-22 11:29:50 +02:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2007-12-19 01:31:22 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:22 +01:00
|
|
|
|
|
|
|
|
|
2023-08-28 15:09:23 +02:00
|
|
|
|
2025-05-21 00:34:29 +02:00
|
|
|
|
2023-08-28 15:09:23 +02:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
|
|
|
|
|
2011-11-06 14:13:34 +01:00
|
|
|
|
2010-12-02 18:44:09 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-26 21:35:32 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-12-02 18:44:09 +01:00
|
|
|
|
|
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-03-28 13:38:25 +09:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-06-18 01:19:51 -07:00
|
|
|
|
2022-02-09 13:14:26 +01:00
|
|
|
|
2008-05-29 10:38:53 +02:00
|
|
|
|
|
|
|
|
|
2020-10-09 13:25:41 +02:00
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2012-11-07 14:02:30 +01:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2016-07-13 11:00:02 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2007-09-14 11:10:24 -04:00
|
|
|
|
2010-06-29 15:08:06 +04:00
|
|
|
|
2016-07-13 11:00:02 +02:00
|
|
|
|
2008-02-23 15:17:10 +01:00
|
|
|
|
2010-06-29 15:08:06 +04:00
|
|
|
|
2008-02-23 15:17:10 +01:00
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
2007-09-14 11:10:24 -04:00
|
|
|
|
|
|
|
|
|
networking: make skb_push & __skb_push return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
@@
expression SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- fn(SKB, LEN)[0]
+ *(u8 *)fn(SKB, LEN)
Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:23 +02:00
|
|
|
|
2007-09-14 11:10:24 -04:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 01:16:56 +00:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2010-12-18 19:30:48 +01:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
|
|
|
|
|
2011-11-06 14:13:34 +01:00
|
|
|
|
2023-08-28 15:09:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:09 +02:00
|
|
|
|
2022-07-19 10:26:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
2022-07-19 10:26:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-05 14:08:41 +02:00
|
|
|
|
2022-07-19 10:26:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-11-06 14:13:34 +01:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-04 19:10:59 +01:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-24 14:59:49 +02:00
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-10 14:02:08 +02:00
|
|
|
|
2016-10-18 23:12:11 +03:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-14 10:28:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
2023-06-16 09:53:52 +03:00
|
|
|
|
2024-06-12 14:35:56 +02:00
|
|
|
|
2023-06-16 09:53:52 +03:00
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-29 15:53:48 +01:00
|
|
|
|
2023-06-16 09:53:52 +03:00
|
|
|
|
2024-01-29 15:53:48 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-16 15:00:15 +02:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-15 15:37:23 +02:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-07 15:45:48 -05:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-07-18 16:58:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-10 14:03:17 +02:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-12-01 13:50:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-31 15:00:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-19 21:34:08 +01:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-19 21:34:08 +01:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-10 14:03:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
2015-04-10 14:03:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2018-08-29 08:57:02 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2018-08-29 08:57:02 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
2018-08-29 08:57:02 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-15 13:28:18 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-15 13:28:18 +02:00
|
|
|
|
2016-10-15 13:28:19 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-16 16:51:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
2016-10-15 13:28:18 +02:00
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2016-10-15 13:28:18 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-10-15 13:28:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-15 15:37:23 +02:00
|
|
|
|
2016-10-15 13:28:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
2019-03-16 18:06:31 +01:00
|
|
|
|
2019-03-16 18:06:32 +01:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2018-08-31 01:04:13 +02:00
|
|
|
|
2018-08-29 08:57:02 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-18 04:38:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-15 11:03:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
2018-09-05 08:06:10 +03:00
|
|
|
|
2022-09-02 16:12:54 +02:00
|
|
|
|
2018-09-05 08:06:10 +03:00
|
|
|
|
2019-03-16 18:06:32 +01:00
|
|
|
|
|
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-12-18 19:47:14 +01:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2018-12-15 11:03:07 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
2019-03-16 18:06:31 +01:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-09-05 08:06:11 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2018-08-29 21:03:25 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
2021-08-30 15:32:40 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-29 08:57:02 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-30 10:55:49 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-29 08:57:02 +02:00
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-08-30 10:55:49 +02:00
|
|
|
|
2019-03-16 18:06:31 +01:00
|
|
|
|
2018-08-30 10:55:49 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
2016-05-19 10:37:49 +02:00
|
|
|
|
2016-03-03 22:59:00 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 18:31:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2021-06-17 18:31:12 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 18:31:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-11-13 23:46:24 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: prepare sta handling for MLO support
Currently in mac80211 each STA object is represented
using sta_info datastructure with the associated
STA specific information and drivers access ieee80211_sta
part of it.
With MLO (Multi Link Operation) support being added
in 802.11be standard, though the association is logically
with a single Multi Link capable STA, at the physical level
communication can happen via different advertised
links (uniquely identified by Channel, operating class,
BSSID) and hence the need to handle multiple link
STA parameters within a composite sta_info object
called the MLD STA. The different link STA part of
MLD STA are identified using the link address which can
be same or different as the MLD STA address and unique
link id based on the link vif.
To support extension of such a model, the sta_info
datastructure is modified to hold multiple link STA
objects with link specific params currently within
sta_info moved to this new structure. Similarly this is
done for ieee80211_sta as well which will be accessed
within mac80211 as well as by drivers, hence trivial
driver changes are expected to support this.
For current non MLO supported drivers, only one link STA
is present and link information is accessed via 'deflink'
member.
For MLO drivers, we still need to define the APIs etc. to
get the correct link ID and access the correct part of
the station info.
Currently in mac80211, all link STA info are accessed directly
via deflink. These will be updated to access via link pointers
indexed by link id with MLO support patches, with link id
being 0 for non MLO supported cases.
Except for couple of macro related changes, below spatch takes
care of updating mac80211 and driver code to access to the
link STA info via deflink.
@ieee80211_sta@
struct ieee80211_sta *s;
struct sta_info *si;
identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr};
@@
(
s->
- var
+ deflink.var
|
si->sta.
- var
+ deflink.var
)
@sta_info@
struct sta_info *si;
identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth};
@@
(
si->
- var
+ deflink.var
)
Signed-off-by: Sriram R <quic_srirrama@quicinc.com>
Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com
[remove MLO-drivers notes from commit message, not clear yet; run spatch]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-04-04 21:11:23 +05:30
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-19 21:34:08 +01:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 18:31:12 +02:00
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-06 23:31:41 +01:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-08-22 10:51:10 +05:30
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
2025-08-22 10:51:10 +05:30
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-21 00:34:29 +02:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-09 16:45:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
2022-05-26 21:35:32 +08:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: add stop/start logic for software TXQs
Sometimes, it is required to stop the transmissions momentarily and
resume it later; stopping the txqs becomes very critical in scenarios where
the packet transmission has to be ceased completely. For example, during
the hardware restart, during off channel operations,
when initiating CSA(upon detecting a radar on the DFS channel), etc.
The TX queue stop/start logic in mac80211 works well in stopping the TX
when drivers make use of netdev queues, i.e, when Qdiscs in network layer
take care of traffic scheduling. Since the devices implementing
wake_tx_queue can run without Qdiscs, packets will be handed to mac80211
directly without queueing them in the netdev queues.
Also, mac80211 does not invoke any of the
netif_stop_*/netif_wake_* APIs if wake_tx_queue is implemented.
Since the queues are not stopped in this case, transmissions can continue
and this will impact negatively on the operation of the wireless device.
For example,
During hardware restart, we stop the netdev queues so that packets are
not sent to the driver. Since ath10k implements wake_tx_queue,
TX queues will not be stopped and packets might reach the hardware while
it is restarting; this can make hardware unresponsive and the only
possible option for recovery is to reboot the entire system.
There is another problem to this, it is observed that the packets
were sent on the DFS channel for a prolonged duration after radar
detection impacting the channel closing time.
We can still invoke netif stop/wake APIs when wake_tx_queue is implemented
but this could lead to packet drops in network layer; adding stop/start
logic for software TXQs in mac80211 instead makes more sense; the change
proposed adds the same in mac80211.
Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-07-11 00:12:53 +05:30
|
|
|
|
2022-12-30 13:18:49 +01:00
|
|
|
|
wifi: mac80211: fortify the spinlock against deadlock by interrupt
In the function ieee80211_tx_dequeue() there is a particular locking
sequence:
begin:
spin_lock(&local->queue_stop_reason_lock);
q_stopped = local->queue_stop_reasons[q];
spin_unlock(&local->queue_stop_reason_lock);
However small the chance (increased by ftracetest), an asynchronous
interrupt can occur in between of spin_lock() and spin_unlock(),
and the interrupt routine will attempt to lock the same
&local->queue_stop_reason_lock again.
This will cause a costly reset of the CPU and the wifi device or an
altogether hang in the single CPU and single core scenario.
The only remaining spin_lock(&local->queue_stop_reason_lock) that
did not disable interrupts was patched, which should prevent any
deadlocks on the same CPU/core and the same wifi device.
This is the probable trace of the deadlock:
kernel: ================================
kernel: WARNING: inconsistent lock state
kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W
kernel: --------------------------------
kernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:
kernel: ffff9d6190779478 (&local->queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40
kernel: {IN-SOFTIRQ-W} state was registered at:
kernel: lock_acquire+0xc7/0x2d0
kernel: _raw_spin_lock+0x36/0x50
kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]
kernel: ieee80211_queue_skb+0x450/0x730 [mac80211]
kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]
kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]
kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211]
kernel: dev_hard_start_xmit+0xb5/0x260
kernel: __dev_queue_xmit+0xdbe/0x1200
kernel: neigh_resolve_output+0x166/0x260
kernel: ip_finish_output2+0x216/0xb80
kernel: __ip_finish_output+0x2a4/0x4d0
kernel: ip_finish_output+0x2d/0xd0
kernel: ip_output+0x82/0x2b0
kernel: ip_local_out+0xec/0x110
kernel: igmpv3_sendpack+0x5c/0x90
kernel: igmp_ifc_timer_expire+0x26e/0x4e0
kernel: call_timer_fn+0xa5/0x230
kernel: run_timer_softirq+0x27f/0x550
kernel: __do_softirq+0xb4/0x3a4
kernel: irq_exit_rcu+0x9b/0xc0
kernel: sysvec_apic_timer_interrupt+0x80/0xa0
kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30
kernel: _raw_spin_unlock_irqrestore+0x3f/0x70
kernel: free_to_partial_list+0x3d6/0x590
kernel: __slab_free+0x1b7/0x310
kernel: kmem_cache_free+0x52d/0x550
kernel: putname+0x5d/0x70
kernel: do_sys_openat2+0x1d7/0x310
kernel: do_sys_open+0x51/0x80
kernel: __x64_sys_openat+0x24/0x30
kernel: do_syscall_64+0x5c/0x90
kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc
kernel: irq event stamp: 5120729
kernel: hardirqs last enabled at (5120729): [<ffffffff9d149936>] trace_graph_return+0xd6/0x120
kernel: hardirqs last disabled at (5120728): [<ffffffff9d149950>] trace_graph_return+0xf0/0x120
kernel: softirqs last enabled at (5069900): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel: softirqs last disabled at (5067555): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel:
other info that might help us debug this:
kernel: Possible unsafe locking scenario:
kernel: CPU0
kernel: ----
kernel: lock(&local->queue_stop_reason_lock);
kernel: <Interrupt>
kernel: lock(&local->queue_stop_reason_lock);
kernel:
*** DEADLOCK ***
kernel: 8 locks held by kworker/5:0/25656:
kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530
kernel: #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530
kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #3: ffff9d6190778728 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #4: ffff9d619077b480 (&mvm->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #5: ffff9d61907bacd8 (&trans_pcie->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #6: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_queue_state_change+0x59/0x3a0 [iwlmvm]
kernel: #7: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
kernel:
stack backtrace:
kernel: CPU: 5 PID: 25656 Comm: kworker/5:0 Tainted: G W 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4
kernel: Hardware name: LENOVO 82H8/LNVNB161216, BIOS GGCN51WW 11/16/2022
kernel: Workqueue: events_freezable ieee80211_restart_work [mac80211]
kernel: Call Trace:
kernel: <TASK>
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: dump_stack_lvl+0x5f/0xa0
kernel: dump_stack+0x14/0x20
kernel: print_usage_bug.part.46+0x208/0x2a0
kernel: mark_lock.part.47+0x605/0x630
kernel: ? sched_clock+0xd/0x20
kernel: ? trace_clock_local+0x14/0x30
kernel: ? __rb_reserve_next+0x5f/0x490
kernel: ? _raw_spin_lock+0x1b/0x50
kernel: __lock_acquire+0x464/0x1990
kernel: ? mark_held_locks+0x4e/0x80
kernel: lock_acquire+0xc7/0x2d0
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ? ftrace_return_to_handler+0x8b/0x100
kernel: ? preempt_count_add+0x4/0x70
kernel: _raw_spin_lock+0x36/0x50
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel: ? prepare_ftrace_return+0xc5/0x190
kernel: ? ftrace_graph_func+0x16/0x20
kernel: ? 0xffffffffc02ab0b1
kernel: ? lock_acquire+0xc7/0x2d0
kernel: ? iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
kernel: ? ieee80211_tx_dequeue+0x9/0x1330 [mac80211]
kernel: ? __rcu_read_lock+0x4/0x40
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_queue_state_change+0x311/0x3a0 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_wake_sw_queue+0x17/0x20 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_unmap+0x1c9/0x1f0 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_free+0x55/0x130 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_tx_free+0x63/0x80 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: _iwl_trans_pcie_gen2_stop_device+0x3f3/0x5b0 [iwlwifi]
kernel: ? _iwl_trans_pcie_gen2_stop_device+0x9/0x5b0 [iwlwifi]
kernel: ? mutex_lock_nested+0x4/0x30
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_trans_pcie_gen2_stop_device+0x5f/0x90 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_stop_device+0x78/0xd0 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: __iwl_mvm_mac_start+0x114/0x210 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_mac_start+0x76/0x150 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: drv_start+0x79/0x180 [mac80211]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_reconfig+0x1523/0x1ce0 [mac80211]
kernel: ? synchronize_net+0x4/0x50
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_restart_work+0x108/0x170 [mac80211]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: process_one_work+0x250/0x530
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: worker_thread+0x48/0x3a0
kernel: ? __pfx_worker_thread+0x10/0x10
kernel: kthread+0x10f/0x140
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork+0x29/0x50
kernel: </TASK>
Fixes: 4444bc2116ae ("wifi: mac80211: Proper mark iTXQs for resumption")
Link: https://lore.kernel.org/all/1f58a0d1-d2b9-d851-73c3-93fcc607501c@alu.unizg.hr/
Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Cc: Gregory Greenman <gregory.greenman@intel.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/all/cdc80531-f25f-6f9d-b15f-25e16130b53a@alu.unizg.hr/
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Alexander Wetzel <alexander@wetzel-home.de>
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: tag, or it goes automatically?
Link: https://lore.kernel.org/r/20230425164005.25272-1-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-25 18:40:08 +02:00
|
|
|
|
2022-12-30 13:18:49 +01:00
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
2019-06-17 22:01:39 +02:00
|
|
|
|
|
|
|
|
|
2019-11-18 22:06:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-16 18:06:33 +01:00
|
|
|
|
wifi: mac80211: fortify the spinlock against deadlock by interrupt
In the function ieee80211_tx_dequeue() there is a particular locking
sequence:
begin:
spin_lock(&local->queue_stop_reason_lock);
q_stopped = local->queue_stop_reasons[q];
spin_unlock(&local->queue_stop_reason_lock);
However small the chance (increased by ftracetest), an asynchronous
interrupt can occur in between of spin_lock() and spin_unlock(),
and the interrupt routine will attempt to lock the same
&local->queue_stop_reason_lock again.
This will cause a costly reset of the CPU and the wifi device or an
altogether hang in the single CPU and single core scenario.
The only remaining spin_lock(&local->queue_stop_reason_lock) that
did not disable interrupts was patched, which should prevent any
deadlocks on the same CPU/core and the same wifi device.
This is the probable trace of the deadlock:
kernel: ================================
kernel: WARNING: inconsistent lock state
kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W
kernel: --------------------------------
kernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:
kernel: ffff9d6190779478 (&local->queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40
kernel: {IN-SOFTIRQ-W} state was registered at:
kernel: lock_acquire+0xc7/0x2d0
kernel: _raw_spin_lock+0x36/0x50
kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]
kernel: ieee80211_queue_skb+0x450/0x730 [mac80211]
kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]
kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]
kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211]
kernel: dev_hard_start_xmit+0xb5/0x260
kernel: __dev_queue_xmit+0xdbe/0x1200
kernel: neigh_resolve_output+0x166/0x260
kernel: ip_finish_output2+0x216/0xb80
kernel: __ip_finish_output+0x2a4/0x4d0
kernel: ip_finish_output+0x2d/0xd0
kernel: ip_output+0x82/0x2b0
kernel: ip_local_out+0xec/0x110
kernel: igmpv3_sendpack+0x5c/0x90
kernel: igmp_ifc_timer_expire+0x26e/0x4e0
kernel: call_timer_fn+0xa5/0x230
kernel: run_timer_softirq+0x27f/0x550
kernel: __do_softirq+0xb4/0x3a4
kernel: irq_exit_rcu+0x9b/0xc0
kernel: sysvec_apic_timer_interrupt+0x80/0xa0
kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30
kernel: _raw_spin_unlock_irqrestore+0x3f/0x70
kernel: free_to_partial_list+0x3d6/0x590
kernel: __slab_free+0x1b7/0x310
kernel: kmem_cache_free+0x52d/0x550
kernel: putname+0x5d/0x70
kernel: do_sys_openat2+0x1d7/0x310
kernel: do_sys_open+0x51/0x80
kernel: __x64_sys_openat+0x24/0x30
kernel: do_syscall_64+0x5c/0x90
kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc
kernel: irq event stamp: 5120729
kernel: hardirqs last enabled at (5120729): [<ffffffff9d149936>] trace_graph_return+0xd6/0x120
kernel: hardirqs last disabled at (5120728): [<ffffffff9d149950>] trace_graph_return+0xf0/0x120
kernel: softirqs last enabled at (5069900): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel: softirqs last disabled at (5067555): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel:
other info that might help us debug this:
kernel: Possible unsafe locking scenario:
kernel: CPU0
kernel: ----
kernel: lock(&local->queue_stop_reason_lock);
kernel: <Interrupt>
kernel: lock(&local->queue_stop_reason_lock);
kernel:
*** DEADLOCK ***
kernel: 8 locks held by kworker/5:0/25656:
kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530
kernel: #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530
kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #3: ffff9d6190778728 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #4: ffff9d619077b480 (&mvm->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #5: ffff9d61907bacd8 (&trans_pcie->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #6: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_queue_state_change+0x59/0x3a0 [iwlmvm]
kernel: #7: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
kernel:
stack backtrace:
kernel: CPU: 5 PID: 25656 Comm: kworker/5:0 Tainted: G W 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4
kernel: Hardware name: LENOVO 82H8/LNVNB161216, BIOS GGCN51WW 11/16/2022
kernel: Workqueue: events_freezable ieee80211_restart_work [mac80211]
kernel: Call Trace:
kernel: <TASK>
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: dump_stack_lvl+0x5f/0xa0
kernel: dump_stack+0x14/0x20
kernel: print_usage_bug.part.46+0x208/0x2a0
kernel: mark_lock.part.47+0x605/0x630
kernel: ? sched_clock+0xd/0x20
kernel: ? trace_clock_local+0x14/0x30
kernel: ? __rb_reserve_next+0x5f/0x490
kernel: ? _raw_spin_lock+0x1b/0x50
kernel: __lock_acquire+0x464/0x1990
kernel: ? mark_held_locks+0x4e/0x80
kernel: lock_acquire+0xc7/0x2d0
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ? ftrace_return_to_handler+0x8b/0x100
kernel: ? preempt_count_add+0x4/0x70
kernel: _raw_spin_lock+0x36/0x50
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel: ? prepare_ftrace_return+0xc5/0x190
kernel: ? ftrace_graph_func+0x16/0x20
kernel: ? 0xffffffffc02ab0b1
kernel: ? lock_acquire+0xc7/0x2d0
kernel: ? iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
kernel: ? ieee80211_tx_dequeue+0x9/0x1330 [mac80211]
kernel: ? __rcu_read_lock+0x4/0x40
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_queue_state_change+0x311/0x3a0 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_wake_sw_queue+0x17/0x20 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_unmap+0x1c9/0x1f0 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_free+0x55/0x130 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_tx_free+0x63/0x80 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: _iwl_trans_pcie_gen2_stop_device+0x3f3/0x5b0 [iwlwifi]
kernel: ? _iwl_trans_pcie_gen2_stop_device+0x9/0x5b0 [iwlwifi]
kernel: ? mutex_lock_nested+0x4/0x30
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_trans_pcie_gen2_stop_device+0x5f/0x90 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_stop_device+0x78/0xd0 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: __iwl_mvm_mac_start+0x114/0x210 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_mac_start+0x76/0x150 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: drv_start+0x79/0x180 [mac80211]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_reconfig+0x1523/0x1ce0 [mac80211]
kernel: ? synchronize_net+0x4/0x50
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_restart_work+0x108/0x170 [mac80211]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: process_one_work+0x250/0x530
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: worker_thread+0x48/0x3a0
kernel: ? __pfx_worker_thread+0x10/0x10
kernel: kthread+0x10f/0x140
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork+0x29/0x50
kernel: </TASK>
Fixes: 4444bc2116ae ("wifi: mac80211: Proper mark iTXQs for resumption")
Link: https://lore.kernel.org/all/1f58a0d1-d2b9-d851-73c3-93fcc607501c@alu.unizg.hr/
Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Cc: Gregory Greenman <gregory.greenman@intel.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/all/cdc80531-f25f-6f9d-b15f-25e16130b53a@alu.unizg.hr/
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Alexander Wetzel <alexander@wetzel-home.de>
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: tag, or it goes automatically?
Link: https://lore.kernel.org/r/20230425164005.25272-1-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-25 18:40:08 +02:00
|
|
|
|
2022-12-30 13:18:49 +01:00
|
|
|
|
wifi: mac80211: fortify the spinlock against deadlock by interrupt
In the function ieee80211_tx_dequeue() there is a particular locking
sequence:
begin:
spin_lock(&local->queue_stop_reason_lock);
q_stopped = local->queue_stop_reasons[q];
spin_unlock(&local->queue_stop_reason_lock);
However small the chance (increased by ftracetest), an asynchronous
interrupt can occur in between of spin_lock() and spin_unlock(),
and the interrupt routine will attempt to lock the same
&local->queue_stop_reason_lock again.
This will cause a costly reset of the CPU and the wifi device or an
altogether hang in the single CPU and single core scenario.
The only remaining spin_lock(&local->queue_stop_reason_lock) that
did not disable interrupts was patched, which should prevent any
deadlocks on the same CPU/core and the same wifi device.
This is the probable trace of the deadlock:
kernel: ================================
kernel: WARNING: inconsistent lock state
kernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G W
kernel: --------------------------------
kernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
kernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:
kernel: ffff9d6190779478 (&local->queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40
kernel: {IN-SOFTIRQ-W} state was registered at:
kernel: lock_acquire+0xc7/0x2d0
kernel: _raw_spin_lock+0x36/0x50
kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel: iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]
kernel: ieee80211_queue_skb+0x450/0x730 [mac80211]
kernel: __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]
kernel: __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]
kernel: ieee80211_subif_start_xmit+0x60/0x580 [mac80211]
kernel: dev_hard_start_xmit+0xb5/0x260
kernel: __dev_queue_xmit+0xdbe/0x1200
kernel: neigh_resolve_output+0x166/0x260
kernel: ip_finish_output2+0x216/0xb80
kernel: __ip_finish_output+0x2a4/0x4d0
kernel: ip_finish_output+0x2d/0xd0
kernel: ip_output+0x82/0x2b0
kernel: ip_local_out+0xec/0x110
kernel: igmpv3_sendpack+0x5c/0x90
kernel: igmp_ifc_timer_expire+0x26e/0x4e0
kernel: call_timer_fn+0xa5/0x230
kernel: run_timer_softirq+0x27f/0x550
kernel: __do_softirq+0xb4/0x3a4
kernel: irq_exit_rcu+0x9b/0xc0
kernel: sysvec_apic_timer_interrupt+0x80/0xa0
kernel: asm_sysvec_apic_timer_interrupt+0x1f/0x30
kernel: _raw_spin_unlock_irqrestore+0x3f/0x70
kernel: free_to_partial_list+0x3d6/0x590
kernel: __slab_free+0x1b7/0x310
kernel: kmem_cache_free+0x52d/0x550
kernel: putname+0x5d/0x70
kernel: do_sys_openat2+0x1d7/0x310
kernel: do_sys_open+0x51/0x80
kernel: __x64_sys_openat+0x24/0x30
kernel: do_syscall_64+0x5c/0x90
kernel: entry_SYSCALL_64_after_hwframe+0x72/0xdc
kernel: irq event stamp: 5120729
kernel: hardirqs last enabled at (5120729): [<ffffffff9d149936>] trace_graph_return+0xd6/0x120
kernel: hardirqs last disabled at (5120728): [<ffffffff9d149950>] trace_graph_return+0xf0/0x120
kernel: softirqs last enabled at (5069900): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel: softirqs last disabled at (5067555): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40
kernel:
other info that might help us debug this:
kernel: Possible unsafe locking scenario:
kernel: CPU0
kernel: ----
kernel: lock(&local->queue_stop_reason_lock);
kernel: <Interrupt>
kernel: lock(&local->queue_stop_reason_lock);
kernel:
*** DEADLOCK ***
kernel: 8 locks held by kworker/5:0/25656:
kernel: #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530
kernel: #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530
kernel: #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #3: ffff9d6190778728 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #4: ffff9d619077b480 (&mvm->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #5: ffff9d61907bacd8 (&trans_pcie->mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40
kernel: #6: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_queue_state_change+0x59/0x3a0 [iwlmvm]
kernel: #7: ffffffff9ef9cda0 (rcu_read_lock){....}-{1:2}, at: iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
kernel:
stack backtrace:
kernel: CPU: 5 PID: 25656 Comm: kworker/5:0 Tainted: G W 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4
kernel: Hardware name: LENOVO 82H8/LNVNB161216, BIOS GGCN51WW 11/16/2022
kernel: Workqueue: events_freezable ieee80211_restart_work [mac80211]
kernel: Call Trace:
kernel: <TASK>
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: dump_stack_lvl+0x5f/0xa0
kernel: dump_stack+0x14/0x20
kernel: print_usage_bug.part.46+0x208/0x2a0
kernel: mark_lock.part.47+0x605/0x630
kernel: ? sched_clock+0xd/0x20
kernel: ? trace_clock_local+0x14/0x30
kernel: ? __rb_reserve_next+0x5f/0x490
kernel: ? _raw_spin_lock+0x1b/0x50
kernel: __lock_acquire+0x464/0x1990
kernel: ? mark_held_locks+0x4e/0x80
kernel: lock_acquire+0xc7/0x2d0
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ? ftrace_return_to_handler+0x8b/0x100
kernel: ? preempt_count_add+0x4/0x70
kernel: _raw_spin_lock+0x36/0x50
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]
kernel: ? prepare_ftrace_return+0xc5/0x190
kernel: ? ftrace_graph_func+0x16/0x20
kernel: ? 0xffffffffc02ab0b1
kernel: ? lock_acquire+0xc7/0x2d0
kernel: ? iwl_mvm_mac_itxq_xmit+0x42/0x210 [iwlmvm]
kernel: ? ieee80211_tx_dequeue+0x9/0x1330 [mac80211]
kernel: ? __rcu_read_lock+0x4/0x40
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_queue_state_change+0x311/0x3a0 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_wake_sw_queue+0x17/0x20 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_unmap+0x1c9/0x1f0 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_free+0x55/0x130 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_txq_gen2_tx_free+0x63/0x80 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: _iwl_trans_pcie_gen2_stop_device+0x3f3/0x5b0 [iwlwifi]
kernel: ? _iwl_trans_pcie_gen2_stop_device+0x9/0x5b0 [iwlwifi]
kernel: ? mutex_lock_nested+0x4/0x30
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_trans_pcie_gen2_stop_device+0x5f/0x90 [iwlwifi]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_stop_device+0x78/0xd0 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: __iwl_mvm_mac_start+0x114/0x210 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: iwl_mvm_mac_start+0x76/0x150 [iwlmvm]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: drv_start+0x79/0x180 [mac80211]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_reconfig+0x1523/0x1ce0 [mac80211]
kernel: ? synchronize_net+0x4/0x50
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: ieee80211_restart_work+0x108/0x170 [mac80211]
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: process_one_work+0x250/0x530
kernel: ? ftrace_regs_caller_end+0x66/0x66
kernel: worker_thread+0x48/0x3a0
kernel: ? __pfx_worker_thread+0x10/0x10
kernel: kthread+0x10f/0x140
kernel: ? __pfx_kthread+0x10/0x10
kernel: ret_from_fork+0x29/0x50
kernel: </TASK>
Fixes: 4444bc2116ae ("wifi: mac80211: Proper mark iTXQs for resumption")
Link: https://lore.kernel.org/all/1f58a0d1-d2b9-d851-73c3-93fcc607501c@alu.unizg.hr/
Reported-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Cc: Gregory Greenman <gregory.greenman@intel.com>
Cc: Johannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/all/cdc80531-f25f-6f9d-b15f-25e16130b53a@alu.unizg.hr/
Cc: David S. Miller <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Alexander Wetzel <alexander@wetzel-home.de>
Signed-off-by: Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Reviewed-by: tag, or it goes automatically?
Link: https://lore.kernel.org/r/20230425164005.25272-1-mirsad.todorovac@alu.unizg.hr
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-04-25 18:40:08 +02:00
|
|
|
|
2022-12-30 13:18:49 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
2021-04-16 13:47:04 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-01-06 23:31:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-04-16 13:47:04 +02:00
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-16 18:06:33 +01:00
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-10-19 20:01:13 +04:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2020-03-26 15:51:34 +01:00
|
|
|
|
|
|
|
|
|
2020-10-19 20:01:13 +04:00
|
|
|
|
2020-03-26 15:51:34 +01:00
|
|
|
|
2020-10-19 20:01:13 +04:00
|
|
|
|
|
|
|
|
|
2020-03-29 22:50:06 +02:00
|
|
|
|
2020-03-26 15:51:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-24 12:37:32 +02:00
|
|
|
|
|
|
|
|
|
2020-03-26 15:51:34 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-17 17:45:29 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-04 10:27:52 +01:00
|
|
|
|
2023-01-06 23:31:41 +01:00
|
|
|
|
|
|
|
|
|
2016-11-04 10:27:52 +01:00
|
|
|
|
2021-06-17 18:31:13 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2021-06-17 18:31:13 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 18:31:12 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-31 16:49:10 +01:00
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2019-03-16 18:06:33 +01:00
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2019-03-16 18:06:33 +01:00
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
|
|
|
|
|
2018-12-15 11:03:09 +02:00
|
|
|
|
2016-10-04 09:22:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-06-22 12:20:30 +02:00
|
|
|
|
|
|
|
|
|
2024-10-09 10:25:48 +02:00
|
|
|
|
|
|
|
|
|
2017-06-22 12:20:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-25 18:48:36 +02:00
|
|
|
|
|
|
|
|
|
2017-06-22 12:20:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-31 16:49:11 +01:00
|
|
|
|
|
|
|
|
|
2017-06-22 12:20:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-07 15:45:48 -05:00
|
|
|
|
2017-06-22 12:20:30 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2024-01-31 16:49:10 +01:00
|
|
|
|
2019-11-18 22:06:10 -08:00
|
|
|
|
2022-07-13 10:34:44 +02:00
|
|
|
|
2020-02-21 10:45:45 +01:00
|
|
|
|
2020-07-24 20:28:16 +02:00
|
|
|
|
2019-11-18 22:06:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-24 20:28:16 +02:00
|
|
|
|
2019-11-18 22:06:10 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-16 18:06:33 +01:00
|
|
|
|
mac80211: add stop/start logic for software TXQs
Sometimes, it is required to stop the transmissions momentarily and
resume it later; stopping the txqs becomes very critical in scenarios where
the packet transmission has to be ceased completely. For example, during
the hardware restart, during off channel operations,
when initiating CSA(upon detecting a radar on the DFS channel), etc.
The TX queue stop/start logic in mac80211 works well in stopping the TX
when drivers make use of netdev queues, i.e, when Qdiscs in network layer
take care of traffic scheduling. Since the devices implementing
wake_tx_queue can run without Qdiscs, packets will be handed to mac80211
directly without queueing them in the netdev queues.
Also, mac80211 does not invoke any of the
netif_stop_*/netif_wake_* APIs if wake_tx_queue is implemented.
Since the queues are not stopped in this case, transmissions can continue
and this will impact negatively on the operation of the wireless device.
For example,
During hardware restart, we stop the netdev queues so that packets are
not sent to the driver. Since ath10k implements wake_tx_queue,
TX queues will not be stopped and packets might reach the hardware while
it is restarting; this can make hardware unresponsive and the only
possible option for recovery is to reboot the entire system.
There is another problem to this, it is observed that the packets
were sent on the DFS channel for a prolonged duration after radar
detection impacting the channel closing time.
We can still invoke netif stop/wake APIs when wake_tx_queue is implemented
but this could lead to packet drops in network layer; adding stop/start
logic for software TXQs in mac80211 instead makes more sense; the change
proposed adds the same in mac80211.
Signed-off-by: Manikanta Pubbisetty <mpubbise@codeaurora.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2018-07-11 00:12:53 +05:30
|
|
|
|
2016-09-22 19:04:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-06 09:09:27 +03:00
|
|
|
|
2022-06-25 23:24:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-12-06 09:09:27 +03:00
|
|
|
|
2022-06-25 23:24:08 +02:00
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2022-06-25 23:24:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-23 15:47:55 +02:00
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:07 +02:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2019-03-18 12:00:58 +01:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:08 +02:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2025-07-17 18:25:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2022-06-25 23:24:08 +02:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:08 +02:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:08 +02:00
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2019-01-22 15:20:16 +01:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2019-01-22 15:20:16 +01:00
|
|
|
|
2021-01-09 18:57:51 +01:00
|
|
|
|
|
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-18 22:06:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-18 22:06:09 -08:00
|
|
|
|
|
|
|
|
|
2019-12-12 12:14:37 +01:00
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-18 22:06:09 -08:00
|
|
|
|
|
|
|
|
|
2021-01-09 18:57:51 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-18 22:06:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-03-19 23:28:01 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-18 22:06:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
mac80211: Implement Airtime-based Queue Limit (AQL)
In order for the Fq_CoDel algorithm integrated in mac80211 layer to operate
effectively to control excessive queueing latency, the CoDel algorithm
requires an accurate measure of how long packets stays in the queue, AKA
sojourn time. The sojourn time measured at the mac80211 layer doesn't
include queueing latency in the lower layer (firmware/hardware) and CoDel
expects lower layer to have a short queue. However, most 802.11ac chipsets
offload tasks such TX aggregation to firmware or hardware, thus have a deep
lower layer queue.
Without a mechanism to control the lower layer queue size, packets only
stay in mac80211 layer transiently before being sent to firmware queue.
As a result, the sojourn time measured by CoDel in the mac80211 layer is
almost always lower than the CoDel latency target, hence CoDel does little
to control the latency, even when the lower layer queue causes excessive
latency.
The Byte Queue Limits (BQL) mechanism is commonly used to address the
similar issue with wired network interface. However, this method cannot be
applied directly to the wireless network interface. "Bytes" is not a
suitable measure of queue depth in the wireless network, as the data rate
can vary dramatically from station to station in the same network, from a
few Mbps to over Gbps.
This patch implements an Airtime-based Queue Limit (AQL) to make CoDel work
effectively with wireless drivers that utilized firmware/hardware
offloading. AQL allows each txq to release just enough packets to the lower
layer to form 1-2 large aggregations to keep hardware fully utilized and
retains the rest of the frames in mac80211 layer to be controlled by the
CoDel algorithm.
Signed-off-by: Kan Yan <kyan@google.com>
[ Toke: Keep API to set pending airtime internal, fix nits in commit msg ]
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-4-kyan@google.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2019-11-18 22:06:09 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2022-06-25 23:24:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:07 +02:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:08 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2022-06-25 23:24:09 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-25 23:24:05 +02:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2019-03-15 11:03:35 +01:00
|
|
|
|
2018-12-18 17:02:06 -08:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
2019-04-11 13:47:25 -07:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
2019-03-25 08:59:23 +01:00
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
2015-04-14 14:50:41 +02:00
|
|
|
|
2021-11-13 07:34:15 +01:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2022-09-20 17:55:41 +02:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: mesh fast xmit support
Previously, fast xmit only worked on interface types where initially a
sta lookup is performed, and a cached header can be attached to the sta,
requiring only some fields to be updated at runtime.
This technique is not directly applicable for a mesh device type due
to the dynamic nature of the topology and protocol. There are more
addresses that need to be filled, and there is an extra header with a
dynamic length based on the addressing mode.
Change the code to cache entries contain a copy of the mesh subframe header +
bridge tunnel header, as well as an embedded struct ieee80211_fast_tx, which
contains the information for building the 802.11 header.
Add a mesh specific early fast xmit call, which looks up a cached entry and
adds only the mesh subframe header, before passing it over to the generic
fast xmit code.
To ensure the changes in network are reflected in these cached headers,
flush affected cached entries on path changes, as well as other conditions
that currently trigger a fast xmit check in other modes (key changes etc.)
This code is loosely based on a previous implementation by:
Sriram R <quic_srirrama@quicinc.com>
Cc: Sriram R <quic_srirrama@quicinc.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Link: https://lore.kernel.org/r/20230314095956.62085-4-nbd@nbd.name
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2023-03-14 10:59:53 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-10 14:10:10 +02:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2019-03-25 08:59:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-09 18:30:40 +02:00
|
|
|
|
2021-06-17 18:31:11 +02:00
|
|
|
|
|
|
|
|
|
2019-03-25 08:59:23 +01:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-09-22 19:04:20 +02:00
|
|
|
|
2015-03-21 15:25:43 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-04-10 14:10:10 +02:00
|
|
|
|
|
|
|
|
|
2020-01-13 18:42:33 -05:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2020-06-17 10:26:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-11 13:47:25 -07:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
2020-01-13 18:42:33 -05:00
|
|
|
|
|
|
|
|
|
2015-04-14 14:50:41 +02:00
|
|
|
|
2020-01-13 18:42:33 -05:00
|
|
|
|
2015-04-14 14:50:41 +02:00
|
|
|
|
2020-11-13 23:46:24 +02:00
|
|
|
|
2015-04-14 14:50:41 +02:00
|
|
|
|
2020-07-23 14:01:52 +04:00
|
|
|
|
2015-04-14 14:50:41 +02:00
|
|
|
|
2015-04-10 14:10:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-13 07:34:15 +01:00
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2021-11-13 07:34:15 +01:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-22 11:52:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-07-07 15:45:48 -05:00
|
|
|
|
2016-11-22 11:52:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:07 +03:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-14 20:08:15 +01:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-09-20 21:25:18 +03:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:10 +02:00
|
|
|
|
2014-11-09 18:50:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-26 14:39:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-22 11:52:18 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2025-03-25 14:31:25 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
2016-11-22 11:52:18 +01:00
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2016-11-22 11:52:18 +01:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:07 +02:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2022-05-26 21:35:32 +08:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2020-09-08 14:36:50 +02:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:50 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:49 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-26 21:35:32 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-06-17 18:31:11 +02:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:51 +02:00
|
|
|
|
2020-09-08 14:36:50 +02:00
|
|
|
|
2020-09-08 14:36:51 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:50 +02:00
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-05-21 00:34:29 +02:00
|
|
|
|
2023-08-28 15:09:24 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-13 07:34:15 +01:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:51 +02:00
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
2022-09-20 17:55:41 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
|
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
|
|
|
|
|
2020-12-18 19:47:16 +01:00
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2020-12-18 19:47:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2020-12-18 19:47:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-10-10 11:43:38 +02:00
|
|
|
|
2020-12-18 19:47:16 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-08 14:36:53 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
2014-11-09 18:50:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-03-21 09:13:45 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-21 10:56:48 +02:00
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-17 00:57:14 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2012-11-10 03:44:14 +01:00
|
|
|
|
2009-03-23 17:28:35 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-11-10 03:44:14 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2011-02-24 14:42:06 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-02-24 14:42:06 +01:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2009-07-14 00:33:34 +02:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2020-07-23 14:01:52 +04:00
|
|
|
|
2020-09-08 14:36:57 +02:00
|
|
|
|
2019-11-25 11:04:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-11-13 07:34:15 +01:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2011-11-16 15:28:55 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2009-11-25 17:46:18 +01:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2021-11-13 07:34:15 +01:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-17 00:57:14 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2008-05-17 00:57:14 +02:00
|
|
|
|
2020-11-03 14:48:18 +05:30
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2020-11-03 14:48:18 +05:30
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:37 +01:00
|
|
|
|
2009-03-23 17:28:41 +01:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-03-23 17:28:36 +01:00
|
|
|
|
2009-03-23 17:28:37 +01:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2009-03-12 23:49:28 +01:00
|
|
|
|
2009-03-23 17:28:37 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2009-03-23 17:28:37 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-17 00:57:14 +02:00
|
|
|
|
2009-03-23 17:28:37 +01:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2009-07-14 00:33:34 +02:00
|
|
|
|
|
|
|
|
|
2009-07-27 10:33:31 +02:00
|
|
|
|
2012-10-08 14:39:33 +02:00
|
|
|
|
2009-07-27 10:33:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:37 +01:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-03-23 17:28:37 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2009-03-23 17:28:37 +01:00
|
|
|
|
2009-03-23 17:28:36 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-07 16:04:50 +01:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2013-12-18 15:44:16 +08:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
2011-01-31 20:48:44 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-11-07 11:16:02 +13:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2025-07-25 23:22:19 +10:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2013-01-07 16:04:50 +01:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2013-01-07 16:04:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2013-01-07 16:04:50 +01:00
|
|
|
|
2013-02-22 12:55:01 +01:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2013-02-22 12:55:01 +01:00
|
|
|
|
2013-01-07 16:04:50 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2013-08-28 13:41:31 +02:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
2014-05-09 14:11:47 +03:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2013-08-28 13:41:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-17 15:55:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-28 13:41:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2014-05-09 14:11:47 +03:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2014-05-09 14:11:47 +03:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
2014-05-09 14:11:47 +03:00
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
2021-07-02 19:44:08 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:47 +03:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
|
|
|
|
|
2025-06-17 10:49:01 +02:00
|
|
|
|
|
|
|
|
|
2015-06-10 13:06:53 +02:00
|
|
|
|
2025-06-17 10:49:01 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-10 13:06:53 +02:00
|
|
|
|
2025-06-17 10:49:01 +02:00
|
|
|
|
2015-06-10 13:06:53 +02:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2015-06-10 13:06:53 +02:00
|
|
|
|
|
|
|
|
|
2024-01-30 19:39:15 +05:30
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
|
|
|
|
|
2024-01-30 19:39:15 +05:30
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2024-01-30 19:39:15 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
|
|
|
|
|
2024-01-30 19:39:15 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
2024-01-30 19:39:15 +05:30
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-17 10:49:01 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-16 15:00:15 +02:00
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
|
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2018-04-20 13:49:24 +03:00
|
|
|
|
2024-02-16 20:16:20 +05:30
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
2024-02-16 20:16:20 +05:30
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-02-16 20:16:20 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2024-02-16 20:16:20 +05:30
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2024-02-16 20:16:20 +05:30
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-28 13:41:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-10-17 15:55:02 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-08-28 13:41:31 +02:00
|
|
|
|
|
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2014-06-05 14:21:37 +02:00
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2013-07-11 16:09:06 +02:00
|
|
|
|
2020-02-22 15:25:46 +02:00
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2020-02-22 15:25:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-20 10:20:23 +01:00
|
|
|
|
2020-02-22 15:25:46 +02:00
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2020-02-22 15:25:46 +02:00
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:16 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-01 12:09:17 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-22 15:25:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-20 10:20:23 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-02-22 15:25:46 +02:00
|
|
|
|
2020-03-20 10:20:23 +01:00
|
|
|
|
2020-02-22 15:25:46 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-08-23 12:36:37 +02:00
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
|
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-23 04:38:01 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
2025-07-17 17:42:05 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-01-30 19:39:15 +05:30
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
2023-03-23 04:38:01 -07:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
2022-02-24 12:54:58 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-08-05 17:20:35 +03:00
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
2024-08-05 17:20:35 +03:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-17 17:42:05 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
treewide: Replace kmalloc with kmalloc_obj for non-scalar types
This is the result of running the Coccinelle script from
scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to
avoid scalar types (which need careful case-by-case checking), and
instead replace kmalloc-family calls that allocate struct or union
object instances:
Single allocations: kmalloc(sizeof(TYPE), ...)
are replaced with: kmalloc_obj(TYPE, ...)
Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...)
are replaced with: kmalloc_objs(TYPE, COUNT, ...)
Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...)
are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...)
(where TYPE may also be *VAR)
The resulting allocations no longer return "void *", instead returning
"TYPE *".
Signed-off-by: Kees Cook <kees@kernel.org>
2026-02-20 23:49:23 -08:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-17 17:42:05 +10:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
2008-07-09 14:40:37 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2025-07-17 17:42:05 +10:00
|
|
|
|
2008-01-24 19:38:38 +01:00
|
|
|
|
2007-12-19 02:03:33 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2011-01-24 19:28:49 +01:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
2008-09-11 00:01:58 +02:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
2008-07-09 14:40:37 +02:00
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
2025-07-17 17:42:05 +10:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-17 17:42:05 +10:00
|
|
|
|
|
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
2008-09-11 00:01:58 +02:00
|
|
|
|
2009-02-15 12:44:28 +01:00
|
|
|
|
2008-07-09 14:40:37 +02:00
|
|
|
|
2008-02-23 15:17:19 +01:00
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
|
|
|
|
|
2008-07-09 14:40:37 +02:00
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2025-06-17 10:49:01 +02:00
|
|
|
|
2013-08-28 13:41:31 +02:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2013-08-28 13:41:31 +02:00
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
2013-12-14 13:54:53 +01:00
|
|
|
|
2008-07-09 14:40:37 +02:00
|
|
|
|
|
|
|
|
|
2013-03-07 20:54:29 +01:00
|
|
|
|
networking: introduce and use skb_put_data()
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:20 +02:00
|
|
|
|
2008-07-09 14:40:37 +02:00
|
|
|
|
|
|
|
|
|
2008-07-15 18:44:13 -07:00
|
|
|
|
|
|
|
|
|
2021-10-05 21:09:36 -07:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
|
|
|
|
|
2008-02-23 15:17:19 +01:00
|
|
|
|
2012-03-31 11:31:32 -07:00
|
|
|
|
2008-09-11 00:01:49 +02:00
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
|
|
|
|
|
2011-01-18 13:45:32 +01:00
|
|
|
|
|
|
|
|
|
2020-08-11 10:01:04 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-06-17 10:49:01 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2014-05-09 14:11:50 +03:00
|
|
|
|
2013-10-17 15:55:02 -07:00
|
|
|
|
2012-03-31 11:31:32 -07:00
|
|
|
|
2016-12-08 10:15:51 +09:00
|
|
|
|
2012-03-31 11:31:32 -07:00
|
|
|
|
2011-10-26 14:47:25 -07:00
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
2013-01-30 18:14:08 +01:00
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
2013-12-14 13:54:53 +01:00
|
|
|
|
2008-02-23 15:17:10 +01:00
|
|
|
|
|
|
|
|
|
2013-02-14 11:20:13 -08:00
|
|
|
|
networking: introduce and use skb_put_data()
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:20 +02:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
2014-06-05 14:21:36 +02:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
networking: introduce and use skb_put_data()
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:20 +02:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
|
|
|
|
|
2008-07-09 14:40:37 +02:00
|
|
|
|
|
|
|
|
|
2007-12-19 02:03:33 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-10-21 12:40:02 +02:00
|
|
|
|
2007-12-19 02:03:33 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-05-31 11:50:12 +05:30
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
2022-06-06 14:25:54 +03:00
|
|
|
|
2022-12-05 16:50:37 -08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 09:46:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-09-09 09:46:32 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-04 12:13:52 +01:00
|
|
|
|
2015-09-09 09:46:32 +02:00
|
|
|
|
2014-05-09 14:11:49 +03:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2009-10-29 08:30:35 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-06 14:26:16 +03:00
|
|
|
|
|
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-16 15:00:15 +02:00
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-08-06 14:26:16 +03:00
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
networking: introduce and use skb_put_data()
A common pattern with skb_put() is to just want to memcpy()
some data into the new space, introduce skb_put_data() for
this.
An spatch similar to the one for skb_put_zero() converts many
of the places using it:
@@
identifier p, p2;
expression len, skb, data;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_data(skb, data, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_data(skb, data, len);
)
(
p2 = (t2)p;
-memcpy(p2, data, len);
|
-memcpy(p, data, len);
)
@@
type t, t2;
identifier p, p2;
expression skb, data;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_data(skb, data, sizeof(t));
)
(
p2 = (t2)p;
-memcpy(p2, data, sizeof(*p));
|
-memcpy(p, data, sizeof(*p));
)
@@
expression skb, len, data;
@@
-memcpy(skb_put(skb, len), data, len);
+skb_put_data(skb, data, len);
(again, manually post-processed to retain some comments)
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:20 +02:00
|
|
|
|
2012-08-06 14:26:16 +03:00
|
|
|
|
2011-11-10 11:28:57 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-16 15:00:15 +02:00
|
|
|
|
2020-09-11 00:05:31 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-09-11 00:33:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-16 15:00:15 +02:00
|
|
|
|
2020-09-11 00:33:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2011-08-29 14:17:31 -07:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
2011-08-29 14:17:31 -07:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
networking: convert many more places to skb_put_zero()
There were many places that my previous spatch didn't find,
as pointed out by yuan linyu in various patches.
The following spatch found many more and also removes the
now unnecessary casts:
@@
identifier p, p2;
expression len;
expression skb;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_zero(skb, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_zero(skb, len);
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, len);
|
-memset(p, 0, len);
)
@@
type t, t2;
identifier p, p2;
expression skb;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, sizeof(*p));
|
-memset(p, 0, sizeof(*p));
)
@@
expression skb, len;
@@
-memset(skb_put(skb, len), 0, len);
+skb_put_zero(skb, len);
Apply it to the tree (with one manual fixup to keep the
comment in vxlan.c, which spatch removed.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:19 +02:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: move interface config to new struct
We'll use bss_conf for per-link configuration later, so
move out all the non-link-specific data out into a new
struct ieee80211_vif_cfg used in the vif.
Some adjustments were done with the following spatch:
@@
expression sdata;
struct ieee80211_vif *vifp;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
(
-sdata->vif.bss_conf.var
+sdata->vif.cfg.var
|
-vifp->bss_conf.var
+vifp->cfg.var
)
@bss_conf@
struct ieee80211_bss_conf *bss_conf;
identifier var = { assoc, ibss_joined, aid, arp_addr_list, arp_addr_cnt, ssid, ssid_len, s1g, ibss_creator };
@@
-bss_conf->var
+vif_cfg->var
(though more manual fixups were needed, e.g. replacing
"vif_cfg->" by "vif->cfg." in many files.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 17:05:04 +02:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-05-16 15:00:15 +02:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
2022-09-02 16:12:47 +02:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
2022-09-02 16:12:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
|
|
|
|
|
2011-08-29 14:17:31 -07:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
2011-08-29 14:17:31 -07:00
|
|
|
|
2022-09-02 16:12:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
networking: convert many more places to skb_put_zero()
There were many places that my previous spatch didn't find,
as pointed out by yuan linyu in various patches.
The following spatch found many more and also removes the
now unnecessary casts:
@@
identifier p, p2;
expression len;
expression skb;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_zero(skb, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_zero(skb, len);
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, len);
|
-memset(p, 0, len);
)
@@
type t, t2;
identifier p, p2;
expression skb;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, sizeof(*p));
|
-memset(p, 0, sizeof(*p));
)
@@
expression skb, len;
@@
-memset(skb_put(skb, len), 0, len);
+skb_put_zero(skb, len);
Apply it to the tree (with one manual fixup to keep the
comment in vxlan.c, which spatch removed.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:19 +02:00
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
2018-11-09 11:16:46 +01:00
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-11-09 11:16:46 +01:00
|
|
|
|
2017-11-21 14:46:08 +01:00
|
|
|
|
|
|
|
|
|
2022-09-02 16:12:47 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:19 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
2014-06-12 22:24:31 +02:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
2012-11-29 13:00:10 +01:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
2014-06-12 22:24:31 +02:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-11-29 13:00:10 +01:00
|
|
|
|
2011-08-29 14:17:31 -07:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
networking: convert many more places to skb_put_zero()
There were many places that my previous spatch didn't find,
as pointed out by yuan linyu in various patches.
The following spatch found many more and also removes the
now unnecessary casts:
@@
identifier p, p2;
expression len;
expression skb;
type t, t2;
@@
(
-p = skb_put(skb, len);
+p = skb_put_zero(skb, len);
|
-p = (t)skb_put(skb, len);
+p = skb_put_zero(skb, len);
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, len);
|
-memset(p, 0, len);
)
@@
type t, t2;
identifier p, p2;
expression skb;
@@
t *p;
...
(
-p = skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
|
-p = (t *)skb_put(skb, sizeof(t));
+p = skb_put_zero(skb, sizeof(t));
)
... when != p
(
p2 = (t2)p;
-memset(p2, 0, sizeof(*p));
|
-memset(p, 0, sizeof(*p));
)
@@
expression skb, len;
@@
-memset(skb_put(skb, len), 0, len);
+skb_put_zero(skb, len);
Apply it to the tree (with one manual fixup to keep the
comment in vxlan.c, which spatch removed.)
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 14:29:19 +02:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
2012-07-13 16:23:07 +02:00
|
|
|
|
2014-06-12 22:24:31 +02:00
|
|
|
|
2012-07-13 16:23:07 +02:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-03-29 16:30:41 +02:00
|
|
|
|
2010-01-05 20:16:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-06-22 16:45:27 -07:00
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
|
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2008-05-27 17:50:51 +03:00
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2007-12-19 01:31:26 +01:00
|
|
|
|
2007-12-19 02:03:33 +01:00
|
|
|
|
|
|
|
|
|
wifi: mac80211: move some future per-link data to bss_conf
To add MLD, reuse the bss_conf structure later for per-link
information, so move some things into it that are per link.
Most transformations were done with the following spatch:
@@
expression sdata;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-sdata->vif.var
+sdata->vif.bss_conf.var
@@
struct ieee80211_vif *vif;
identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color };
@@
-vif->var
+vif->bss_conf.var
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2022-05-10 13:26:44 +02:00
|
|
|
|
2007-12-19 02:03:33 +01:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2008-05-27 17:50:51 +03:00
|
|
|
|
2007-12-19 02:03:33 +01:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
|
|
|
|
|
2022-05-16 15:00:15 +02:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2013-01-30 18:14:08 +01:00
|
|
|
|
|
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-05-27 17:50:51 +03:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-27 17:50:51 +03:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
2012-10-10 12:39:50 -07:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-03-06 15:08:43 +01:00
|
|
|
|
2013-03-01 16:01:18 +01:00
|
|
|
|
2015-03-20 14:18:27 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2016-08-02 11:13:41 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-05-15 12:55:29 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2008-02-25 16:27:43 +01:00
|
|
|
|
2012-11-09 11:39:59 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
2008-06-20 01:22:30 +02:00
|
|
|
|
2008-02-25 16:27:46 +01:00
|
|
|
|
2007-07-27 15:43:22 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2014-11-19 13:47:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-28 14:00:01 +02:00
|
|
|
|
2014-11-19 13:47:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2014-11-19 13:47:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-01-07 15:42:39 +02:00
|
|
|
|
2014-11-19 13:47:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2015-06-02 21:39:54 +02:00
|
|
|
|
2014-11-19 13:47:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-28 14:00:01 +02:00
|
|
|
|
2014-11-19 13:47:38 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2012-07-26 17:24:39 +02:00
|
|
|
|
2022-07-18 21:36:08 +02:00
|
|
|
|
2020-07-23 14:01:52 +04:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
2017-01-24 16:42:10 +01:00
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
2016-03-03 01:16:56 +00:00
|
|
|
|
2012-04-03 16:28:50 +02:00
|
|
|
|
2011-12-15 10:18:34 +01:00
|
|
|
|
2010-01-05 18:00:58 +01:00
|
|
|
|
2013-02-13 15:39:57 +01:00
|
|
|
|
|
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:08 +03:00
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
2022-07-18 21:36:08 +02:00
|
|
|
|
|
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
|
|
|
|
|
2022-06-17 22:36:37 +02:00
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
|
|
|
|
|
2023-06-08 16:36:07 +03:00
|
|
|
|
2022-06-09 22:05:07 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-06-18 17:25:11 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2014-11-09 18:50:09 +02:00
|
|
|
|
2020-07-23 14:01:52 +04:00
|
|
|
|
2009-06-18 17:25:11 +02:00
|
|
|
|
2009-06-17 17:43:56 +02:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
2022-07-18 21:36:08 +02:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-09-08 14:13:02 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-18 21:36:08 +02:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-18 21:36:08 +02:00
|
|
|
|
2023-06-08 16:36:07 +03:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-18 21:36:08 +02:00
|
|
|
|
2022-06-01 15:59:31 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
2020-05-08 16:42:00 +02:00
|
|
|
|
2022-06-30 15:27:59 +03:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
2020-03-26 15:53:34 +01:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
2022-07-19 09:37:59 +02:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
2023-08-28 14:00:05 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-03-26 15:53:34 +01:00
|
|
|
|
2020-06-17 10:26:36 +02:00
|
|
|
|
|
|
|
|
|
2020-03-26 15:53:34 +01:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-30 15:27:59 +03:00
|
|
|
|
2022-07-19 10:26:50 +02:00
|
|
|
|
2022-06-30 15:27:59 +03:00
|
|
|
|
2022-07-19 10:26:50 +02:00
|
|
|
|
|
|
|
|
|
2022-06-30 15:27:59 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-19 10:26:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-06-30 15:27:59 +03:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-18 21:20:52 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
2024-09-13 11:49:19 +03:00
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-19 09:37:59 +02:00
|
|
|
|
|
|
|
|
|
2022-08-18 12:33:49 +08:00
|
|
|
|
2022-07-19 09:37:59 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
2022-07-19 09:37:59 +02:00
|
|
|
|
2022-10-09 18:30:40 +02:00
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
|
|
|
|
|
2022-07-19 10:26:50 +02:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-07-28 17:25:16 +03:00
|
|
|
|
2022-07-19 10:26:50 +02:00
|
|
|
|
2021-02-06 12:51:12 +01:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-09-18 21:20:52 +02:00
|
|
|
|
2018-06-19 10:39:50 -05:00
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
2018-06-19 10:39:50 -05:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2019-04-11 13:47:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2020-05-27 18:03:34 +02:00
|
|
|
|
|
|
|
|
|
2018-06-19 10:39:50 -05:00
|
|
|
|
2018-03-26 12:52:50 -05:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
