Johannes Berg [Wed, 18 Jan 2023 09:51:53 +0000 (10:51 +0100)]
wifi: wireless: deny wireless extensions on MLO-capable devices
These are WiFi 7 devices that will be introduced into the market
in 2023, with new drivers. Wireless extensions haven't been in
real development since 2006. Since wireless has evolved a lot,
and continues to evolve significantly with Multi-Link Operation,
there's really no good way to still support wireless extensions
for devices that do MLO.
Stop supporting wireless extensions for new devices. We don't
consider this a regression since no such devices (apart from
hwsim) exist yet.
Johannes Berg [Wed, 18 Jan 2023 09:51:52 +0000 (10:51 +0100)]
wifi: wireless: warn on most wireless extension usage
With WiFi 7 (802.11ax, MLO/EHT) around the corner, we're going to
remove support for wireless extensions with new devices since MLO
(multi-link operation) cannot be properly indicated using them.
Add a warning to indicate which processes are still using wireless
extensions, if being used with modern (i.e. cfg80211) drivers.
Johannes Berg [Wed, 18 Jan 2023 13:26:53 +0000 (14:26 +0100)]
bitfield: add FIELD_PREP_CONST()
Neither FIELD_PREP() nor *_encode_bits() can be used
in constant contexts (such as initializers), but we
don't want to define shift constants for all masks
just for use in initializers, and having checks that
the values fit is also useful.
Therefore, add FIELD_PREP_CONST() which is a smaller
version of FIELD_PREP() that can only take constant
arguments and has less friendly (but not less strict)
error checks, and expands to a constant value.
Johannes Berg [Thu, 19 Jan 2023 07:52:01 +0000 (08:52 +0100)]
wifi: mac80211: add kernel-doc for EHT structure
Looks like this is required, even if all of the members
are separately described. Add a line to avoid the warning.
Fixes: f66c48af7a11 ("mac80211: support minimal EHT rate reporting on RX") Reported-by: Stephen Rothwell <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
Muna Sinada [Wed, 5 Oct 2022 21:54:46 +0000 (14:54 -0700)]
wifi: mac80211: Add HE MU-MIMO related flags in ieee80211_bss_conf
Adding flags for SU Beamformer, SU Beamformee, MU Beamformer and Full
Bandwidth UL MU-MIMO for HE. This is utilized to pass MU-MIMO
configurations from user space to driver in AP mode.
Muna Sinada [Wed, 5 Oct 2022 21:54:45 +0000 (14:54 -0700)]
wifi: mac80211: Add VHT MU-MIMO related flags in ieee80211_bss_conf
Adding flags for SU Beamformer, SU Beamformee, MU Beamformer and
MU Beamformee for VHT. This is utilized to pass MU-MIMO
configurations from user space to driver in AP mode.
wifi: cfg80211: Support 32 bytes KCK key in GTK rekey offload
Currently, maximum KCK key length supported for GTK rekey offload is 24
bytes but with some newer AKMs the KCK key length can be 32 bytes. e.g.,
00-0F-AC:24 AKM suite with SAE finite cyclic group 21. Add support to
allow 32 bytes KCK keys in GTK rekey offload.
wifi: cfg80211: Fix extended KCK key length check in nl80211_set_rekey_data()
The extended KCK key length check wrongly using the KEK key attribute
for validation. Due to this GTK rekey offload is failing when the KCK
key length is 24 bytes even though the driver advertising
WIPHY_FLAG_SUPPORTS_EXT_KEK_KCK flag. Use correct attribute to fix the
same.
Kalle Valo [Tue, 17 Jan 2023 11:36:25 +0000 (13:36 +0200)]
Merge wireless into wireless-next
Due to the two cherry picked commits from wireless to wireless-next we have
several conflicts in mt76. To avoid any bugs with conflicts merge wireless into
wireless-next.
96f134dc1964 wifi: mt76: handle possible mt76_rx_token_consume failures fe13dad8992b wifi: mt76: dma: do not increment queue head if mt76_dma_add_buf fails
Bitterblue Smith [Tue, 10 Jan 2023 15:42:39 +0000 (17:42 +0200)]
wifi: rtl8xxxu: Dump the efuse only for untested devices
It appears this was the intention all along, but commit 3307d84024d2
("rtl8xxxu: Add initial code to parse rtl8192eu efuse") initialised
rtl8xxxu_debug with RTL8XXXU_DEBUG_EFUSE for no apparent reason, which
made it dump the efuse for all devices, even the tested ones.
wifi: rtw88: Use non-atomic sta iterator in rtw_ra_mask_info_update()
USB and (upcoming) SDIO support may sleep in the read/write handlers.
Use non-atomic rtw_iterate_stas() in rtw_ra_mask_info_update() because
the iterator function rtw_ra_mask_info_update_iter() needs to read and
write registers from within rtw_update_sta_info(). Using the non-atomic
iterator ensures that we can sleep during USB and SDIO register reads
and writes. This fixes "scheduling while atomic" or "Voluntary context
switch within RCU read-side critical section!" warnings as seen by SDIO
card users (but it also affects USB cards).
wifi: rtw88: Use rtw_iterate_vifs() for rtw_vif_watch_dog_iter()
USB and (upcoming) SDIO support may sleep in the read/write handlers.
Make rtw_watch_dog_work() use rtw_iterate_vifs() to prevent "scheduling
while atomic" or "Voluntary context switch within RCU read-side
critical section!" warnings when accessing the registers using an SDIO
card (which is where this issue has been spotted in the real world but
it also affects USB cards).
wifi: rtw88: Move register access from rtw_bf_assoc() outside the RCU
USB and (upcoming) SDIO support may sleep in the read/write handlers.
Shrink the RCU critical section so it only cover the call to
ieee80211_find_sta() and finding the ic_vht_cap/vht_cap based on the
found station. This moves the chip's BFEE configuration outside the
rcu_read_lock section and thus prevent "scheduling while atomic" or
"Voluntary context switch within RCU read-side critical section!"
warnings when accessing the registers using an SDIO card (which is
where this issue has been spotted in the real world - but it also
affects USB cards).
The Realtek rate control algorithm goes back and forth a lot between
the highest and the lowest rate it's allowed to use. This is due to
a lot of frames being dropped because the retry limits set by
IEEE80211_CONF_CHANGE_RETRY_LIMITS are too low. (Experimentally, they
are 4 for long frames and 7 for short frames.)
The vendor drivers hardcode the value 48 for both retry limits (for
station mode), which makes dropped frames very rare and thus the rate
control is more stable.
Because most Realtek chips handle the rate control in the firmware,
which can't be modified, ignore the limits set by
IEEE80211_CONF_CHANGE_RETRY_LIMITS and use the value 48 (set during
chip initialisation), same as the vendor drivers.
Or in the case of RTL8188EU, report the RSSI to the rate control code.
The rate control code for RTL8188EU is less likely to switch to a lower
rate when the RSSI is high. The firmware-based rate control in the other
chips probably works the same way.
This affects all the chips, but it was only tested with RTL8188EU,
RTL8188FU, and RTL8192EU.
Jisoo Jang [Thu, 29 Dec 2022 09:29:06 +0000 (18:29 +0900)]
wifi: mt7601u: fix an integer underflow
Fix an integer underflow that leads to a null pointer dereference in
'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet
could be manipulated, which could trigger an integer underflow of
'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently
causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be
bypassed, eventually leading to a dereference of the pointer 'p', which
is a null pointer.
Ensure that 'dma_len' is greater than 'min_seg_len'.
Alexey Kodanev [Tue, 27 Dec 2022 13:33:06 +0000 (16:33 +0300)]
wifi: orinoco: check return value of hermes_write_wordrec()
There is currently no return check for writing an authentication
type (HERMES_AUTH_SHARED_KEY or HERMES_AUTH_OPEN). It looks like
it was accidentally skipped.
This patch adds a return check similar to the other checks in
__orinoco_hw_setup_enc() for hermes_write_wordrec().
Bitterblue Smith [Thu, 22 Dec 2022 11:48:04 +0000 (13:48 +0200)]
wifi: rtl8xxxu: Fix memory leaks with RTL8723BU, RTL8192EU
The wifi + bluetooth combo chip RTL8723BU can leak memory (especially?)
when it's connected to a bluetooth audio device. The busy bluetooth
traffic generates lots of C2H (card to host) messages, which are not
freed correctly.
To fix this, move the dev_kfree_skb() call in rtl8xxxu_c2hcmd_callback()
inside the loop where skb_dequeue() is called.
The RTL8192EU leaks memory because the C2H messages are added to the
queue and left there forever. (This was fine in the past because it
probably wasn't sending any C2H messages until commit e542e66b7c2e
("wifi: rtl8xxxu: gen2: Turn on the rate control"). Since that commit
it sends a C2H message when the TX rate changes.)
To fix this, delete the check for rf_paths > 1 and the goto. Let the
function process the C2H messages from RTL8192EU like the ones from
the other chips.
Theoretically the RTL8188FU could also leak like RTL8723BU, but it
most likely doesn't send C2H messages frequently enough.
This change was tested with RTL8723BU by Erhard F. I tested it with
RTL8188FU and RTL8192EU.
Felix Fietkau [Fri, 13 Jan 2023 10:58:48 +0000 (11:58 +0100)]
wifi: mt76: dma: fix a regression in adding rx buffers
When adding WED support, mt76_dma_add_buf was accidentally changed to set
the skip_buf0 flag for tx buffers on the wrong queue descriptor entry.
Additionally, there is a rxwi leak when rx buffer allocation fails.
Fix this and make the code more readable by adding a separate function for
adding rx buffers.
Zong-Zhe Yang [Fri, 13 Jan 2023 09:06:32 +0000 (17:06 +0800)]
wifi: rtw89: 8852b: fill the missing configuration about queue empty checking
The configurations, wde_qempty_acq_num and wde_qempty_mgq_sel, are used
when MAC checks if TX queues are empty. Fill the corresponding setting
for 8852B.
Zong-Zhe Yang [Fri, 13 Jan 2023 09:06:31 +0000 (17:06 +0800)]
wifi: rtw89: fix assignation of TX BD RAM table
TX BD's RAM table describes how HW allocates usable buffer section
for each TX channel at fetch time. The total RAM size for TX BD is
chip-dependent. For 8852BE, it has only half size (32) for TX channels
of single band. Original table arrange total size (64) for dual band.
It will overflow on 8852BE circuit and cause section conflicts between
different TX channels.
So, we do the changes below.
* add another table for single band chip and export both kind of tables
* point to the expected one in rtw89_pci_info by chip
Some hardware modules don't have good RF characteristic as regular.
It could get ADC abnormal in low temperature, and it causes bad RX
performance and affects calibration result of DPK.
Kuan-Chung Chen [Fri, 6 Jan 2023 12:15:17 +0000 (20:15 +0800)]
wifi: rtw89: set the correct mac_id for management frames
The mac_id of management frames should follow rtwvif->mac_id or
rtwsta->mac_id. Add this patch to set the correct mac_id and
prevent unexpected behavior.
Kuan-Chung Chen [Fri, 6 Jan 2023 12:15:16 +0000 (20:15 +0800)]
wifi: rtw89: fix null vif pointer when get management frame date rate
When transmitting a packet that gets from ieee80211_nullfunc_get(),
the vif in tx_info->control was no assigned, which will cause
dereferencing a null pointer.
Ching-Te Ku [Fri, 6 Jan 2023 12:08:44 +0000 (20:08 +0800)]
wifi: rtw89: coex: Change Wi-Fi role info related logic to version separate
The Wi-Fi role info structure will need to H2C to firmware, firmware
need these information to do some multi-role operation. v1 add DBCC
and NOA information in the structure. And driver side also need to
put/get values at the corresponding version of structure.
Ching-Te Ku [Fri, 6 Jan 2023 12:08:43 +0000 (20:08 +0800)]
wifi: rtw89: coex: Change RTL8852B use v1 TDMA policy
RTL8852B support the new features like TDMA instant (Change TDMA mechanism
immediately), Co-RX feature (Wi-Fi/Bluetooth can RX in the same time) and
so on. The v1 TDMA policy will enable those newer mechanism. It will have
a better coexistence performance.
Because the difference of the hardware design, RTL8852C can not get the
PTA owner by the same method with RTL8852B, RTL8852A. Modify the get owner
API and related logic.
Ching-Te Ku [Fri, 6 Jan 2023 12:08:40 +0000 (20:08 +0800)]
wifi: rtw89: coex: Change firmware steps report to version separate
The report records the slots/events and their time cost about the code
call flow at firmware, ver 3 assign a reserved variable to recognize
the report is enabled or not. And add corresponding function to parsing
the report.
Ching-Te Ku [Fri, 6 Jan 2023 12:08:39 +0000 (20:08 +0800)]
wifi: rtw89: coex: Change Wi-Fi Null data report to version separate
Coexistence need to send Null data to stop AP keeps TX packet to DUT
before DUT coexistence switch to Bluetooth time slot, or it will be an
interference to DUT BT and because DUT will not RX packet from AP
the packet retry may harmful to WL TP. Compare to v1 version, the newer
firmware report will also report Null TX data counter.
Ching-Te Ku [Fri, 6 Jan 2023 12:08:38 +0000 (20:08 +0800)]
wifi: rtw89: coex: Add version code for Wi-Fi firmware coexistence control
The newer Wi-Fi firmware are all changed to "Not to send H2C to
mention firmware how many call flow step should firmware trace".
The structure had removed the member, and define the steps number
at newer version firmware.
Ching-Te Ku [Tue, 3 Jan 2023 14:02:38 +0000 (22:02 +0800)]
wifi: rtw89: coex: Update WiFi role info H2C report
Change style to feature version separate. And because there are
different WiFi roles number in the firmware, it will make structure
length longer or shorter, so update the length calculator to cover
the difference.
Ching-Te Ku [Tue, 3 Jan 2023 14:02:37 +0000 (22:02 +0800)]
wifi: rtw89: coex: only read Bluetooth counter of report version 1 for RTL8852A
Only when firmware control report version is 1, need to get the counter by
reading the register. The other version will monitor the counter at
firmware. And upstream branch only RTL8852A has this old version.
Ching-Te Ku [Tue, 3 Jan 2023 14:02:35 +0000 (22:02 +0800)]
wifi: rtw89: coex: Change firmware control report to version separate
The rtw89 driver may support more than 1 version of Wi-Fi firmware for
certain chips. In order to support all the firmware, change to select logic
by firmware feature version code. Type control version 4 will monitor
Bluetooth PTA hardware counters at firmware and C2H to driver, but
version 1 will not do this.
Ching-Te Ku [Tue, 3 Jan 2023 14:02:34 +0000 (22:02 +0800)]
wifi: rtw89: coex: Add v4 version firmware cycle report
To support v4 version firmware cycle report, apply the related
structure and functions. v4 cycle report add a group of status
to show how the free-run/TDMA training goes to. It is a firmware
mechanism that can auto adjust coexistence mode between TDMA and
free run mechanism at 3 antenna solution.
Ching-Te Ku [Tue, 3 Jan 2023 14:02:33 +0000 (22:02 +0800)]
wifi: rtw89: coex: Rename BTC firmware cycle report by feature version
Because there are new report format in the upcoming patches, to make the
logic more readable, rename the related structure by their version number.
And to support the several version at the same time, add union definition
to include all the versions.
Ching-Te Ku [Tue, 3 Jan 2023 14:02:32 +0000 (22:02 +0800)]
wifi: rtw89: coex: Remove le32 to CPU translator at firmware cycle report
There are at least 2 version of cycle report format. If the code keep
translating the report to local variable, the numbers of variable in
check btc report function will out of maximum variable numbers. And
most of these variable are using only one time, it is not necessary
to store at memory.
Jisoo Jang [Fri, 30 Dec 2022 07:51:39 +0000 (16:51 +0900)]
wifi: brcmfmac: ensure CLM version is null-terminated to prevent stack-out-of-bounds
Fix a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with
a CLM version string by memcpy() in brcmf_fil_iovar_data_get().
Ensure buf is null-terminated.
Szymon Heidrich [Wed, 11 Jan 2023 17:50:31 +0000 (18:50 +0100)]
wifi: rndis_wlan: Prevent buffer overflow in rndis_query_oid
Since resplen and respoffs are signed integers sufficiently
large values of unsigned int len and offset members of RNDIS
response will result in negative values of prior variables.
This may be utilized to bypass implemented security checks
to either extract memory contents by manipulating offset or
overflow the data buffer via memcpy by manipulating both
offset and len.
Additionally assure that sum of resplen and respoffs does not
overflow so buffer boundaries are kept.
Arend van Spriel [Wed, 11 Jan 2023 11:24:19 +0000 (12:24 +0100)]
wifi: brcmfmac: fix regression for Broadcom PCIe wifi devices
A sanity check was introduced considering maximum flowrings above
256 as insane and effectively aborting the device probe. This
resulted in regression for number of users as the value turns out
to be sane after all.
wifi: brcmfmac: avoid NULL-deref in survey dump for 2G only device
When dealing with a device for 2GHz band only the wiphy->bands for
5GHz will be NULL. This would result in a NULL-deref in the
brcmf_cfg80211_dump_survey() function. Rework the code with a
for-loop to make it easier to add another band.
wifi: brcmfmac: avoid handling disabled channels for survey dump
An issue was reported in which periodically error messages are
printed in the kernel log:
[ 26.303445] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43455-sdio for chip BCM4345/6
[ 26.303554] brcmfmac mmc1:0001:1: Direct firmware load for brcm/brcmfmac43455-sdio.raspberrypi,3-model-b-plus.bin failed with error -2
[ 26.516752] brcmfmac_wcc: brcmf_wcc_attach: executing
[ 26.528264] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM4345/6 wl0: Jan 4 2021 19:56:29 version 7.45.229 (617f1f5 CY) FWID 01-2dbd9d2e
[ 27.076829] Bluetooth: hci0: BCM: features 0x2f
[ 27.078592] Bluetooth: hci0: BCM43455 37.4MHz Raspberry Pi 3+
[ 27.078601] Bluetooth: hci0: BCM4345C0 (003.001.025) build 0342
[ 30.142104] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SS
[ 30.590017] Bluetooth: MGMT ver 1.22
[ 104.897615] brcmfmac: cfg80211_set_channel: set chanspec 0x100e fail, reason -52
[ 104.897992] brcmfmac: cfg80211_set_channel: set chanspec 0xd022 fail, reason -52
[ 105.007672] brcmfmac: cfg80211_set_channel: set chanspec 0xd026 fail, reason -52
[ 105.117654] brcmfmac: cfg80211_set_channel: set chanspec 0xd02a fail, reason -52
[ 105.227636] brcmfmac: cfg80211_set_channel: set chanspec 0xd02e fail, reason -52
[ 106.987552] brcmfmac: cfg80211_set_channel: set chanspec 0xd090 fail, reason -52
[ 106.987911] brcmfmac: cfg80211_set_channel: set chanspec 0xd095 fail, reason -52
[ 106.988233] brcmfmac: cfg80211_set_channel: set chanspec 0xd099 fail, reason -52
[ 106.988565] brcmfmac: cfg80211_set_channel: set chanspec 0xd09d fail, reason -52
[ 106.988909] brcmfmac: cfg80211_set_channel: set chanspec 0xd0a1 fail, reason -52
This happens in brcmf_cfg80211_dump_survey() because we try a disabled
channel. When channel is marked as disabled we do not need to fill any
other info so bail out.
Philipp Zabel [Mon, 2 Jan 2023 17:29:34 +0000 (18:29 +0100)]
net: rfkill: gpio: add DT support
Allow probing rfkill-gpio via device tree. This hooks up the already
existing support that was started in commit 262c91ee5e52 ("net:
rfkill: gpio: prepare for DT and ACPI support") via the "rfkill-gpio"
compatible, with the "name" and "type" properties renamed to "label"
and "radio-type", respectively, in the device tree case.
Philipp Zabel [Mon, 2 Jan 2023 17:29:33 +0000 (18:29 +0100)]
dt-bindings: net: Add rfkill-gpio binding
Add a device tree binding document for GPIO controlled rfkill switches.
The label and radio-type properties correspond to the name and type
properties used for ACPI, respectively. The shutdown-gpios property
is the same as defined for ACPI.
wifi: mac80211: Drop stations iterator where the iterator function may sleep
This reverts commit acb99b9b2a08f ("mac80211: Add stations iterator
where the iterator function may sleep"). A different approach was found
for the rtw88 driver where most of the problematic locks were converted
to a driver-local mutex. Drop ieee80211_iterate_stations() because there
are no users of that function.
Felix Fietkau [Wed, 14 Dec 2022 13:03:26 +0000 (14:03 +0100)]
wifi: mac80211: fix MLO + AP_VLAN check
Instead of preventing adding AP_VLAN to MLO enabled APs, this check was
preventing adding more than one 4-addr AP_VLAN regardless of the MLO status.
Fix this by adding missing extra checks.
Sriram R [Thu, 8 Dec 2022 04:00:50 +0000 (09:30 +0530)]
mac80211: Fix MLO address translation for multiple bss case
When multiple interfaces are present in the local interface
list, new skb copy is taken before rx processing except for
the first interface. The address translation happens each
time only on the original skb since the hdr pointer is not
updated properly to the newly created skb.
As a result frames start to drop in userspace when address
based checks or search fails.
Alexander Wetzel [Fri, 30 Dec 2022 12:18:49 +0000 (13:18 +0100)]
wifi: mac80211: Proper mark iTXQs for resumption
When a running wake_tx_queue() call is aborted due to a hw queue stop
the corresponding iTXQ is not always correctly marked for resumption:
wake_tx_push_queue() can stops the queue run without setting
@IEEE80211_TXQ_STOP_NETIF_TX.
Without the @IEEE80211_TXQ_STOP_NETIF_TX flag __ieee80211_wake_txqs()
will not schedule a new queue run and remaining frames in the queue get
stuck till another frame is queued to it.
Fix the issue for all drivers - also the ones with custom wake_tx_queue
callbacks - by moving the logic into ieee80211_tx_dequeue() and drop the
redundant @txqs_stopped.
@IEEE80211_TXQ_STOP_NETIF_TX is also renamed to @IEEE80211_TXQ_DIRTY to
better describe the flag.
Felix Fietkau [Fri, 30 Dec 2022 20:07:47 +0000 (21:07 +0100)]
wifi: mac80211: fix initialization of rx->link and rx->link_sta
There are some codepaths that do not initialize rx->link_sta properly. This
causes a crash in places which assume that rx->link_sta is valid if rx->sta
is valid.
One known instance is triggered by __ieee80211_rx_h_amsdu being called from
fast-rx. It results in a crash like this one:
Since the initialization of rx->link and rx->link_sta is rather convoluted
and duplicated in many places, clean it up by using a helper function to
set it.
af_unix: selftest: Fix the size of the parameter to connect()
Adjust size parameter in connect() to match the type of the parameter, to
fix "No such file or directory" error in selftests/net/af_unix/
test_oob_unix.c:127.
The existing code happens to work provided that the autogenerated pathname
is shorter than sizeof (struct sockaddr), which is why it hasn't been
noticed earlier.
Visible from the trace excerpt:
bind(3, {sa_family=AF_UNIX, sun_path="unix_oob_453059"}, 110) = 0
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fa6a6577a10) = 453060
[pid <child>] connect(6, {sa_family=AF_UNIX, sun_path="unix_oob_45305"}, 16) = -1 ENOENT (No such file or directory)
BUG: The filename is trimmed to sizeof (struct sockaddr).
Horatiu Vultur [Fri, 6 Jan 2023 20:15:07 +0000 (21:15 +0100)]
net: lan966x: Allow to add rules in TCAM even if not enabled
The blamed commit implemented the vcap_operations to allow to add an
entry in the TCAM. One of the callbacks is to validate the supported
keysets. If the TCAM lookup was not enabled, then this will return
failure so no entries could be added.
This doesn't make much sense, as you can enable at a later point the
TCAM. Therefore change it such to allow entries in TCAM even it is not
enabled.
Fixes: 4426b78c626d ("net: lan966x: Add port keyset config and callback interface") Signed-off-by: Horatiu Vultur <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Eric Dumazet [Fri, 6 Jan 2023 14:25:23 +0000 (14:25 +0000)]
gro: take care of DODGY packets
Jaroslav reported a recent throughput regression with virtio_net
caused by blamed commit.
It is unclear if DODGY GSO packets coming from user space
can be accepted by GRO engine in the future with minimal
changes, and if there is any expected gain from it.
In the meantime, make sure to detect and flush DODGY packets.
Minsuk Kang [Fri, 6 Jan 2023 08:23:44 +0000 (17:23 +0900)]
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
Fix a use-after-free that occurs in hcd when in_urb sent from
pn533_usb_send_frame() is completed earlier than out_urb. Its callback
frees the skb data in pn533_send_async_complete() that is used as a
transfer buffer of out_urb. Wait before sending in_urb until the
callback of out_urb is called. To modify the callback of out_urb alone,
separate the complete function of out_urb and ack_urb.
Kees Cook [Thu, 5 Jan 2023 23:22:29 +0000 (15:22 -0800)]
mlxsw: spectrum_router: Replace 0-length array with flexible array
Zero-length arrays are deprecated[1]. Replace struct
mlxsw_sp_nexthop_group_info's "nexthops" 0-length array with a flexible
array. Detected with GCC 13, using -fstrict-flex-arrays=3:
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c: In function 'mlxsw_sp_nexthop_group_hash_obj':
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:3278:38: warning: array subscript i is outside array bounds of 'struct mlxsw_sp_nexthop[0]' [-Warray-bounds=]
3278 | val ^= jhash(&nh->ifindex, sizeof(nh->ifindex), seed);
| ^~~~~~~~~~~~
drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:2954:33: note: while referencing 'nexthops'
2954 | struct mlxsw_sp_nexthop nexthops[0];
| ^~~~~~~~
Alex Elder [Fri, 6 Jan 2023 13:25:01 +0000 (07:25 -0600)]
net: ipa: correct IPA v4.7 IMEM offset
Commit b310de784bacd ("net: ipa: add IPA v4.7 support") was merged
despite an unresolved comment made by Konrad Dybcio. Konrad
observed that the IMEM region specified for IPA v4.7 did not match
that used downstream for the SM7225 SoC. In "lagoon.dtsi" present
in a Sony Xperia source tree, a ipa_smmu_ap node was defined with a
"qcom,additional-mapping" property that defined the IPA IMEM area
starting at offset 0x146a8000 (not 0x146a9000 that was committed).
The IPA v4.7 target system used for testing uses the SM7225 SoC, so
we'll adhere what the downstream code specifies is the address of
the IMEM region used for IPA.
Ivan T. Ivanov [Fri, 6 Jan 2023 13:19:05 +0000 (15:19 +0200)]
brcmfmac: Prefer DT board type over DMI board type
The introduction of support for Apple board types inadvertently changed
the precedence order, causing hybrid SMBIOS+DT platforms to look up the
firmware using the DMI information instead of the device tree compatible
to generate the board type. Revert back to the old behavior,
as affected platforms use firmwares named after the DT compatible.
Fixes: 7682de8b3351 ("wifi: brcmfmac: of: Fetch Apple properties")
[1] https://bugzilla.opensuse.org/show_bug.cgi?id=1206697#c13
David S. Miller [Sat, 7 Jan 2023 23:10:33 +0000 (23:10 +0000)]
Merge tag 'rxrpc-fixes-20230107' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs
David Howells says:
====================
rxrpc: Fix race between call connection, data transmit and call disconnect
Here are patches to fix an oops[1] caused by a race between call
connection, initial packet transmission and call disconnection which
results in something like:
kernel BUG at net/rxrpc/peer_object.c:413!
when the syzbot test is run. The problem is that the connection procedure
is effectively split across two threads and can get expanded by taking an
interrupt, thereby adding the call to the peer error distribution list
*after* it has been disconnected (say by the rxrpc socket shutting down).
The easiest solution is to look at the fourth set of I/O thread
conversion/SACK table expansion patches that didn't get applied[2] and take
from it those patches that move call connection and disconnection into the
I/O thread. Moving these things into the I/O thread means that the
sequencing is managed by all being done in the same thread - and the race
can no longer happen.
This is preferable to introducing an extra lock as adding an extra lock
would make the I/O thread have to wait for the app thread in yet another
place.
The changes can be considered as a number of logical parts:
(1) Move all of the call state changes into the I/O thread.
(2) Make client connection ID space per-local endpoint so that the I/O
thread doesn't need locks to access it.
(3) Move actual abort generation into the I/O thread and clean it up. If
sendmsg or recvmsg want to cause an abort, they have to delegate it.
(4) Offload the setting up of the security context on a connection to the
thread of one of the apps that's starting a call. We don't want to be
doing any sort of crypto in the I/O thread.
(5) Connect calls (ie. assign them to channel slots on connections) in the
I/O thread. Calls are set up by sendmsg/kafs and passed to the I/O
thread to connect. Connections are allocated in the I/O thread after
this.
(6) Disconnect calls in the I/O thread.
I've also added a patch for an unrelated bug that cropped up during
testing, whereby a race can occur between an incoming call and socket
shutdown.
Note that whilst this fixes the original syzbot bug, another bug may get
triggered if this one is fixed:
It doesn't look this should be anything to do with rxrpc, though, as I've
tested an additional patch[3] that removes practically all the RCU usage
from rxrpc and it still occurs. It seems likely that it is being caused by
something in the tunnelling setup that the syzbot test does, but there's
not enough info to go on. It also seems unlikely to be anything to do with
the afs driver as the test doesn't use that.
====================
incurred during rmmod of rxrpc. The 1061d is the call flags:
RECVMSG_READ_ALL, RX_HEARD, BEGAN_RX_TIMER, RX_LAST, EXPOSED,
IS_SERVICE, RELEASED
but no DISCONNECTED flag (0x800), so it's an incoming (service) call and
it's still connected.
The race appears to be that:
(1) rxrpc_new_incoming_call() consults the service struct, checks sk_state
and allocates a call - then pauses, possibly for an interrupt.
(2) rxrpc_release_sock() sets RXRPC_CLOSE, nulls the service pointer,
discards the prealloc and releases all calls attached to the socket.
(3) rxrpc_new_incoming_call() resumes, launching the new call, including
its timer and attaching it to the socket.
Fix this by read-locking local->services_lock to access the AF_RXRPC socket
providing the service rather than RCU in rxrpc_new_incoming_call().
There's no real need to use RCU here as local->services_lock is only
write-locked by the socket side in two places: when binding and when
shutting down.
Fixes: 5e6ef4f1017c ("rxrpc: Make the I/O thread take over the call and local processor work") Reported-by: Marc Dionne <[email protected]> Signed-off-by: David Howells <[email protected]>
cc: [email protected]
Angela Czubak [Thu, 5 Jan 2023 16:01:07 +0000 (21:31 +0530)]
octeontx2-af: Fix LMAC config in cgx_lmac_rx_tx_enable
PF netdev can request AF to enable or disable reception and transmission
on assigned CGX::LMAC. The current code instead of disabling or enabling
'reception and transmission' also disables/enable the LMAC. This patch
fixes this issue.
Tung Nguyen [Thu, 5 Jan 2023 06:02:51 +0000 (06:02 +0000)]
tipc: fix unexpected link reset due to discovery messages
This unexpected behavior is observed:
node 1 | node 2
------ | ------
link is established | link is established
reboot | link is reset
up | send discovery message
receive discovery message |
link is established | link is established
send discovery message |
| receive discovery message
| link is reset (unexpected)
| send reset message
link is reset |
It is due to delayed re-discovery as described in function
tipc_node_check_dest(): "this link endpoint has already reset
and re-established contact with the peer, before receiving a
discovery message from that node."
However, commit 598411d70f85 has changed the condition for calling
tipc_node_link_down() which was the acceptance of new media address.
This commit fixes this by restoring the old and correct behavior.
David Howells [Wed, 19 Oct 2022 08:45:43 +0000 (09:45 +0100)]
rxrpc: Move client call connection to the I/O thread
Move the connection setup of client calls to the I/O thread so that a whole
load of locking and barrierage can be eliminated. This necessitates the
app thread waiting for connection to complete before it can begin
encrypting data.
This also completes the fix for a race that exists between call connection
and call disconnection whereby the data transmission code adds the call to
the peer error distribution list after the call has been disconnected (say
by the rxrpc socket getting closed).
The fix is to complete the process of moving call connection, data
transmission and call disconnection into the I/O thread and thus forcibly
serialising them.
Note that the issue may predate the overhaul to an I/O thread model that
were included in the merge window for v6.2, but the timing is very much
changed by the change given below.
David Howells [Wed, 2 Nov 2022 16:46:13 +0000 (16:46 +0000)]
rxrpc: Move the client conn cache management to the I/O thread
Move the management of the client connection cache to the I/O thread rather
than managing it from the namespace as an aggregate across all the local
endpoints within the namespace.
This will allow a load of locking to be got rid of in a future patch as
only the I/O thread will be looking at the this.
The downside is that the total number of cached connections on the system
can get higher because the limit is now per-local rather than per-netns.
We can, however, keep the number of client conns in use across the entire
netfs and use that to reduce the expiration time of idle connection.
David Howells [Wed, 26 Oct 2022 22:43:00 +0000 (23:43 +0100)]
rxrpc: Move call state changes from recvmsg to I/O thread
Move the call state changes that are made in rxrpc_recvmsg() to the I/O
thread. This means that, thenceforth, only the I/O thread does this and
the call state lock can be removed.
This requires the Rx phase to be ended when the last packet is received,
not when it is processed.
Since this now changes the rxrpc call state to SUCCEEDED before we've
consumed all the data from it, rxrpc_kernel_check_life() mustn't say the
call is dead until the recvmsg queue is empty (unless the call has failed).
David Howells [Fri, 11 Nov 2022 08:35:36 +0000 (08:35 +0000)]
rxrpc: Move call state changes from sendmsg to I/O thread
Move all the call state changes that are made in rxrpc_sendmsg() to the I/O
thread. This is a step towards removing the call state lock.
This requires the switch to the RXRPC_CALL_CLIENT_AWAIT_REPLY and
RXRPC_CALL_SERVER_SEND_REPLY states to be done when the last packet is
decanted from ->tx_sendmsg to ->tx_buffer in the I/O thread, not when it is
added to ->tx_sendmsg by sendmsg().
David Howells [Mon, 19 Dec 2022 15:32:32 +0000 (15:32 +0000)]
rxrpc: Wrap accesses to get call state to put the barrier in one place
Wrap accesses to get the state of a call from outside of the I/O thread in
a single place so that the barrier needed to order wrt the error code and
abort code is in just that place.
Also use a barrier when setting the call state and again when reading the
call state such that the auxiliary completion info (error code, abort code)
can be read without taking a read lock on the call state lock.
David Howells [Wed, 26 Oct 2022 23:16:55 +0000 (00:16 +0100)]
rxrpc: Split out the call state changing functions into their own file
Split out the functions that change the state of an rxrpc call into their
own file. The idea being to remove anything to do with changing the state
of a call directly from the rxrpc sendmsg() and recvmsg() paths and have
all that done in the I/O thread only, with the ultimate aim of removing the
state lock entirely. Moving the code out of sendmsg.c and recvmsg.c makes
that easier to manage.
David Howells [Fri, 21 Oct 2022 08:30:23 +0000 (09:30 +0100)]
rxrpc: Set up a connection bundle from a call, not rxrpc_conn_parameters
Use the information now stored in struct rxrpc_call to configure the
connection bundle and thence the connection, rather than using the
rxrpc_conn_parameters struct.
David Howells [Fri, 21 Oct 2022 07:54:03 +0000 (08:54 +0100)]
rxrpc: Offload the completion of service conn security to the I/O thread
Offload the completion of the challenge/response cycle on a service
connection to the I/O thread. After the RESPONSE packet has been
successfully decrypted and verified by the work queue, offloading the
changing of the call states to the I/O thread makes iteration over the
conn's channel list simpler.
Do this by marking the RESPONSE skbuff and putting it onto the receive
queue for the I/O thread to collect. We put it on the front of the queue
as we've already received the packet for it.
David Howells [Thu, 6 Oct 2022 20:45:42 +0000 (21:45 +0100)]
rxrpc: Tidy up abort generation infrastructure
Tidy up the abort generation infrastructure in the following ways:
(1) Create an enum and string mapping table to list the reasons an abort
might be generated in tracing.
(2) Replace the 3-char string with the values from (1) in the places that
use that to log the abort source. This gets rid of a memcpy() in the
tracepoint.
(3) Subsume the rxrpc_rx_eproto tracepoint with the rxrpc_abort tracepoint
and use values from (1) to indicate the trace reason.
(4) Always make a call to an abort function at the point of the abort
rather than stashing the values into variables and using goto to get
to a place where it reported. The C optimiser will collapse the calls
together as appropriate. The abort functions return a value that can
be returned directly if appropriate.
Note that this extends into afs also at the points where that generates an
abort. To aid with this, the afs sources need to #define
RXRPC_TRACE_ONLY_DEFINE_ENUMS before including the rxrpc tracing header
because they don't have access to the rxrpc internal structures that some
of the tracepoints make use of.
David Howells [Thu, 20 Oct 2022 08:56:36 +0000 (09:56 +0100)]
rxrpc: Clean up connection abort
Clean up connection abort, using the connection state_lock to gate access
to change that state, and use an rxrpc_call_completion value to indicate
the difference between local and remote aborts as these can be pasted
directly into the call state.
David Howells [Thu, 20 Oct 2022 08:08:34 +0000 (09:08 +0100)]
rxrpc: Implement a mechanism to send an event notification to a connection
Provide a means by which an event notification can be sent to a connection
through such that the I/O thread can pick it up and handle it rather than
doing it in a separate workqueue.
This is then used to move the deferred final ACK of a call into the I/O
thread rather than a separate work queue as part of the drive to do all
transmission from the I/O thread.
David Howells [Wed, 12 Oct 2022 16:01:25 +0000 (17:01 +0100)]
rxrpc: Only disconnect calls in the I/O thread
Only perform call disconnection in the I/O thread to reduce the locking
requirement.
This is the first part of a fix for a race that exists between call
connection and call disconnection whereby the data transmission code adds
the call to the peer error distribution list after the call has been
disconnected (say by the rxrpc socket getting closed).
The fix is to complete the process of moving call connection, data
transmission and call disconnection into the I/O thread and thus forcibly
serialising them.
Note that the issue may predate the overhaul to an I/O thread model that
were included in the merge window for v6.2, but the timing is very much
changed by the change given below.
David Howells [Wed, 12 Oct 2022 21:17:56 +0000 (22:17 +0100)]
rxrpc: Only set/transmit aborts in the I/O thread
Only set the abort call completion state in the I/O thread and only
transmit ABORT packets from there. rxrpc_abort_call() can then be made to
actually send the packet.
Further, ABORT packets should only be sent if the call has been exposed to
the network (ie. at least one attempted DATA transmission has occurred for
it).
David Howells [Wed, 2 Nov 2022 10:24:29 +0000 (10:24 +0000)]
rxrpc: Make the local endpoint hold a ref on a connected call
Make the local endpoint and it's I/O thread hold a reference on a connected
call until that call is disconnected. Without this, we're reliant on
either the AF_RXRPC socket to hold a ref (which is dropped when the call is
released) or a queued work item to hold a ref (the work item is being
replaced with the I/O thread).
David Howells [Thu, 20 Oct 2022 22:17:06 +0000 (23:17 +0100)]
rxrpc: Stash the network namespace pointer in rxrpc_local
Stash the network namespace pointer in the rxrpc_local struct in addition
to a pointer to the rxrpc-specific net namespace info. Use this to remove
some places where the socket is passed as a parameter.
Hui Wang [Thu, 5 Jan 2023 03:42:49 +0000 (11:42 +0800)]
net: usb: cdc_ether: add support for Thales Cinterion PLS62-W modem
This modem has 7 interfaces, 5 of them are serial interfaces and are
driven by cdc_acm, while 2 of them are wwan interfaces and are driven
by cdc_ether:
If 0: Abstract (modem)
If 1: Abstract (modem)
If 2: Abstract (modem)
If 3: Abstract (modem)
If 4: Abstract (modem)
If 5: Ethernet Networking
If 6: Ethernet Networking
Without this change, the 2 network interfaces will be named to usb0
and usb1, our QA think the names are confusing and filed a bug on it.
After applying this change, the name will be wwan0 and wwan1, and
they could work well with modem manager.
projects / linux.git / log