The bacam_v1 must do additional initialization, and H2C content of BA CAM
is also different. So, correct them accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220816013247.6243-3-pkshih@realtek.com
8852A has 2 BA CAM entries, but 8852C has 8 entries. Add a field to
discriminate their differences.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220816013247.6243-2-pkshih@realtek.com
TX power byrate:
doesn't change
TX power limit:
configure values for KCC and UK
refine a bit configuration vales
TX power limit_ru:
configure values for KCC and UK
refine a bit configuration values
change 6GHz to follow indoor setting
configure 6GHz values for ETSI
TX power shape:
change with TX power limit/limit_ru
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220812093116.56791-4-pkshih@realtek.com
Some chips' RF TX power limit/limit_ru tables start to configure some
negative values. Fix the setting logic to prevent negative values from
polluting fields of others.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220812093116.56791-2-pkshih@realtek.com
Because RTL8852c firmware handshake use different structure definition
with RTL8852a, so it's necessary to update a version for RTL8852c.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-10-pkshih@realtek.com
Because the later firmware had patched some new feature, it can control
the Wi-Fi/BT slots more efficiently. This patch enhance it for better
Wi-Fi SCC mode performance.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-9-pkshih@realtek.com
Due to the difference of Wi-Fi firmware supported feature, RTL8852C
need to defined more policy to enable the features.
(Ex: DBCC, Wi-Fi multi-role, TDMA instant and so on)
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-8-pkshih@realtek.com
The H2C format and support feature are different. The newer Wi-Fi firmware
and driver branch need to handshake more information like DBCC or P2P
connection info.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-7-pkshih@realtek.com
RTL8852C use a later version Wi-Fi firmware, there are some parameters
need to be defined. These new parameter can avoid some unexpected
TDMA mode while Wi-Fi enter/leave lps.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-6-pkshih@realtek.com
It is for setting up BT slot max length at BT auto slot mechanism.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-5-pkshih@realtek.com
Add a part of logic to parse type of ctrl report from firmware, and
remove Bluetooth packet counter count from driver, the feature was
moved to firmware at rtl8852c.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-4-pkshih@realtek.com
To configure the different chips with different coexistence version,
separated the firmware feature version matching number is necessary.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-3-pkshih@realtek.com
Update scoreboard setting to let Bluetooth know Wi-Fi power save state.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220725023509.43114-2-pkshih@realtek.com
mac_txen time is to inform TMAC tx after rx air end.
Modify 8852c value to meet TB SIFS time.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220704023453.19935-7-pkshih@realtek.com
Prebkf time is to inform generating tx command if remaining backoff
time less than this setting value.
It might cause SER if generating tx command early in security mode.
Signed-off-by: Chia-Yuan Li <leo.li@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220704023453.19935-6-pkshih@realtek.com
Calling rtw89_leave_lps() should hold rtwdev::mutex.
So, fix it.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220704023453.19935-5-pkshih@realtek.com
Sometimes, BB might encounter RX problem on OFDM 6M. It's not quite
easy to happen, but if it happens, we will keep getting stuck on RX.
And, since we cannot properly receive layer 2 ACK, it also casues TX
problem, e.g. constantly retrying TX. Eventually, after some time, we
would get disconnected due to abnormal behavior.
Update break setting and phy status parsing time to make BB get out
of stuck state faster.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220704023453.19935-3-pkshih@realtek.com
Without this patch, our hardware attempts to perform dma while device
cpu restarts, and leads to iommu page faults caused by invalid requests.
Some platforms show warning messages as below:
rtw89_8852ce 0000:01:00.0: AMD-Vi: Event logged [IO_PAGE_FAULT
domain=0x000a address=0x10000000004 flags=0x0030]
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220704023453.19935-2-pkshih@realtek.com
In current flow, FW is asynchronously loaded after alloc_hw(). It defers
the decision on FW feature map. It makes things difficult for us to decide
whether to hook chanctx ops, which should be decided while alloc_hw() is
calling. Still, asynchronous gets its advantages. So, we want to resolve
this without dropping them.
Based on multi-FW flag, RTW89_MFW_SIG, we can determine runtime FW is
multi-FW (MFW) or single FW (SFW). Both of them have a quite small chunk
for header at the head. The difference is that MFW doesn't describe version
code in its header while SFW does. So, we plan to extend MFW header for
version code. After that, in both cases, we can determine FW feature map by
just FW header. And, according to the map, we can decide chanctx.
So, we call request_partial_firmware_into_buf() to request a quite small
chunk before alloc_hw() to get a early FW feature map without affecting
things much and only use early map to decide whether to hook chanctx ops.
It means that if non-extended MFW is used at runtime, driver just acts
without chanctx as before. If extended MFW or SFW, which supports required
FW features, is used at runtime, driver can hook chanctx ops to mac80211 if
chip has configured support_chanctx_num > 0.
Besides, key point for now to support single one chanctx is whether HW scan
is supported at runtime. So, we configure all chip's support_chanctx_num to
1, and check if HW scan is supported at runtime via early FW feature map.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-14-pkshih@realtek.com
Some HW features are required if we hook chanctx ops to mac80211. With it,
mac80211 would expect the HW-supported variant ops exists on some behavior,
e.g. HW scan. But, HW features may depend on chip's FW or its development.
Besides, how many chanctx can be supported also depends on chip design.
We can neither decide whether to generally support chanctx ops nor how many
chanctx can be supported.
So, support_chanctx_num is added under chip info to deal with this by chip.
For now, all chip configure support_chanctx_num as 0. We haven't really
hook chanctx ops yet. So, chip can run without mac80211 chanctx as before.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-13-pkshih@realtek.com
Support mac80211 chanctx series ops. Still, currently support
single channel. Based on this premise, things should be similar
to before. So, we haven't dealt with relationship between vif
and chanctx in depth. Instead, we leave both ::assign_vif()
and ::unassign_vif() as noops for now.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-12-pkshih@realtek.com
After supporting more than one channel, we need entity mode to decide
how to set current channel(s) on the sub-entities. This decision may
happen on set_channel() and rtw89_core_set_chip_txpwr().
For now, we support single one channel and use only first HW entry,
i.e. RTW89_SUB_ENTITY_0, RTW89_MAC_0, RTW89_PHY_0. Without something
unexpected, the entity mode should always be RTW89_ENT_MODE_SCC after
recalcated, where SCC means single channel concurrency. So, an assert
is added in set_channel() and rtw89_core_set_chip_txpwr().
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-11-pkshih@realtek.com
While idle, we need a default chandef to set channel for things,
such as scan. Before support of mac80211 chanctx, mac80211 would
configure a default one on ieee80211_hw::conf::chandef. And we
just queried it whenever we did set channel. However, after support
of mac80211 chanctx, the flow won't work like before.
Besides, we don't now query chandef from ieee80211_hw::conf::chandef
either. So, similar to mac80211 without using chanctx, we configure
the default chandef with ieee80211_channel of index 0 in 2GHz.
Although we have not added the support of mac80211 chanctx here,
this configuration should be compatible before that. So, we commit
this ahead.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-10-pkshih@realtek.com
Originally, we didn't support mac80211 chanctx, so it's expected that
ieee80211_hw::conf::chandef would be filled by mac80211. And then, we
could just query it whenever we need the current chandef.
However, we are planing to support mac80211 chanctx. After that, the
above assumption would be broken. So, we adjust a bit ahead to reduce
future works about mac80211 chanctx.
After this, we don't query ieee80211_hw::conf::chandef directly, and
we add a map, entity_map, to HAL to indicate which chandef came from
stack. And it will later be used to recalcate entity mode.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-9-pkshih@realtek.com
For future support on multiple channels by multiple sub-entities,
we need to manage parameters of each channel instance like rtw89_chan,
rtw89_mac_idx, rtw89_phy_idx. So, we adjust related channel callback
functions and centrally conrtol these parameters in set_channel().
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-8-pkshih@realtek.com
For future support on multiple channels, there will be settings of
multiple sub-entities that we need to control. We don't want such
settings to be scattered all over the place. So, we centrally manage
controls of rtw89_phy_idx for RFK in set_channel().
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-7-pkshih@realtek.com
For future support on multiple channels, it would be disturbing if we
still allow scattered leaf functions of TX power to query and manage
channel related control by themselves.
So, query rtw89_chan only on top functions. Then, pass it via functions
to make sure that the values coming from the same struct rtw89_chan.
Besides, fix rtw8852a_set_txpwr_offset() from rtw8852a_set_txpwr_ctrl()
to rtw8852a_set_txpwr(). TX power offset should consider current band,
so move it to chip_ops::set_txpwr() which will be called every time that
channel is set.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-6-pkshih@realtek.com
Sometimes we need to write current rtw89_chan outside set_channel(),
e.g. during HW scan, we adjust it to align FW process through C2H.
However, we don't have full parameters to fill entire rtw89_chan.
And it will breakage if we update only part of current rtw89_chan.
That is what we don't want to see because most flows throughout
driver treat rtw89_chan as a whole.
So, we divide struct rtw89_chan to basic part and derived part. The
basic part contains the parameters which we are always able to know.
And the derived part will be calculated by the basic part. Then, a
central function, rtw89_chan_create(), is added to deal with this.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-5-pkshih@realtek.com
We are planning to support mac80211 chanctx. To reduce future works,
the driver architecture is adjusted first to isolate related things.
According to chip, our HW may have multiple sub-entities to support
multiple mac80211 chanctx. Struct rtw89_chan has been introduced for
things about channel/band/subband/... Now introduce struct rtw89_chan_rcd
to record difference after assigning new one of struct rtw89_chan.
We will implement and support chanctx with single channel first, i.e.
only use entry in RTW89_SUB_ENTITY_0, before handling dual channels.
Our hierarchy in planning will become as the following.
DEV
-> HAL
---> entity (manage status across sub-entities)
-----> sub-entity[*] (support mac80211 chanctx)
where each sub-entity contains one struct rtw89_chan.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-4-pkshih@realtek.com
Introduce struct rtw89_chan ahead to encapsulate stuffs from struct
rtw89_channel_params. These stuffs have a clone in HAL and are used
throughout driver. After multiple channels support, it's expected that
each channel instance has a configuration of them. So, we refine them
with struct rtw89_chan by precise type first, and will re-arrange HAL
by struct rtw89_chan in the following as well.
(No logic has changed.)
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-3-pkshih@realtek.com
We need to invoke the callback of the changed band at the first
set_channel() after every power-off. Originally, we forced the
channel to be 0 when doing power-off, and then determined things
by comparing channel with 0.
However, deciding on such things by channel might be confusing.
It's also confusing to use this kind of decision when we consider
multiple channels in the follow-up patches. So, another flag,
entity_active, is added ahead to HAL to deal with this.
Besides, we also need to check if entity is active when we set
TX power.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220809104952.61355-2-pkshih@realtek.com
This is a followup of commit c67b85558f ("ipv6: tcp: send consistent
autoflowlabel in TIME_WAIT state"), but for SYN_RECV state.
In some cases, TCP sends a challenge ACK on behalf of a SYN_RECV request.
WHen this happens, we want to use the flow label that was used when
the prior SYNACK packet was sent, instead of another one.
After his patch, following packetdrill passes:
0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3
+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
+0 bind(3, ..., ...) = 0
+0 listen(3, 1) = 0
+.2 < S 0:0(0) win 32792 <mss 1000,sackOK,nop,nop,nop,wscale 7>
+0 > (flowlabel 0x11) S. 0:0(0) ack 1 <...>
// Test if a challenge ack is properly sent (same flowlabel than prior SYNACK)
+.01 < . 4000000000:4000000000(0) ack 1 win 320
+0 > (flowlabel 0x11) . 1:1(0) ack 1
Signed-off-by: Eric Dumazet <edumazet@google.com>
Link: https://lore.kernel.org/r/20220831203729.458000-1-eric.dumazet@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This has been validated on the Ocelot/Felix switch family (NXP LS1028A)
and should be relevant to any switch driver that offloads the tc-flower
and/or tc-matchall actions trap, drop, accept, mirred, for which DSA has
operations.
TEST: gact drop and ok (skip_hw) [ OK ]
TEST: mirred egress flower redirect (skip_hw) [ OK ]
TEST: mirred egress flower mirror (skip_hw) [ OK ]
TEST: mirred egress matchall mirror (skip_hw) [ OK ]
TEST: mirred_egress_to_ingress (skip_hw) [ OK ]
TEST: gact drop and ok (skip_sw) [ OK ]
TEST: mirred egress flower redirect (skip_sw) [ OK ]
TEST: mirred egress flower mirror (skip_sw) [ OK ]
TEST: mirred egress matchall mirror (skip_sw) [ OK ]
TEST: trap (skip_sw) [ OK ]
TEST: mirred_egress_to_ingress (skip_sw) [ OK ]
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20220831170839.931184-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Return value directly from nsim_dev_reload_create()
instead of getting value from redundant variable ret.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Jinpeng Cui <cui.jinpeng2@zte.com.cn>
Link: https://lore.kernel.org/r/20220831154329.305372-1-cui.jinpeng2@zte.com.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The open code is defined as a new helper function(netif_oper_up) on netdev.h,
the code is dev->operstate == IF_OPER_UP || dev->operstate == IF_OPER_UNKNOWN.
Thus, replace the open code to netif_oper_up. This patch doesn't change logic.
Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Link: https://lore.kernel.org/r/20220831125845.1333-1-claudiajkang@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
etf_enable_offload() is only called when q->offload is false in
etf_init(). So remove true check in etf_enable_offload().
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Acked-by: Vinicius Costa Gomes <vinicius.gomes@intel.com>
Link: https://lore.kernel.org/r/20220831092919.146149-1-shaozhengchao@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When CONFIG_SECURITY_NETWORK is disabled, there will be build warnings
from resolve_btfids:
WARN: resolve_btfids: unresolved symbol bpf_lsm_socket_socketpair
......
WARN: resolve_btfids: unresolved symbol bpf_lsm_inet_conn_established
Fixing it by wrapping these BTF ID definitions by CONFIG_SECURITY_NETWORK.
Fixes: 69fd337a97 ("bpf: per-cgroup lsm flavor")
Fixes: 9113d7e48e ("bpf: expose bpf_{g,s}etsockopt to lsm cgroup")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Link: https://lore.kernel.org/r/20220901065126.3856297-1-houtao@huaweicloud.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
The assignment of the else and else if branches is the same, so the else
if here is redundant, so we remove it and add a comment to make the code
here readable.
./kernel/bpf/cgroup_iter.c:81:6-8: WARNING: possible condition with no effect (if == else).
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=2016
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220831021618.86770-1-jiapeng.chong@linux.alibaba.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Hou Tao says:
====================
From: Hou Tao <houtao1@huawei.com>
Hi,
The patchset aims to make the update of per-cpu prog->active and per-cpu
bpf_task_storage_busy being preemption-safe. The problem is on same
architectures (e.g. arm64), __this_cpu_{inc|dec|inc_return} are neither
preemption-safe nor IRQ-safe, so under fully preemptible kernel the
concurrent updates on these per-cpu variables may be interleaved and the
final values of these variables may be not zero.
Patch 1 & 2 use the preemption-safe per-cpu helpers to manipulate
prog->active and bpf_task_storage_busy. Patch 3 & 4 add a test case in
map_tests to show the concurrent updates on the per-cpu
bpf_task_storage_busy by using __this_cpu_{inc|dec} are not atomic.
Comments are always welcome.
Regards,
Tao
Change Log:
v2:
* Patch 1: update commit message to indicate the problem is only
possible for fully preemptible kernel
* Patch 2: a new patch which fixes the problem for prog->active
* Patch 3 & 4: move it to test_maps and make it depend on CONFIG_PREEMPT
v1: https://lore.kernel.org/bpf/20220829142752.330094-1-houtao@huaweicloud.com/
====================
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Under full preemptible kernel, task local storage lookup operations on
the same CPU may update per-cpu bpf_task_storage_busy concurrently. If
the update of bpf_task_storage_busy is not preemption safe, the final
value of bpf_task_storage_busy may become not-zero forever and
bpf_task_storage_trylock() will always fail. So add a test case to
ensure the update of bpf_task_storage_busy is preemption safe.
Will skip the test case when CONFIG_PREEMPT is disabled, and it can only
reproduce the problem probabilistically. By increasing
TASK_STORAGE_MAP_NR_LOOP and running it under ARM64 VM with 4-cpus, it
takes about four rounds to reproduce:
> test_maps is modified to only run test_task_storage_map_stress_lookup()
$ export TASK_STORAGE_MAP_NR_THREAD=256
$ export TASK_STORAGE_MAP_NR_LOOP=81920
$ export TASK_STORAGE_MAP_PIN_CPU=1
$ time ./test_maps
test_task_storage_map_stress_lookup(135):FAIL:bad bpf_task_storage_busy got -2
real 0m24.743s
user 0m6.772s
sys 0m17.966s
Signed-off-by: Hou Tao <houtao1@huawei.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/r/20220901061938.3789460-5-houtao@huaweicloud.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
sys_pidfd_open() is defined twice in both test_bprm_opts.c and
test_local_storage.c, so move it to a common header file. And it will be
used in map_tests as well.
Signed-off-by: Hou Tao <houtao1@huawei.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/r/20220901061938.3789460-4-houtao@huaweicloud.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Both __this_cpu_inc_return() and __this_cpu_dec() are not preemption
safe and now migrate_disable() doesn't disable preemption, so the update
of prog-active is not atomic and in theory under fully preemptible kernel
recurisve prevention may do not work.
Fixing by using the preemption-safe and IRQ-safe variants.
Fixes: ca06f55b90 ("bpf: Add per-program recursion prevention mechanism")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/r/20220901061938.3789460-3-houtao@huaweicloud.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
Now migrate_disable() does not disable preemption and under some
architectures (e.g. arm64) __this_cpu_{inc|dec|inc_return} are neither
preemption-safe nor IRQ-safe, so for fully preemptible kernel concurrent
lookups or updates on the same task local storage and on the same CPU
may make bpf_task_storage_busy be imbalanced, and
bpf_task_storage_trylock() on the specific cpu will always fail.
Fixing it by using this_cpu_{inc|dec|inc_return} when manipulating
bpf_task_storage_busy.
Fixes: bc235cdb42 ("bpf: Prevent deadlock from recursive bpf_task_storage_[get|delete]")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/r/20220901061938.3789460-2-houtao@huaweicloud.com
Signed-off-by: Martin KaFai Lau <martin.lau@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEjUuTAak14xi+SF7M4CHKc/GJqRAFAmMQhqcACgkQ4CHKc/GJ
qRC1ywf+JPE12TvdYL5s3V6OySv4Qx2lSXe2Ka/FcQIM0nCYH+dunKgBDK4+/cyf
4Jh9gNZhA8OMBlbRKA+hvOab7qgk+iGCLmVv+5JjBalUPufp1IWTEGAY0NP4CIjy
6b8okqIMPnZnJq3QpBgONfnv7ymILQevw8g1rmvw2/0hxjxWN3eAWVQgfYyawh7p
mDubKcqqYV5b5hxgJbY9/STgb6VzWuAp6nm5YCPrlSzQPRuOxE5IgCAJ0mWOFoLN
qhzc4JAh/Pt4jr+bKzeMgPhA3oqrEMvHctT/PMzbV8oAesr97Das/csTQEhba7Vj
3P9HOyMFs/lPT5+hmMam7hdrslrzGQ==
=jIKX
-----END PGP SIGNATURE-----
Merge tag 'slab-for-6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab
Pull slab fix from Vlastimil Babka:
- A fix from Waiman Long to avoid a theoretical deadlock reported by
lockdep.
* tag 'slab-for-6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vbabka/slab:
mm/slab_common: Deleting kobject in kmem_cache_destroy() without holding slab_mutex/cpu_hotplug_lock
Just handful changes at this time. The only major change is the
regression fix about the x86 WC-page buffer allocation.
The rest are trivial data-race fixes for ALSA sequencer core,
the possible out-of-bounds access fixes in the new ALSA control
hash code, and a few device-specific workarounds and fixes.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmMQaOQOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE/5tBAAipTHkfJP7PBEmg4xYkrOP5CPH6epfsA5Pcxw
Uyf6PX6ylvYK9SR2CyPLFXXWtyKrFXhhMp9J+36tO4tx5bH5lQ6HvkYfkRUNnq2S
2iHHctork6UmCmKYk6ChxngXoGqRWivFISqeEaU0kM2P1ke56y75gpDZfxstRVOD
6UIUavjAlosUh8QfxMMPaRIZG4KTKLLGraQ8EcZHAkyi2jnQevKY3VcGO8SkjBX0
nTLMcD5YaTURY8ZwaJcsd5hhbvmKehu2oMpDPyQR4ln+QcbYrYV2U9tWFGA065fa
JK9z+wRC7h1iHgt7HjDZlnsVm+egNZ1cxs5KmJphC71YcceHKZm7fJYpQ3fnNvPB
FJc4Esumx2CsAtj8NnDT82u+6GgQVrLqpNo+Cif1Pyu0Ek2wE8M6jZ4FM7xQaU1v
+bFX91hqJbHc80hkK1oR/Pz+Op+OONA55kskKtCE3SZLvZm3EXD0ZXXeCGtj0ECw
GxLRUqBd4KE3wOjHvwl2AZ4XZVedUIO2ddnyanPOKjH+lMFrW3uMvxOa0znd59Ym
YGdlWVubJ4wEwnT3s1kZd0sOAykHTjrB4IBhCPysGpa0exaY5ZTE+rZ7VTu0Stav
JXn3WtzYim7U5uUjQK8wqfe+gg42nHZ37KzQeJrUpv/Ybnh7SVEkuIwzLuFKKiyI
RBZGGLs=
=Ksu8
-----END PGP SIGNATURE-----
Merge tag 'sound-6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"Just handful changes at this time. The only major change is the
regression fix about the x86 WC-page buffer allocation.
The rest are trivial data-race fixes for ALSA sequencer core, the
possible out-of-bounds access fixes in the new ALSA control hash code,
and a few device-specific workarounds and fixes"
* tag 'sound-6.0-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: usb-audio: Add quirk for LH Labs Geek Out HD Audio 1V5
ALSA: hda/realtek: Add speaker AMP init for Samsung laptops with ALC298
ALSA: control: Re-order bounds checking in get_ctl_id_hash()
ALSA: control: Fix an out-of-bounds bug in get_ctl_id_hash()
ALSA: hda: intel-nhlt: Correct the handling of fmt_config flexible array
ALSA: seq: Fix data-race at module auto-loading
ALSA: seq: oss: Fix data-race for max_midi_devs access
ALSA: memalloc: Revive x86-specific WC page allocations again
