The alignment check was wrong (e.g. & 4 instead of & 3), and the logic
was also inefficient if the length was not a multiple of 4, since it
would needlessly fall back to copying the entire buffer bytewise.
We already have a perfectly good memcpy_toio function, so just call that
instead of rolling our own copy logic here. brcmf_pcie_init_ringbuffers
was already using it anyway.
Fixes: 9e37f045d5 ("brcmfmac: Adding PCIe bus layer support.")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220131160713.245637-6-marcan@marcan.st
Move one of the declarations from sdio.c to pcie.c, since it makes no
sense in the former (SDIO support is optional), and add missing ones.
Fixes: 75729e110e ("brcmfmac: expose firmware config files through modinfo")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220131160713.245637-5-marcan@marcan.st
If boardrev is missing from the NVRAM we add a default one, but this
might need more space in the output buffer than was allocated. Ensure
we have enough padding for this in the buffer.
Fixes: 46f2b38a91 ("brcmfmac: insert default boardrev in nvram data if missing")
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220131160713.245637-3-marcan@marcan.st
This avoids leaking memory if brcmf_chip_get_raminfo fails. Note that
the CLM blob is released in the device remove path.
Fixes: 82f93cf46d ("brcmfmac: get chip's default RAM info during PCIe setup")
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Cc: stable@vger.kernel.org
Signed-off-by: Hector Martin <marcan@marcan.st>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220131160713.245637-2-marcan@marcan.st
Variable ul_encalgo is initialized with a value that is never read,
it is being re-assigned a new value in every case in the following
switch statement. The initialization is redundant and can be removed.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220130223714.6999-1-colin.i.king@gmail.com
The coccinelle report
./include/linux/ssb/ssb_driver_gige.h:98:8-9:
WARNING: return of 0/1 in function
'ssb_gige_must_flush_posted_writes' with return type bool
Return statements in functions returning bool should use true/false
instead of 1/0.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Yang Guang <yang.guang5@zte.com.cn>
Signed-off-by: David Yang <davidcomponentone@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/fa4f1fa737e715eb62a85229ac5f12bae21145cf.1642065490.git.davidcomponentone@gmail.com
As the possible failure of the ioremap(), the 'local->sram' and other
two could be NULL.
Therefore it should be better to check it in order to avoid the later
dev_dbg.
Fixes: 1da177e4c3 ("Linux-2.6.12-rc2")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211230022926.1846757-1-jiasheng@iscas.ac.cn
Don't populate the read-only array queue_id_to_wmm_aci on the stack
but instead make it static. Also makes the object code a little smaller.
Signed-off-by: Colin Ian King <colin.i.king@gmail.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220109230921.58766-1-colin.i.king@gmail.com
Ping-Ke Shih answered[1] a question for a user about an rtl8821ce device that
reported RFE 6, which the driver did not support. Ping-Ke suggested a possible
fix, but the user never reported back.
A second user discovered the above thread and tested the proposed fix.
Accordingly, I am pushing this change, even though I am not the author.
[1] https://lore.kernel.org/linux-wireless/3f5e2f6eac344316b5dd518ebfea2f95@realtek.com/
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Reported-and-tested-by: masterzorag <masterzorag@gmail.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107024739.20967-1-Larry.Finger@lwfinger.net
Previously we allocated less memory than actual required, overwrite
to the buffer causes the mm module to complaint and raise access
violation faults. Along with potential memory leaks when returned
early. Fix these by passing the correct size and proper deinit flow.
Fixes: 10d162b2ed ("rtw88: 8822c: add ieee80211_ops::hw_scan")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220121070813.9656-4-pkshih@realtek.com
Upon hw scan completion, idle mode is not re-entered. This might
increase power consumption under no link mode. Fix this by adding the
re-enter flow. We need another work for this since enter_ips waits
for c2h_work to finish, which might lead to deadlock if caller is in
the same work.
Fixes: 10d162b2ed ("rtw88: 8822c: add ieee80211_ops::hw_scan")
Signed-off-by: Po-Hao Huang <phhuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220121070813.9656-3-pkshih@realtek.com
ieee80211_probereq_get() can return NULL. Pointer skb should be checked
for validty before use. If it is not valid, list of skbs needs to be
freed.
Fixes: 10d162b2ed ("rtw88: 8822c: add ieee80211_ops::hw_scan")
Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220121070813.9656-2-pkshih@realtek.com
CYW43570 is a 3-antenna, 2x2 MIMO,802.11a/b/g/n/ac, PCIe 3.0 for WLAN.
It is BT/WIFI combo.
Signed-off-by: Soontak Lee <soontak.lee@cypress.com>
Signed-off-by: Chi-Hsien Lin <chi-hsien.lin@infineon.com>
Signed-off-by: Ian Lin <ian.lin-ee@infineon.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211229035144.9205-1-ian.lin-ee@infineon.com
This is a second attempt at honering the country code send out by access
points. This was first added in commit b0b524f079 ("brcmfmac: use
ISO3166 country code and 0 rev as fallback").
Subsequently this was reverted in commit 151a7c12c4 ("Revert "brcmfmac:
use ISO3166 country code and 0 rev as fallback""), because it was causing
issues with AP mode on some brcmfmac models (specifically on BCM4359/9).
Many devices ship with a nvram ccode value of X2/XT/XU/XV/ALL which are
all special world-wide compatibility ccode-s. Most of these world-wide
ccode-s allow passive scan mode only for 2.4GHz channels 12-14,
only enabling them when an AP is seen on them.
But at least on brcmfmac43455 devices this is not working correctly, these
do not see accesspoints on channels 12-14 unless the ccode is changes to
a country where these channels are allowed.
Translating received country codes to an ISO3166 country code and 0 rev
ccreq fixes devices using a brcmfmac43455 with a X2/XT/XU/XV/ALL ccode
not seeing accesspoints on channels 12-14.
To avoid this causing issues on other brcmfmac models again, the
fallback is limited to only brcmfmac4345* chips this time.
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Soeren Moch <smoch@web.de>
Cc: Fabio Aiuto <fabioaiuto83@gmail.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Soeren Moch <smoch@web.de> # on BCM4359/9
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20211218185643.158182-1-hdegoede@redhat.com
In the past we use dbi function of wifi mac to read/write
pci config space, but the function will be remove in new
chip. So use kernel api pci_read/write_config_byte instead.
Signed-off-by: Chin-Yen Lee <timlee@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/20220121075555.12457-2-pkshih@realtek.com
DIG, which is short for dynamic initial gain, is used to adjust gain to get
good RX performance. CCK PD feature, a mechanism that adjusts 802.11b CCK
packet detection(PD) power threshold based on environment noisy level in
order to avoid false alarm. Also, refine related variable naming.
Signed-off-by: Johnson Lin <johnson.lin@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/20220121075555.12457-1-pkshih@realtek.com
Call to dle_dfi_qempty might fail, leaving qempty.qempty untouched, which
is latter used to control the for loop. If that happens, it's not
initialized anywhere.
Initialize it so the loop doesn't iterate unless it's modified by the
call to dle_dfi_qempty.
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220113094253.73370-1-ihuguet@redhat.com
Make stuffs related to channel be collected in channel_params,
and encapsulate the corresponding decision in get_channel_params().
Then, functions that takes channel_params can also notice subband type.
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/20220113011042.6705-2-pkshih@realtek.com
For next chipset which can support 6G band, we add the handling
of ieee80211_supported_band for 6G band in advance. And a bitmap,
support_bands, is added to rtw89_chip_info to declare which
NL80211_BAND_* are supported. With the chipset's declaration,
we register the corresponding instances of ieee80211_supported_band
with wiphy.
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/20220113011042.6705-1-pkshih@realtek.com
One mac_id is corresponding to one connected station, and port ID is a
ID of virtual interfaces. With proper mac_id and port ID, firmware and
hardware can handle a packet with correct context.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-12-pkshih@realtek.com
If a packet we are going to send is broadcast/multicast and certain STAs
are in sleep mode, a flag IEEE80211_TX_CTL_SEND_AFTER_DTIM is added to
txinfo. Then, this kind of packets must be sent via HIQ instead of regular
AC queues, because they should be sent right after beacon.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-11-pkshih@realtek.com
HIQ is short for high queue that is used to send broadcast/multicast
packets right after TBTT in AP mode. Two registers, DTIM and window size,
are configured accordingly.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-10-pkshih@realtek.com
The H2C_FUNC_MAC_FWROLE_MAINTAIN also maintains the roles of all connected
stations; not just the role of VIF. So, I correct the name, but don't
change the 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/20220107034239.22002-9-pkshih@realtek.com
The h2c_join firmware command is used to indicate a station is connected,
and the assoc_cmac_tbl firmware command is used to set CMAC table
corresponding to a mac_id. Both commands must work in both station and AP
modes. Use the mac_id of rtw89_sta naturally and intuitively.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-8-pkshih@realtek.com
In station mode, mac_id of station is the same as rtwvif's one.
In AP mode, each station uses individual mac_id.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-7-pkshih@realtek.com
Update beacon content if TIM bitmap maintained by mac80211 is changed.
Since .set_tim must be atomic but driver uses mutex lock, we add a work.
Otherwise, kernel says "sched: RT throttling activated" and lock down.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-6-pkshih@realtek.com
This C2H notify driver the beacon count we send out. We don't handle the
content for now, so add a dummy handler to avoid messages, like
rtw89_pci 0000:03:00.0: c2h class 0 func 3 not support
C2H: 00000000: 01 03 01 3f 0f 00 00 00 80 0a 00 00 00 00 a0
rtw89_pci 0000:03:00.0: c2h class 0 func 3 not support
C2H: 00000000: 01 03 01 40 0f 00 00 00 00 03 20 00 00 00 a5
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-5-pkshih@realtek.com
Firmware sends out beacon content generated by mac80211, and then stations
can receive beacon and work with this AP properly. Also, we download
beacon content again if TIM is changed.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-4-pkshih@realtek.com
Since firmware transmits beacon by hardware SSN, driver does it with the
same setting, then packets in the air have continual sequence number.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220107034239.22002-3-pkshih@realtek.com
BA CAM is used to ACK peer's packets, so it must be established when
IEEE80211_AMPDU_RX_START, and free it by IEEE80211_AMPDU_RX_STOP.
The hardware can support two static BA CAM entries, so I implement a bitmap
and a struct to record which entry is used and its corresponding tid. Also,
the hardware can learn and create dynamic BA CAM entries automatically if
received packets don't match static BA CAM. That means it can still work if
we don't use H2C to set static BA CAM. An exception is tid=0 should be
always allocated in static BA CAM, so an existing static BA CAM will be
replaced if it is full and peer is going to establish a BA with tid=0.
The new firmware use new format of this H2C, so I upgrade it as well.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20220104012052.6911-1-pkshih@realtek.com
We have three points to receive packets to mac80211 with three different
kinds of status. Many handlers are common and can be shared, so I move
them together, and I don't change the 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/20220103013623.17052-3-pkshih@realtek.com
We are planning to support more chipsets, e.g. 8852C. Before that, we
consider architecutre to handle multiple kinds of chipsets. Obviosuly,
based on original design, rtw89_core module will have large size even
if there is only one chipset under running. It is because all chipset
related things are put in rtw89_core now. To reduce such overhead, we
extract modules of rtw89 and adjust dependencies between modules.
The following assumes that 8852AE, 8852AU, and 8852CE are all supported,
we describe the difference before and after extraction.
[Before extraction]
-------------
|------------------------------------ | rtw89_usb |
V -------------
--------------------------------------- -------------
| rtw89_core (including 8852A, 8852C) | <--- | rtw89_pci |
--------------------------------------- -------------
The data of 8852A and 8852C are built in rtw89_core.
And rtw89_pci is the entry of 8852AE and 8852CE.
And rtw89_usb is the entry of 8852AU.
[After extraction]
------------- ----------------
|----------- | rtw89_usb | <-------- | rtw89_8852au |
| ------------- ----------------
V --------------- |
-------------- | | <---------------
| rtw89_core | <--- | rtw89_8852a |
-------------- | | <---------------
^ ^ --------------- |
| | ------------- ----------------
| | | | <-------- | rtw89_8852ae |
| |----------- | rtw89_pci | ----------------
| | | <-----------------
| ------------- |
| --------------- ----------------
|--------------- | rtw89_8852c | <------ | rtw89_8852ce |
--------------- ----------------
The data of 8852A/8852C is extracted to rtw89_8852a/rtw89_8852c.
And rtw89_pci/rtw89_usb handles only common flow of pci/usb bus.
Finally, 8852AE, 8852AU, and 8852CE have individual entry modules,
i.e. rtw89_8852ae, rtw89_8852au, and rtw89_8852ce correspondingly.
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/20211221025828.25092-1-pkshih@realtek.com
For the NL80211_REGDOM_SET_BY_USER hint from cfg80211, it set the new
alpha2 code to ath11k, then ath11k send WMI_SET_INIT_COUNTRY_CMDID to
firmware for all chips currently. When test with WCN6855/QCA6390 chips,
this WMI CMD leads firmware crash.
For AP based chips(ipq8074/qcn9074), WMI_SET_INIT_COUNTRY_CMDID is used
to send to firmware, for STATION based chips(WCN6855/QCA6390), it need to
use another WMI CMD WMI_SET_CURRENT_COUNTRY_CMDID.
Add flag current_cc_support in hardware parameters, it is used to
distinguish AP/STA platform. After that, the firmware will work
normal and the regulatory feature works well for QCA6390/WCN6855.
Tested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-01740-QCAHSTSWPLZ_V2_TO_X86-1
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220119041355.32014-1-quic_wgong@quicinc.com
When station connect to AP of 6 GHz with 40 MHz bandwidth, the TX is
always stay 20 MHz, it is because the flag WMI_PEER_40MHZ is not set
while peer assoc. Add the flag if remote peer is 40 MHz bandwidth.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2
Fixes: c3a7d7eb4c ("ath11k: add 6 GHz params in peer assoc command")
Signed-off-by: Wen Gong <quic_wgong@quicinc.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220119034211.28622-1-quic_wgong@quicinc.com
Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing
field initialization.
In htc_connect_service() svc_meta_len and pad are not initialized. Based
on code it looks like in current skb there is no service data, so simply
initialize svc_meta_len to 0.
htc_issue_send() does not initialize htc_frame_hdr::control array. Based
on firmware code, it will initialize it by itself, so simply zero whole
array to make KMSAN happy
Fail logs:
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]
hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479
htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]
htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275
...
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258
...
Bytes 4-7 of 18 are uninitialized
Memory access of size 18 starts at ffff888027377e00
BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430
hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]
hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479
htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]
htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275
...
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258
...
Bytes 16-17 of 18 are uninitialized
Memory access of size 18 starts at ffff888027377e00
Fixes: fb9987d0f7 ("ath9k_htc: Support for AR9271 chipset.")
Reported-by: syzbot+f83a1df1ed4f67e8d8ad@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
Link: https://lore.kernel.org/r/20220115122733.11160-1-paskripkin@gmail.com
Pavel Begunkov says:
====================
udp/ipv6 optimisations
Shed some weight from udp/ipv6. Zerocopy benchmarks over dummy showed
~5% tx/s improvement, should be similar for small payload non-zc
cases.
The performance comes from killing 4 atomics and a couple of big struct
memcpy/memset. 1/10 removes a pair of atomics on dst refcounting for
cork->skb setup, 9/10 saves another pair on cork init. 5/10 and 8/10
kill extra 88B memset and memcpy respectively.
====================
Link: https://lore.kernel.org/r/cover.1643243772.git.asml.silence@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Inline a part of ipv6_fixup_options() to avoid extra overhead on
function call if opt is NULL.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
udpv6_sendmsg() doesn't need dst after calling ip6_make_skb(), so
instead of taking an additional reference inside ip6_setup_cork()
and releasing the initial one afterwards, we can hand over a reference
into ip6_make_skb() saving two atomics. The only other user of
ip6_setup_cork() is ip6_append_data() and it requires an extra
dst_hold().
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
udpv6_sendmsg() first initialises an on-stack 88B struct flowi6 and then
copies it into cork, which is expensive. Avoid the copy in corkless case
by initialising on-stack cork->fl directly.
The main part is a couple of lines under !corkreq check. The rest
converts fl6 variable to be a pointer.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Another preparation patch. inet_cork_full already contains a field for
iflow, so we can avoid passing a separate struct iflow6 into
__ip6_append_data() and ip6_make_skb(), and use the flow stored in
inet_cork_full. Make sure callers set cork->fl, i.e. we init it in
ip6_append_data() and before calling ip6_make_skb().
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Convert a struct inet_cork argument in __ip6_append_data() to struct
inet_cork_full. As one struct contains another inet_cork is still can
be accessed via ->base field. It's a preparation patch making further
changes a bit cleaner.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
It doesn't appear there is any reason for ip6_cork_release() to zero
cork->fl, it'll be fully filled on next initialisation. This 88 bytes
memset accounts to 0.3-0.5% of total CPU cycles.
It's also needed in following patches and allows to remove an extar flow
copy in udp_v6_push_pending_frames().
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Clean up ip6_setup_cork() and ip6_cork_release() adding a local variable
for v6_cork->opt. It's a preparation patch for further changes.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ipv6_push_nfrag_opts() doesn't change passed daddr, and so
__ip6_make_skb() doesn't actually need to keep an on-stack copy of
fl6->daddr. Set initially final_dst to fl6->daddr,
ipv6_push_nfrag_opts() will override it if needed, and get rid of extra
copies.
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Hector Martin
Colin Ian King
Yang Guang
Jiasheng Jiang
Changcheng Deng
Ping-Ke Shih
Po-Hao Huang
Muhammad Usama Anjum
Soontak Lee
Hans de Goede
Chin-Yen Lee
Johnson Lin
Íñigo Huguet
Zong-Zhe Yang
Kalle Valo
Wen Gong
Pavel Skripkin
Jakub Kicinski
Pavel Begunkov