summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2020-12-11mac80211: fix a mistake check for rx_stats updateWen Gong1-1/+1
It should be !is_multicast_ether_addr() in ieee80211_rx_h_sta_process() for the rx_stats update, below commit remove the !, this patch is to change it back. It lead the rx rate "iw wlan0 station dump" become invalid for some scenario when IEEE80211_HW_USES_RSS is set. Fixes: 09a740ce352e ("mac80211: receive and process S1G beacons") Signed-off-by: Wen Gong <wgong@codeaurora.org> Link: https://lore.kernel.org/r/1607483189-3891-1-git-send-email-wgong@codeaurora.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: mlme: save ssid info to ieee80211_bss_conf while assocWen Gong1-0/+5
The ssid info of ieee80211_bss_conf is filled in ieee80211_start_ap() for AP mode. For STATION mode, it is empty, save the info from struct ieee80211_mgd_assoc_data, the struct ieee80211_mgd_assoc_data will be freed after assoc, so the ssid info of ieee80211_mgd_assoc_data can not access after assoc, save ssid info to ieee80211_bss_conf, then ssid info can be still access after assoc. Signed-off-by: Wen Gong <wgong@codeaurora.org> Link: https://lore.kernel.org/r/1607312195-3583-2-git-send-email-wgong@codeaurora.org [reset on disassoc] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: Update rate control on channel changeIlan Peer1-0/+61
A channel change or a channel bandwidth change can impact the rate control logic. However, the rate control logic was not updated before/after such a change, which might result in unexpected behavior. Fix this by updating the stations rate control logic when the corresponding channel context changes. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.600d967fe3c9.I48305f25cfcc9c032c77c51396e9e9b882748a86@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: don't filter out beacons once we start CSAEmmanuel Grumbach1-0/+1
I hit a bug in which we started a CSA with an action frame, but the AP changed its mind and didn't change the beacon. The CSA wasn't cancelled and we lost the connection. The beacons were ignored because they never changed: they never contained any CSA IE. Because they never changed, the CRC of the beacon didn't change either which made us ignore the beacons instead of processing them. Now what happens is: 1) beacon has CRC X and it is valid. No CSA IE in the beacon 2) as long as beacon's CRC X, don't process their IEs 3) rx action frame with CSA 4) invalidate the beacon's CRC 5) rx beacon, CRC is still X, but now it is invalid 6) process the beacon, detect there is no CSA IE 7) abort CSA Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.83470b8407e6.I739b907598001362744692744be15335436b8351@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: Fix calculation of minimal channel widthIlan Peer2-5/+6
When calculating the minimal channel width for channel context, the current operation Rx channel width of a station was used and not the overall channel width capability of the station, i.e., both for Tx and Rx. Fix ieee80211_get_sta_bw() to use the maximal channel width the station is capable. While at it make the function static. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.4387040b99a0.I74bcf19238f75a5960c4098b10e355123d933281@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: ignore country element TX power on 6 GHzJohannes Berg1-1/+9
Updates to the 802.11ax draft are coming that deprecate the country element in favour of the transmit power envelope element, and make the maximum transmit power level field in the triplets reserved, so if we parse them we'd use 0 dBm transmit power. Follow suit and completely ignore the element on 6 GHz for purposes of determining TX power. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.9abf9f6b4f88.Icb6e52af586edcc74f1f0360e8f6fc9ef2bfe8f5@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: use bitfield helpers for BA session action framesJohannes Berg2-10/+10
Use the appropriate bitfield helpers for encoding and decoding the capability field in the BA session action frames instead of open-coding the shifts/masks. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.0c46e5097cc0.I06e75706770c40b9ba1cabd1f8a78ab7a05c5b73@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: support Rx timestamp calculation for all preamble typesAvraham Stern2-8/+67
Add support for calculating the Rx timestamp for HE frames. Since now all frame types are supported, allow setting the Rx timestamp regardless of the frame type. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.4786559af475.Ia54486bb0a12e5351f9d5c60ef6fcda7c9e7141c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: don't set set TDLS STA bandwidth wider than possibleJohannes Berg1-4/+10
When we set up a TDLS station, we set sta->sta.bandwidth solely based on the capabilities, because the "what's the current bandwidth" check is bypassed and only applied for other types of stations. This leads to the unfortunate scenario that the sta->sta.bandwidth is 160 MHz if both stations support it, but we never actually configure this bandwidth unless the AP is already using 160 MHz; even for wider bandwidth support we only go up to 80 MHz (at least right now.) For iwlwifi, this can also lead to firmware asserts, telling us that we've configured the TX rates for a higher bandwidth than is actually available due to the PHY configuration. For non-TDLS, we check against the interface's requested bandwidth, but we explicitly skip this check for TDLS to cope with the wider BW case. Change this to (a) still limit to the TDLS peer's own chandef, which gets factored into the overall PHY configuration we request from the driver, and (b) limit it to when the TDLS peer is authorized, because it's only factored into the channel context in this case. Fixes: 504871e602d9 ("mac80211: fix bandwidth computation for TDLS peers") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.fcc7d29c4590.I11f77e9e25ddf871a3c8d5604650c763e2c5887a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: support driver-based disconnect with reconnect hintJohannes Berg4-20/+87
Support the driver indicating that a disconnection needs to be performed, and pass through the reconnect hint in this case. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.5c8dab7a22a0.I58459fdf6968b16c90cab9c574f0f04ca22b0c79@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: support immediate reconnect request hintJohannes Berg7-29/+55
There are cases where it's necessary to disconnect, but an immediate reconnection is desired. Support a hint to userspace that this is the case, by including a new attribute in the deauth or disassoc event. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.58d33941fb9d.I0e7168c205c7949529c8e3b86f3c9b12c01a7017@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: use struct assignment for he_obss_pdJohannes Berg1-2/+1
Use a struct assignment here, which is clearer than the memcpy() and type-safe as well. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.2ab3aad7d5fc.Iaca4ee6db651b7de17e4351f4be7973ff8600186@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: remove struct ieee80211_he_bss_colorJohannes Berg2-15/+1
We don't really use this struct, we're now using struct cfg80211_he_bss_color instead. Change the one place in mac80211 that's using the old name to use struct assignment instead of memcpy() and thus remove the wrong sizeof while at it. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201206145305.f6698d97ae4e.Iba2dffcb79c4ab80bde7407609806010b55edfdf@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11nl80211: validate key indexes for cfg80211_registered_deviceAnant Thazhemadam3-11/+49
syzbot discovered a bug in which an OOB access was being made because an unsuitable key_idx value was wrongly considered to be acceptable while deleting a key in nl80211_del_key(). Since we don't know the cipher at the time of deletion, if cfg80211_validate_key_settings() were to be called directly in nl80211_del_key(), even valid keys would be wrongly determined invalid, and deletion wouldn't occur correctly. For this reason, a new function - cfg80211_valid_key_idx(), has been created, to determine if the key_idx value provided is valid or not. cfg80211_valid_key_idx() is directly called in 2 places - nl80211_del_key(), and cfg80211_validate_key_settings(). Reported-by: syzbot+49d4cab497c2142ee170@syzkaller.appspotmail.com Tested-by: syzbot+49d4cab497c2142ee170@syzkaller.appspotmail.com Suggested-by: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Link: https://lore.kernel.org/r/20201204215825.129879-1-anant.thazhemadam@gmail.com Cc: stable@vger.kernel.org [also disallow IGTK key IDs if no IGTK cipher is supported] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: include block-tx flag in channel switch started eventJohannes Berg5-10/+17
In the NL80211_CMD_CH_SWITCH_STARTED_NOTIFY event, include the NL80211_ATTR_CH_SWITCH_BLOCK_TX flag attribute if block-tx was requested by the AP. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.8953ef22cc64.Ifee9cab337a4369938545920ba5590559e91327a@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: disallow band-switch during CSAJohannes Berg1-3/+15
If the AP advertises a band switch during CSA, we will not have the right information to continue working with it, since it will likely (have to) change its capabilities and we don't track any capability changes at all. Additionally, we store e.g. supported rates per band, and that information would become invalid. Since this is a fringe scenario, just disconnect explicitly. Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.0e2327107c06.I461adb07704e056b054a4a7c29b80c95a9f56637@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11ieee80211: update reduced neighbor report TBTT info lengthAvraham Stern1-4/+4
A new field (20MHz PSD - 1 byte) was added to the RNR TBTT info field. Adjust the expected TBTT info length accordingly. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.b503adccce6a.Ie684e1d3039c111bf2d521bf762aaec3f7a24d2e@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: Save the regulatory domain when setting custom regulatoryIlan Peer1-0/+8
When custom regulatory was set, only the channels setting was updated, but the regulatory domain was not saved. Fix it by saving it. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.290fa5c5568a.Ic5732aa64de6ee97ae3578bd5779fc723ba489d1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11nl80211: always accept scan request with the duration setAvraham Stern1-6/+0
Accept a scan request with the duration set even if the driver does not support setting the scan dwell. The duration can be used as a hint to the driver, but the driver may use its internal logic for setting the scan dwell. Signed-off-by: Avraham Stern <avraham.stern@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.9491a12f9226.Ia9c5b24fcefc5ce5592537507243391633a27e5f@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: Update TSF and TSF BSSID for multi BSSIlan Peer1-0/+3
When a new BSS entry is created based on multi BSS IE, the TSF and the TSF BSSID were not updated. Fix it. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.8377d5063827.I6f2011b6017c2ad507c61a3f1ca03b7177a46e32@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: scan PSC channels in case of scan with wildcard SSIDAyala Beker1-10/+8
In case of scan request with wildcard SSID, or in case of more than one SSID in scan request, need to scan PSC channels even though all the co-located APs found during the legacy bands scan indicated that all the APs in their ESS are co-located, as we might find different networks on the PSC channels. Signed-off-by: Ayala Beker <ayala.beker@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.736415a9ca5d.If5b3578ae85e11a707a5da07e66ba85928ba702c@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: Skip entries with SAE H2E only membership selectorIlan Peer1-3/+4
When parsing supported rates IE. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.8228e2be791e.I626c93241fef66bc71aa0cb9719aba1b11232cf1@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: Parse SAE H2E only membership selectorIlan Peer3-1/+5
This extends the support for drivers that rebuild IEs in the FW (same as with HT/VHT/HE). Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.4012647275f3.I1a93ae71c57ef0b6f58f99d47fce919d19d65ff0@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: support MIC error/replay detected counters driver updateJohannes Berg2-0/+69
Support the driver incrementing MIC error and replay detected counters when having detected a bad frame, if it drops it directly instead of relying on mac80211 to do the checks. These are then exposed to userspace, though currently only in some cases and in debugfs. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.fb59be9c6de8.Ife2260887366f585afadd78c983ebea93d2bb54b@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: he: remove non-bss-conf fields from bss_confShaul Triebitz2-10/+0
ack_enabled and multi_sta_back_32bit are station capabilities and should not be in the bss_conf structure. Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Link: https://lore.kernel.org/r/iwlwifi.20201129172929.69a7f7753444.I405c4b5245145e24577512c477f19131d4036489@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: remove trailing semicolon in macro definitionsTom Rix4-6/+6
The macro uses should have (and already have) the semicolon. Signed-off-by: Tom Rix <trix@redhat.com> Link: https://lore.kernel.org/r/20201127193842.2876355-1-trix@redhat.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11nl80211: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/fe5afd456a1244751177e53359d3dd149a63a873.1605896060.git.gustavoars@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11mac80211: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+2
In preparation to enable -Wimplicit-fallthrough for Clang, fix multiple warnings by explicitly adding multiple break statements instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/1a9c4e8248e76e1361edbe2471a68773d87f0b67.1605896060.git.gustavoars@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: Fix fall-through warnings for ClangGustavo A. R. Silva1-0/+1
In preparation to enable -Wimplicit-fallthrough for Clang, fix a warning by explicitly adding a break statement instead of letting the code fall through to the next case. Link: https://github.com/KSPP/linux/issues/115 Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/ed94a115106fa9c6df94d09b2a6c5791c618c4f2.1605896059.git.gustavoars@kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11cfg80211: fix callback type mismatches in wext-compatSami Tolvanen1-32/+71
Instead of casting callback functions to type iw_handler, which trips indirect call checking with Clang's Control-Flow Integrity (CFI), add stub functions with the correct function type for the callbacks. Reported-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201117205902.405316-1-samitolvanen@google.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11net: wireless: make a const array static, makes object smallerColin Ian King1-1/+1
Don't populate the const array bws on the stack but instead it static. Makes the object code smaller by 80 bytes: Before: text data bss dec hex filename 85694 16865 1216 103775 1955f ./net/wireless/reg.o After: text data bss dec hex filename 85518 16961 1216 103695 1950f ./net/wireless/reg.o (gcc version 10.2.0) Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20201116181636.362729-1-colin.king@canonical.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11net: mac80211: use core API for updating TX/RX statsLev Stipakov2-27/+7
Commits d3fd65484c781 ("net: core: add dev_sw_netstats_tx_add") 451b05f413d3f ("net: netdevice.h: sw_netstats_rx_add helper) have added API to update net device per-cpu TX/RX stats. Use core API instead of ieee80211_tx/rx_stats(). Signed-off-by: Lev Stipakov <lev@openvpn.net> Reviewed-by: Heiner Kallweit <hkallweit1@gmail.com> Link: https://lore.kernel.org/r/20201113214623.144663-1-lev@openvpn.net Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11rfkill: add a reason to the HW rfkill stateEmmanuel Grumbach3-9/+72
The WLAN device may exist yet not be usable. This can happen when the WLAN device is controllable by both the host and some platform internal component. We need some arbritration that is vendor specific, but when the device is not available for the host, we need to reflect this state towards the user space. Add a reason field to the rfkill object (and event) so that userspace can know why the device is in rfkill: because some other platform component currently owns the device, or because the actual hw rfkill signal is asserted. Capable userspace can now determine the reason for the rfkill and possibly do some negotiation on a side band channel using a proprietary protocol to gain ownership on the device in case the device is owned by some other component. When the host gains ownership on the device, the kernel can remove the RFKILL_HARD_BLOCK_NOT_OWNER reason and the hw rfkill state will be off. Then, the userspace can bring the device up and start normal operation. The rfkill_event structure is enlarged to include the additional byte, it is now 9 bytes long. Old user space will ask to read only 8 bytes so that the kernel can know not to feed them with more data. When the user space writes 8 bytes, new kernels will just read what is present in the file descriptor. This new byte is read only from the userspace standpoint anyway. If a new user space uses an old kernel, it'll ask to read 9 bytes but will get only 8, and it'll know that it didn't get the new state. When it'll write 9 bytes, the kernel will again ignore this new byte which is read only from the userspace standpoint. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://lore.kernel.org/r/20201104134641.28816-1-emmanuel.grumbach@intel.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2020-12-11Merge branch 'add-ppp_generic-ioctls-to-bridge-channels'David S. Miller3-3/+167
Tom Parkin says: ==================== add ppp_generic ioctl(s) to bridge channels Following on from my previous RFC[1], this series adds two ioctl calls to the ppp code to implement "channel bridging". When two ppp channels are bridged, frames presented to ppp_input() on one channel are passed to the other channel's ->start_xmit function for transmission. The primary use-case for this functionality is in an L2TP Access Concentrator where PPP frames are typically presented in a PPPoE session (e.g. from a home broadband user) and are forwarded to the ISP network in a PPPoL2TP session. The two new ioctls, PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN form a symmetric pair. Userspace code testing and illustrating use of the ioctl calls is available in the go-l2tp[2] and l2tp-ktest[3] repositories. [1]. Previous RFC series: https://lore.kernel.org/netdev/20201106181647.16358-1-tparkin@katalix.com/ [2]. go-l2tp: a Go library for building L2TP applications on Linux systems. Support for the PPPIOCBRIDGECHAN ioctl is on a branch: https://github.com/katalix/go-l2tp/tree/tp_002_pppoe_2 [3]. l2tp-ktest: a test suite for the Linux Kernel L2TP subsystem. Support for the PPPIOCBRIDGECHAN ioctl is on a branch: https://github.com/katalix/l2tp-ktest/tree/tp_ac_pppoe_tests_2 Changelog: v4: * Fix NULL-pointer access in PPPIOCBRIDGECHAN in the case that the ID of the channel to be bridged wasn't found. * Add comment in ppp_unbridge_channels to better document the unbridge process. v3: * Use rcu_dereference_protected for accessing struct channel 'bridge' field during updates with lock 'upl' held. * Avoid race in ppp_unbridge_channels by ensuring that each channel in the bridge points to it's peer before decrementing refcounts. v2: * Add missing __rcu annotation to struct channel 'bridge' field in order to squash a sparse warning from a C=1 build * Integrate review comments from gnault@redhat.com * Have ppp_unbridge_channels return -EINVAL if the channel isn't part of a bridge: this better aligns with the return code from ppp_disconnect_channel. * Improve docs update by including information on ioctl arguments and error return codes. ==================== Reviewed-by: Guillaume Nault <gnault@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11docs: update ppp_generic.rst to document new ioctlsTom Parkin1-0/+16
Add documentation of the newly-added PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctls. Signed-off-by: Tom Parkin <tparkin@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11ppp: add PPPIOCBRIDGECHAN and PPPIOCUNBRIDGECHAN ioctlsTom Parkin2-3/+151
This new ioctl pair allows two ppp channels to be bridged together: frames arriving in one channel are transmitted in the other channel and vice versa. The practical use for this is primarily to support the L2TP Access Concentrator use-case. The end-user session is presented as a ppp channel (typically PPPoE, although it could be e.g. PPPoA, or even PPP over a serial link) and is switched into a PPPoL2TP session for transmission to the LNS. At the LNS the PPP session is terminated in the ISP's network. When a PPP channel is bridged to another it takes a reference on the other's struct ppp_file. This reference is dropped when the channels are unbridged, which can occur either explicitly on userspace calling the PPPIOCUNBRIDGECHAN ioctl, or implicitly when either channel in the bridge is unregistered. In order to implement the channel bridge, struct channel is extended with a new field, 'bridge', which points to the other struct channel making up the bridge. This pointer is RCU protected to avoid adding another lock to the data path. To guard against concurrent writes to the pointer, the existing struct channel lock 'upl' coverage is extended rather than adding a new lock. The 'upl' lock is used to protect the existing unit pointer. Since the bridge effectively replaces the unit (they're mutually exclusive for a channel) it makes coding easier to use the same lock to cover them both. Signed-off-by: Tom Parkin <tparkin@katalix.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11rtnetlink: RCU-annotate both dimensions of rtnl_msg_handlersJakub Kicinski1-11/+13
We use rcu_assign_pointer to assign both the table and the entries, but the entries are not marked as __rcu. This generates sparse warnings. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11Revert "macb: support the two tx descriptors on at91rm9200"Willy Tarreau2-40/+8
This reverts commit 0a4e9ce17ba77847e5a9f87eed3c0ba46e3f82eb. The code was developed and tested on an MSC313E SoC, which seems to be half-way between the AT91RM9200 and the AT91SAM9260 in that it supports both the 2-descriptors mode and a Tx ring. It turns out that after the code was merged I could notice that the controller would sometimes lock up, and only when dealing with sustained bidirectional transfers, in which case it would report a Tx overrun condition right after having reported being ready, and will stop sending even after the status is cleared (a down/up cycle fixes it though). After adding lots of traces I couldn't spot a sequence pattern allowing to predict that this situation would happen. The chip comes with no documentation and other bits are often reported with no conclusive pattern either. It is possible that my change is wrong just like it is possible that the controller on the chip is bogus or at least unpredictable based on existing docs from other chips. I do not have an RM9200 at hand to test at the moment and a few tests run on a more recent 9G20 indicate that this code path cannot be used there to test the code on a 3rd platform. Since the MSC313E works fine in the single-descriptor mode, and that people using the old RM9200 very likely favor stability over performance, better revert this patch until we can test it on the original platform this part of the driver was written for. Note that the reverted patch was actually tested on MSC313E. Cc: Nicolas Ferre <nicolas.ferre@microchip.com> Cc: Claudiu Beznea <claudiu.beznea@microchip.com> Cc: Daniel Palmer <daniel@0x0f.com> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com> Link: https://lore.kernel.org/netdev/20201206092041.GA10646@1wt.eu/ Signed-off-by: Willy Tarreau <w@1wt.eu> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11net: qualcomm: rmnet: Update rmnet device MTU based on real deviceSubash Abhinov Kasiviswanathan4-3/+90
Packets sent by rmnet to the real device have variable MAP header lengths based on the data format configured. This patch adds checks to ensure that the real device MTU is sufficient to transmit the MAP packet comprising of the MAP header and the IP packet. This check is enforced when rmnet devices are created and updated and during MTU updates of both the rmnet and real device. Additionally, rmnet devices now have a default MTU configured which accounts for the real device MTU and the headroom based on the data format. Signed-off-by: Sean Tranchetti <stranche@codeaurora.org> Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org> Tested-by: Loic Poulain <loic.poulain@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11net: lapbether: Consider it successful if (dis)connecting when already ↵Xie He1-2/+11
(dis)connected When the upper layer instruct us to connect (or disconnect), but we have already connected (or disconnected), consider this operation successful rather than failed. This can help the upper layer to correct its record about whether we are connected or not here in layer 2. The upper layer may not have the correct information about whether we are connected or not. This can happen if this driver has already been running for some time when the "x25" module gets loaded. Another X.25 driver (hdlc_x25) is already doing this, so we make this driver do this, too. Cc: Martin Schiller <ms@dev.tdt.de> Signed-off-by: Xie He <xie.he.0141@gmail.com> Acked-by: Martin Schiller <ms@dev.tdt.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11igc: Add new device IDSasha Neftin3-0/+3
Add new device ID for the next step of the silicon and reflect the I226_K part. Signed-off-by: Sasha Neftin <sasha.neftin@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11tcp: correctly handle increased zerocopy args struct sizeArjun Roy1-2/+2
A prior patch increased the size of struct tcp_zerocopy_receive but did not update do_tcp_getsockopt() handling to properly account for this. This patch simply reintroduces content erroneously cut from the referenced prior patch that handles the new struct size. Fixes: 18fb76ed5386 ("net-zerocopy: Copy straggler unaligned data for TCP Rx. zerocopy.") Signed-off-by: Arjun Roy <arjunroy@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Soheil Hassas Yeganeh <soheil@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11net: mediatek: simplify the return expression of mtk_gmac_sgmii_path_setup()Zheng Yongjun1-6/+2
Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-11net/mlx4: simplify the return expression of mlx4_init_srq_table()Zheng Yongjun1-7/+2
Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10net: stmmac: simplify the return tc_delete_knode()Zheng Yongjun1-8/+2
Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10Merge tag 'linux-can-next-for-5.11-20201210' of ↵David S. Miller10-48/+242
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next Marc Kleine-Budde says: ==================== pull-request: can-next 2020-12-10 here's a pull request of 7 patches for net-next/master. The first patch is by Oliver Hartkopp for the CAN ISOTP, which adds support for functional addressing. A patch by Antonio Quartulli removes an unneeded unlikely() annotation from the rx-offload helper. The next three patches target the m_can driver. Sean Nyekjaers's patch removes a double clearing of clock stop request bit, Patrik Flykt's patch moves the runtime PM enable/disable to m_can_platform and Jarkko Nikula's patch adds a PCI glue code driver. Fabio Estevam's patch converts the flexcan driver to DT only. And Manivannan Sadhasivam's patchd for the mcp251xfd driver adds internal loopback mode support. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10vxlan: avoid double unlikely() notation when using IS_ERR()Antonio Quartulli1-1/+1
The definition of IS_ERR() already applies the unlikely() notation when checking the error status of the passed pointer. For this reason there is no need to have the same notation outside of IS_ERR() itself. Clean up code by removing redundant notation. Signed-off-by: Antonio Quartulli <a@unstable.cc> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-12-10can: mcp251xfd: Add support for internal loopback modeManivannan Sadhasivam1-4/+7
MCP251xFD supports internal loopback mode which can be used to verify CAN functionality in the absence of a real CAN device. Link: https://lore.kernel.org/r/20201201054019.11012-1-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> [mkl: mcp251xfd_get_normal_mode(): move CAN_CTRLMODE_LOOPBACK check to front] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-12-10can: flexcan: convert the driver to DT-onlyFabio Estevam1-17/+1
The flexcan driver runs only on DT platforms, so simplify the code by using of_device_get_match_data() to retrieve the driver data and also by removing the unused id_table. Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201128132855.7724-1-festevam@gmail.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2020-12-10can: m_can: add PCI glue driver for Intel Elkhart LakeJarkko Nikula3-0/+194
Add support for M_CAN controller on Intel Elkhart Lake attached to the PCI bus. It integrates the Bosch M_CAN controller with Message RAM and the wrapper IP block with additional registers which all of them are within the same MMIO range. Currently only interrupt control register from wrapper IP is used and the MRAM configuration is expected to come from the firmware via "bosch,mram-cfg" device property and parsed by m_can.c core. Initial implementation is done by Felipe Balbi while he was working at Intel with later changes from Raymond Tan and me. Co-developed-by: Felipe Balbi (Intel) <balbi@kernel.org> Co-developed-by: Raymond Tan <raymond.tan@intel.com> Signed-off-by: Felipe Balbi (Intel) <balbi@kernel.org> Signed-off-by: Raymond Tan <raymond.tan@intel.com> Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Link: https://lore.kernel.org/r/20201117160827.3636264-1-jarkko.nikula@linux.intel.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>