- 01 Aug, 2023 13 commits
-
-
Polaris Pi authored
Make sure mwifiex_process_mgmt_packet, mwifiex_process_sta_rx_packet and mwifiex_process_uap_rx_packet, mwifiex_uap_queue_bridged_pkt and mwifiex_process_rx_packet not out-of-bounds access the skb->data buffer. Fixes: 2dbaf751 ("mwifiex: report received management frames to cfg80211") Signed-off-by: Polaris Pi <pinkperfect2021@gmail.com> Reviewed-by: Matthew Wang <matthewmwang@chromium.org> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230723070741.1544662-1-pinkperfect2021@gmail.com
-
Prasurjya Rohan Saikia authored
The 'enhance throughput flow' algorithm is used by default. So older sections of the code are removed so as to always use this new algorithm. Signed-off-by: Prasurjya Rohan Saikia <prasurjya.rohansaikia@microchip.com> Acked-by: Ajay Kathat <ajay.kathat@microchip.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230710094401.235222-1-prasurjya.rohansaikia@microchip.com
-
Ping-Ke Shih authored
The data rate from RX descriptor also uses hardware rate v1 for WiFi 7 chips. The rate code contains three parts -- mode, NSS and MCS. For CCK/OFDM/HT rates, NSS/MCS parts are the same as before. VHT/HE/EHT rates are changed and listed as below: mode NSS MCS V0 [8:7] [6:4] [3:0] V1 [10:8] [7:5] [4:0] Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-11-pkshih@realtek.com
-
Ping-Ke Shih authored
The upcoming WiFi 7 chips support EHT rates, and hardware rate codes are changed too, so modify to adapt the changes. (EHT counters are still zeros in below example) RX count: Legacy: [0, 0, 0, 0] OFDM: [0, 0, 0, 0, 0, 0, 0, 0] HT 0: [0, 0, 0, 0, 0, 0, 0, 0] HT 1: [0, 0, 0, 0, 0, 0, 0, 0] VHT 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] VHT 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] HE 1SS: [0, 0, 42, 0, 43, 90, 75, 0, 26, 20, 260, 7] HE 2SS: [0, 96, 232, 84, 125, 184, 52, 0, 0, 0, 0, 0] EHT 1SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0][0, 0] EHT 2SS: [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0] Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-10-pkshih@realtek.com
-
Ping-Ke Shih authored
WiFi 7 chips have more rate mode (EHT), higher MCS and more bandwidth, so define and use reserved bits to carry these information in C2H events. Also, the SS/MCS encoded bits of VHT and HE are changed, so define V1 masks for them. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-9-pkshih@realtek.com
-
Ping-Ke Shih authored
RA (rate adaptive), a mechanism to select proper rate, is implemented in firmware, and this report is used to tell driver TX rate it is currently using. Use struct to access this report, and doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-8-pkshih@realtek.com
-
Ping-Ke Shih authored
Firmware C2H events contain two-word header which can indicate category, class, function and length of received events. Use struct to access them, and doesn't change logic at all. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-7-pkshih@realtek.com
-
Ping-Ke Shih authored
H2C RA V1 command adds two words to support WiFi 7 chips, which can possibly support up to 4SS rates. Because current chips have only 2SS rates, leave the fields blank for now. The main changes are to set extended bits of EHT mode and bandwidth -- add a bit for EHT mode; add a bit to enumerate 320MHz channel bandwidth. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-6-pkshih@realtek.com
-
Ping-Ke Shih authored
RA (rate adaptive) H2C command is used to tell firmware which rates can be used for specified MAC ID. Basically, this commit doesn't change result. Only change to set two 32-bit instead of continual 8-byte rate masks one by one. Originally, we only set 5-byte masks, because existing WiFi 6 2SS chips only need 5-byte masks. Setting two 32-bit masks will be more efficient and also can support coming WiFi 7 2SS chips containing more rates. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-5-pkshih@realtek.com
-
Zong-Zhe Yang authored
Rate pattern is controlled by 'iw bitrates' to fix rate as desired, and we extend to support v1 rate. 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/20230728070252.66525-4-pkshih@realtek.com
-
Ping-Ke Shih authored
To support EHT rate, hardware rate v1 is introduced. The CCK and OFDM rates are persistent. HT/VHT/HE rates use different rate code from original, and add new code for EHT rates. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-3-pkshih@realtek.com
-
Ping-Ke Shih authored
The coming WiFi 7 chip is 8922AE which uses different hardware rate and register naming rule. Adding a chip_info::chip_gen field can help to do things by generations accordingly. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230728070252.66525-2-pkshih@realtek.com
-
Larry Finger authored
When using compressed firmware, the early firmware load feature will fail. In most cases, the only downside is that if a device has more than one firmware version available, only the last one listed will be loaded. In at least two cases, there is no firmware loaded, and the device fails initialization. See https://github.com/lwfinger/rtw89/issues/259 and https://bugzilla.opensuse.org/show_bug.cgi?id=1212808 for examples of the failure. When firmware_class.dyndbg=+p" added to the kernel boot parameters, the following is found: finger@localhost:~/rtw89>sudo dmesg -t | grep rtw89 firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw-1.bin fw_priv=00000000638862fb rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/5.14.21-150500.53-default/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/5.14.21-150500.53-default/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw-1.bin failed with error -2 firmware_class: __free_fw_priv: fw-rtw89/rtw8852b_fw-1.bin fw_priv=00000000638862fb data=00000000307c30c7 size=0 firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw.bin fw_priv=00000000638862fb rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: Direct firmware load for rtw89/rtw8852b_fw.bin failed with error -2 firmware_class: __free_fw_priv: fw-rtw89/rtw8852b_fw.bin fw_priv=00000000638862fb data=00000000307c30c7 size=0 rtw89_8852be 0000:02:00.0: failed to early request firmware: -2 firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw.bin fw_priv=00000000638862fb rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/5.14.21-150500.53-default/rtw89/rtw8852b_fw.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: Loading firmware from /lib/firmware/rtw89/rtw8852b_fw.bin.xz rtw89_8852be 0000:02:00.0: f/w decompressing rtw89/rtw8852b_fw.bin firmware_class: fw_set_page_data: fw-rtw89/rtw8852b_fw.bin fw_priv=00000000638862fb data=000000004ed6c2f7 size=1035232 rtw89_8852be 0000:02:00.0: Firmware version 0.27.32.1, cmd version 0, type 1 rtw89_8852be 0000:02:00.0: Firmware version 0.27.32.1, cmd version 0, type 3 The key is that firmware version 0.27.32.1 is loaded. With this patch, the following is obtained: firmware_class: __free_fw_priv: fw-rtw89/rtw8852b_fw.bin fw_priv=000000000849addc data=00000000fd3cabe2 size=1035232 firmware_class: fw_name_devm_release: fw_name-rtw89/rtw8852b_fw.bin devm-000000002d8c3343 released firmware_class: __allocate_fw_priv: fw-rtw89/rtw8852b_fw-1.bin fw_priv=000000009e1a6364 rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw-1.bin failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/rtw89/rtw8852b_fw-1.bin.zst failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/updates/rtw89/rtw8852b_fw-1.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: loading /lib/firmware/6.4.3-1-default/rtw89/rtw8852b_fw-1.bin.xz failed for no such file or directory. rtw89_8852be 0000:02:00.0: Loading firmware from /lib/firmware/rtw89/rtw8852b_fw-1.bin.xz rtw89_8852be 0000:02:00.0: f/w decompressing rtw89/rtw8852b_fw-1.bin firmware_class: fw_set_page_data: fw-rtw89/rtw8852b_fw-1.bin fw_priv=000000009e1a6364 data=00000000fd3cabe2 size=1184992 rtw89_8852be 0000:02:00.0: Loaded FW: rtw89/rtw8852b_fw-1.bin, sha256: 8539efc75f513f4585cf0cd6e79e6507da47fce87225f2d0de391a03aefe9ac8 rtw89_8852be 0000:02:00.0: loaded firmware rtw89/rtw8852b_fw-1.bin rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.1, cmd version 0, type 5 rtw89_8852be 0000:02:00.0: Firmware version 0.29.29.1, cmd version 0, type 3 Now, version 0.29.29.1 is loaded. Fixes: ffde7f34 ("wifi: rtw89: add firmware format version to backward compatible with older drivers") Cc: Ping-Ke Shih <pkshih@realtek.com> Cc: Takashi Iwai <tiwai@suse.de> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230724183927.28553-1-Larry.Finger@lwfinger.net
-
- 25 Jul, 2023 14 commits
-
-
Dmitry Antipov authored
Remove unused 'struct gpioh_item'. It seems it was so since commit 5b435de0 ("net: wireless: add brcm80211 drivers"). Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230719083232.158177-1-dmantipov@yandex.ru
-
Johannes Wiesboeck authored
Allow moving the wiphy device for mwififex to a non-inital network namespace. Many wireless drivers enable this flag implicitly by initializing through the generic ieee80211_alloc_hw_nm function. As mwifiex does not utilize this function WIPHY_FLAG_NETNS_OK must be set explicitly. Moving to network namespace and working connection tested using wpa_supplicant from a network namespace as well as from a container on GyroidOS. The hardware was the Toradex Apalis i.MX8QM Board using the Azurewave AW-CM276NF wireless module. Signed-off-by: Johannes Wiesboeck <johannes.wiesboeck@aisec.fraunhofer.de> Reviewed-by: Michael Weiß <michael.weiss@aisec.fraunhofer.de> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230706093437.3380526-1-johannes.wiesboeck@aisec.fraunhofer.de
-
Dmitry Antipov authored
When compiling with gcc 13.1 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following: In function ‘fortify_memcpy_chk’, inlined from ‘mwifiex_construct_tdls_action_frame’ at drivers/net/wireless/marvell/mwifiex/tdls.c:765:3, inlined from ‘mwifiex_send_tdls_action_frame’ at drivers/net/wireless/marvell/mwifiex/tdls.c:856:6: ./include/linux/fortify-string.h:529:25: warning: call to ‘__read_overflow2_field’ declared with attribute warning: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] 529 | __read_overflow2_field(q_size_field, size); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The compiler actually complains on: memmove(pos + ETH_ALEN, &mgmt->u.action.category, sizeof(mgmt->u.action.u.tdls_discover_resp)); and it happens because the fortification logic interprets this as an attempt to overread 1-byte 'u.action.category' member of 'struct ieee80211_mgmt'. To silence this warning, it's enough to pass an address of 'u.action' itself instead of an address of its first member. This also fixes an improper usage of 'sizeof()'. Since 'skb' is extended with 'sizeof(mgmt->u.action.u.tdls_discover_resp) + 1' bytes (where 1 is actually 'sizeof(mgmt->u.action.category)'), I assume that the same number of bytes should be copied. Suggested-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230629085115.180499-2-dmantipov@yandex.ru
-
Dmitry Antipov authored
Prefer 'strscpy()' over 'strlcpy()' in 'mwifiex_init_hw_fw()'. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Brian Norris <briannorris@chromium.org> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230629085115.180499-1-dmantipov@yandex.ru
-
Bitterblue Smith authored
Theoretically this chip can handle 127 clients. Only compile tested but it should work as well as the RTL8188FU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/b2876c56-0ea7-c398-5c9b-635f9f894f2c@gmail.com
-
Bitterblue Smith authored
Theoretically this chip can handle 127 clients. Tested only very briefly but it should work as well as the RTL8188FU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/56c9b186-ba9a-8469-652d-ce1709813e9e@gmail.com
-
Bitterblue Smith authored
Theoretically this chip can handle 15 clients. Tested only very briefly but it should work as well as the RTL8188FU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/ce04a0a1-df72-ea30-f742-8834e01457f5@gmail.com
-
Bitterblue Smith authored
Theoretically this chip can handle 127 clients. Tested only very briefly but it should work as well as the RTL8188FU. Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/ffcabba5-7e9e-674c-ad03-73646b040b96@gmail.com
-
Yueh-Shun Li authored
Spell "transmits" properly. Found by searching for keyword "tranm". Signed-off-by: Yueh-Shun Li <shamrocklee@posteo.net> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230622012627.15050-4-shamrocklee@posteo.net
-
Zhang Shurong authored
If there is a failure during kstrtobool_from_user() rtw89_debug_priv_btc_manual_set should return a negative error code instead of returning the count directly. Fix this bug by returning an error code instead of a count after a failed call of the function "kstrtobool_from_user". Moreover I omitted the label "out" with this source code correction. Fixes: e3ec7017 ("rtw89: add Realtek 802.11ax driver") Signed-off-by: Zhang Shurong <zhang_shurong@foxmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/tencent_1C09B99BD7DA9CAD18B00C8F0F050F540607@qq.com
-
Dmitry Antipov authored
Since all iterators called by 'rtw_iterate_vifs()' never uses 'mac' argument, it may be omitted, and 'struct rtw_vifs_entry' may be simplified accordingly. Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230628072327.167196-4-dmantipov@yandex.ru
-
Dmitry Antipov authored
Drop no longer used 'bulkout_size' of 'struct rtw_usb' as well as related macros from usb.h and leftovers in 'rtw_usb_parse()'. This follows commit 462c8db6 ("wifi: rtw88: usb: drop now unnecessary URB size check"). Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230628072327.167196-3-dmantipov@yandex.ru
-
Dmitry Antipov authored
Drop unused and set but unused 'last_push' of 'struct rtw_txq', 'wireless_set' of 'struct rtw_sta_info', 'usb_txagg_num' of 'struct rtw_usb' and 'n' of 'struct rx_usb_ctrl_block', unused definition of 'struct rtw_timer_list', adjust related code. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230628072327.167196-2-dmantipov@yandex.ru
-
Dmitry Antipov authored
Fix possible crash and memory leak on driver unload by deleting TX purge timer and freeing C2H queue in 'rtw_core_deinit()', shrink critical section in the latter by freeing COEX queue out of TX report lock scope. Reviewed-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Dmitry Antipov <dmantipov@yandex.ru> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230628072327.167196-1-dmantipov@yandex.ru
-
- 24 Jul, 2023 1 commit
-
-
Eric Dumazet authored
IPv6 inet sockets are supposed to have a "struct ipv6_pinfo" field at the end of their definition, so that inet6_sk_generic() can derive from socket size the offset of the "struct ipv6_pinfo". This is very fragile, and prevents adding bigger alignment in sockets, because inet6_sk_generic() does not work if the compiler adds padding after the ipv6_pinfo component. We are currently working on a patch series to reorganize TCP structures for better data locality and found issues similar to the one fixed in commit f5d54767 ("tcp: fix tcp_inet6_sk() for 32bit kernels") Alternative would be to force an alignment on "struct ipv6_pinfo", greater or equal to __alignof__(any ipv6 sock) to ensure there is no padding. This does not look great. v2: fix typo in mptcp_proto_v6_init() (Paolo) Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Chao Wu <wwchao@google.com> Cc: Wei Wang <weiwan@google.com> Cc: Coco Li <lixiaoyan@google.com> Cc: YiFei Zhu <zhuyifei@google.com> Reviewed-by: Simon Horman <simon.horman@corigine.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 23 Jul, 2023 9 commits
-
-
Patrick Rohr authored
This change adds a new sysctl accept_ra_min_rtr_lft to specify the minimum acceptable router lifetime in an RA. If the received RA router lifetime is less than the configured value (and not 0), the RA is ignored. This is useful for mobile devices, whose battery life can be impacted by networks that configure RAs with a short lifetime. On such networks, the device should never gain IPv6 provisioning and should attempt to drop RAs via hardware offload, if available. Signed-off-by: Patrick Rohr <prohr@google.com> Cc: Maciej Żenczykowski <maze@google.com> Cc: Lorenzo Colitti <lorenzo@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
justinstitt@google.com authored
`strncpy` is deprecated for use on NUL-terminated destination strings [1]. Even call sites utilizing length-bounded destination buffers should switch over to using `strtomem` or `strtomem_pad`. In this case, however, the compiler is unable to determine the size of the `data` buffer which renders `strtomem` unusable. Due to this, `strscpy` should be used. It should be noted that most call sites already zero-initialize the destination buffer. However, I've opted to use `strscpy_pad` to maintain the same exact behavior that `strncpy` produced (zero-padded tail up to `len`). Also see [3]. [1]: www.kernel.org/doc/html/latest/process/deprecated.html#strncpy-on-nul-terminated-strings [2]: elixir.bootlin.com/linux/v6.3/source/net/ethtool/ioctl.c#L1944 [3]: manpages.debian.org/testing/linux-manual-4.8/strscpy.9.en.html Link: https://github.com/KSPP/linux/issues/90Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Justin Stitt <justinstitt@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Anjali Kulkarni says: ==================== Process connector bug fixes & enhancements Oracle DB is trying to solve a performance overhead problem it has been facing for the past 10 years and using this patch series, we can fix this issue. Oracle DB runs on a large scale with 100000s of short lived processes, starting up and exiting quickly. A process monitoring DB daemon which tracks and cleans up after processes that have died without a proper exit needs notifications only when a process died with a non-zero exit code (which should be rare). Due to the pmon architecture, which is distributed, each process is independent and has minimal interaction with pmon. Hence fd based solutions to track a process's spawning and exit cannot be used. Pmon needs to detect the abnormal death of a process so it can cleanup after. Currently it resorts to checking /proc every few seconds. Other methods we tried like using system call to reduce the above overhead were not accepted upstream. With this change, we add event based filtering to proc connector module so that DB can only listen to the events it is interested in. A new event type PROC_EVENT_NONZERO_EXIT is added, which is only sent by kernel to a listening application when any process exiting has a non-zero exit status. This change will give Oracle DB substantial performance savings - it takes 50ms to scan about 8K PIDs in /proc, about 500ms for 100K PIDs. DB does this check every 3 secs, so over an hour we save 10secs for 100K PIDs. With this, a client can register to listen for only exit or fork or a mix or all of the events. This greatly enhances performance - currently, we need to listen to all events, and there are 9 different types of events. For eg. handling 3 types of events - 8K-forks + 8K-exits + 8K-execs takes 200ms, whereas handling 2 types - 8K-forks + 8K-exits takes about 150ms, and handling just one type - 8K exits takes about 70ms. Measuring the time using pidfds for monitoring 8K process exits took 4 times longer - 200ms, as compared to 70ms using only exit notifications of proc connector. Hence, we cannot use pidfd for our use case. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. This patch series is organized as follows - Patch 1 : Needed for patch 3 to work. Patch 2 : Needed for patch 3 to work. Patch 3 : Fixes some bugs in proc connector, details in the patch. Patch 4 : Adds event based filtering for performance enhancements. Patch 5 : Allow non-root users access to proc connector events. Patch 6 : Selftest code for proc connector. v9->v10 changes: - Rebased to net-next, re-compiled and re-tested. v8->v9 changes: - Added sha1 ("title") of reversed patch as suggested by Eric Dumazet. v7->v8 changes: - Fixed an issue pointed by Liam Howlett in v7. v6->v7 changes: - Incorporated Liam Howlett's comments on v6 - Incorporated Kalesh Anakkur Purayil's comments v5->v6 changes: - Incorporated Liam Howlett's comments - Removed FILTER define from proc_filter.c and added a "-f" run-time option to run new filter code. - Made proc_filter.c a selftest in tools/testing/selftests/connector v4->v5 changes: - Change the cover letter - Fix a small issue in proc_filter.c v3->v4 changes: - Fix comments by Jakub Kicinski to incorporate root access changes within bind call of connector v2->v3 changes: - Fix comments by Jakub Kicinski to separate netlink (patch 2) (after layering) from connector fixes (patch 3). - Minor fixes suggested by Jakub. - Add new multicast group level permissions check at netlink layer. Split this into netlink & connector layers (patches 6 & 7) v1->v2 changes: - Fix comments by Jakub Kicinski to keep layering within netlink and update kdocs. - Move non-root users access patch last in series so remaining patches can go in first. v->v1 changes: - Changed commit log in patch 4 as suggested by Christian Brauner - Changed patch 4 to make more fine grained access to non-root users - Fixed warning in cn_proc.c, Reported-by: kernel test robot <lkp@intel.com> - Fixed some existing warnings in cn_proc.c ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
Run as ./proc_filter -f to run new filter code. Run without "-f" to run usual proc connector code without the new filtering code. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
There were a couple of reasons for not allowing non-root users access initially - one is there was some point no proper receive buffer management in place for netlink multicast. But that should be long fixed. See link below for more context. Second is that some of the messages may contain data that is root only. But this should be handled with a finer granularity, which is being done at the protocol layer. The only problematic protocols are nf_queue and the firewall netlink. Hence, this restriction for non-root access was relaxed for NETLINK_ROUTE initially: https://lore.kernel.org/all/20020612013101.A22399@wotan.suse.de/ This restriction has also been removed for following protocols: NETLINK_KOBJECT_UEVENT, NETLINK_AUDIT, NETLINK_SOCK_DIAG, NETLINK_GENERIC, NETLINK_SELINUX. Since process connector messages are not sensitive (process fork, exit notifications etc.), and anyone can read /proc data, we can allow non-root access here. However, since process event notification is not the only consumer of NETLINK_CONNECTOR, we can make this change even more fine grained than the protocol level, by checking for multicast group within the protocol. Allow non-root access for NETLINK_CONNECTOR via NL_CFG_F_NONROOT_RECV but add new bind function cn_bind(), which allows non-root access only for CN_IDX_PROC multicast group. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
This patch adds the capability to filter messages sent by the proc connector on the event type supplied in the message from the client to the connector. The client can register to listen for an event type given in struct proc_input. This event based filteting will greatly enhance performance - handling 8K exits takes about 70ms, whereas 8K-forks + 8K-exits takes about 150ms & handling 8K-forks + 8K-exits + 8K-execs takes 200ms. There are currently 9 different types of events, and we need to listen to all of them. Also, measuring the time using pidfds for monitoring 8K process exits took much longer - 200ms, as compared to 70ms using only exit notifications of proc connector. We also add a new event type - PROC_EVENT_NONZERO_EXIT, which is only sent by kernel to a listening application when any process exiting, has a non-zero exit status. This will help the clients like Oracle DB, where a monitoring process wants notfications for non-zero process exits so it can cleanup after them. This kind of a new event could also be useful to other applications like Google's lmkd daemon, which needs a killed process's exit notification. The patch takes care that existing clients using old mechanism of not sending the event type work without any changes. cn_filter function checks to see if the event type being notified via proc connector matches the event type requested by client, before sending(matches) or dropping(does not match) a packet. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
The current proc connector code has the foll. bugs - if there are more than one listeners for the proc connector messages, and one of them deregisters for listening using PROC_CN_MCAST_IGNORE, they will still get all proc connector messages, as long as there is another listener. Another issue is if one client calls PROC_CN_MCAST_LISTEN, and another one calls PROC_CN_MCAST_IGNORE, then both will end up not getting any messages. This patch adds filtering and drops packet if client has sent PROC_CN_MCAST_IGNORE. This data is stored in the client socket's sk_user_data. In addition, we only increment or decrement proc_event_num_listeners once per client. This fixes the above issues. cn_release is the release function added for NETLINK_CONNECTOR. It uses the newly added netlink_release function added to netlink_sock. It will free sk_user_data. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
A new function netlink_release is added in netlink_sock to store the protocol's release function. This is called when the socket is deleted. This can be supplied by the protocol via the release function in netlink_kernel_cfg. This is being added for the NETLINK_CONNECTOR protocol, so it can free it's data when socket is deleted. Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Anjali Kulkarni authored
To use filtering at the connector & cn_proc layers, we need to enable filtering in the netlink layer. This reverses the patch which removed netlink filtering - commit ID for that patch: 549017aa (netlink: remove netlink_broadcast_filtered). Signed-off-by: Anjali Kulkarni <anjali.k.kulkarni@oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
- 22 Jul, 2023 3 commits
-
-
Jakub Kicinski authored
Jakub Kicinski says: ==================== net: page_pool: remove page_pool_release_page() page_pool_return_page() is a historic artefact from before recycling of pages attached to skbs was supported. Theoretical uses for it may be thought up but in practice all existing users can be converted to use skb_mark_for_recycle() instead. This code was previously posted as part of the memory provider RFC. https://lore.kernel.org/all/20230707183935.997267-1-kuba@kernel.org/ ==================== Link: https://lore.kernel.org/r/20230720010409.1967072-1-kuba@kernel.orgSigned-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Now that page_pool_release_page() is not exported we can merge it with page_pool_return_page(). I believe that the "Do not replace this with page_pool_return_page()" comment was there in case page_pool_return_page() was not inlined, to avoid two function calls. Acked-by: Jesper Dangaard Brouer <hawk@kernel.org> Reviewed-by: Yunsheng Lin <linyunsheng@huawei.com> Link: https://lore.kernel.org/r/20230720010409.1967072-5-kuba@kernel.orgReviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
There seems to be no user calling page_pool_release_page() for legit reasons, all the users simply haven't been converted to skb-based recycling, yet. Previous changes converted them. Update the docs, and unexport the function. Link: https://lore.kernel.org/r/20230720010409.1967072-4-kuba@kernel.orgReviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-