Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 11 12月, 2020 3 次提交
  3. 06 11月, 2020 2 次提交
  5. 30 10月, 2020 1 次提交
  7. 08 10月, 2020 1 次提交
  9. 28 9月, 2020 3 次提交
  11. 18 9月, 2020 8 次提交
  13. 27 8月, 2020 1 次提交
  15. 31 7月, 2020 4 次提交
  17. 31 5月, 2020 1 次提交
  19. 27 5月, 2020 1 次提交
    • G
      mac80211: Replace zero-length array with flexible-array · 3c23215b
      由 Gustavo A. R. Silva 提交于 
      The current codebase makes use of the zero-length array language
extension to the C90 standard, but the preferred mechanism to declare
variable-length types such as these ones is a flexible array member[1][2],
introduced in C99:

struct foo {
        int stuff;
        struct boo array[];
};

By making use of the mechanism above, we will get a compiler warning
in case the flexible array does not occur last in the structure, which
will help us prevent some kind of undefined behavior bugs from being
inadvertently introduced[3] to the codebase from now on.

Also, notice that, dynamic memory allocations won't be affected by
this change:

"Flexible array members have incomplete type, and so the sizeof operator
may not be applied. As a quirk of the original implementation of
zero-length arrays, sizeof evaluates to zero."[1]

sizeof(flexible-array-member) triggers a warning because flexible array
members have incomplete type[1]. There are some instances of code in
which the sizeof operator is being incorrectly/erroneously applied to
zero-length arrays and the result is zero. Such instances may be hiding
some bugs. So, this work (flexible-array member conversions) will also
help to get completely rid of those sorts of issues.

This issue was found with the help of Coccinelle.

[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732 ("cxgb3/l2t: Fix undefined behaviour")
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
Link: https://lore.kernel.org/r/20200507185907.GA15102@embeddedorSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      3c23215b
  21. 29 4月, 2020 1 次提交
  23. 24 4月, 2020 7 次提交
  25. 20 3月, 2020 1 次提交
  27. 24 2月, 2020 1 次提交
  29. 14 2月, 2020 1 次提交
    • B
      mac80211: Fix setting txpower to zero · db6d9e9e
      由 Ben Greear 提交于 
      With multiple VIFS ath10k, and probably others, tries to find the
minimum txpower for all vifs and uses that when setting txpower in
the firmware.

If a second vif is added and starts to scan, it's txpower is not
initialized yet and it set to zero.

ath10k had a patch to ignore zero values, but then it is impossible
to actually set txpower to zero.

So, instead initialize the txpower to INT_MIN in mac80211, and let
drivers know that means the power has not been set and so should
be ignored.

This should fix regression in:

commit 88407beb
Author: Ryan Hsu <ryanhsu@qca.qualcomm.com>
Date:   Tue Dec 13 14:55:19 2016 -0800

    ath10k: fix incorrect txpower set by P2P_DEVICE interface

Tested on ath10k 9984 with ath10k-ct firmware.
Signed-off-by: NBen Greear <greearb@candelatech.com>
Link: https://lore.kernel.org/r/20191217183057.24586-1-greearb@candelatech.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      db6d9e9e
  31. 07 2月, 2020 1 次提交
  33. 15 1月, 2020 1 次提交
  35. 14 12月, 2019 1 次提交
  37. 22 11月, 2019 1 次提交
    • T
      mac80211: Use Airtime-based Queue Limits (AQL) on packet dequeue · 7a89233a
      由 Toke Høiland-Jørgensen 提交于 
      The previous commit added the ability to throttle stations when they queue
too much airtime in the hardware. This commit enables the functionality by
calculating the expected airtime usage of each packet that is dequeued from
the TXQs in mac80211, and accounting that as pending airtime.

The estimated airtime for each skb is stored in the tx_info, so we can
subtract the same amount from the running total when the skb is freed or
recycled. The throttling mechanism relies on this accounting to be
accurate (i.e., that we are not freeing skbs without subtracting any
airtime they were accounted for), so we put the subtraction into
ieee80211_report_used_skb(). As an optimisation, we also subtract the
airtime on regular TX completion, zeroing out the value stored in the
packet afterwards, to avoid having to do an expensive lookup of the station
from the packet data on every packet.

This patch does *not* include any mechanism to wake a throttled TXQ again,
on the assumption that this will happen anyway as a side effect of whatever
freed the skb (most commonly a TX completion).
Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20191119060610.76681-5-kyan@google.comSigned-off-by: NJohannes Berg <johannes.berg@intel.com>
      7a89233a