Syzkaller reported a hung task with uevent_show() on stack trace. That
specific issue was addressed by another commit [0], but even with that
fix applied (for example, running v6.12-rc5) we face another type of hung
task that comes from the same reproducer [1]. By investigating that, we
could narrow it to the following path:
(a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and
dummy_hcd infrastructure.
(b) During the probe of rtl8192cu, the driver ends-up performing an efuse
read procedure (which is related to EEPROM load IIUC), and here lies the
issue: the function read_efuse() calls read_efuse_byte() many times, as
loop iterations depending on the efuse size (in our example, 512 in total).
This procedure for reading efuse bytes relies in a loop that performs an
I/O read up to *10k* times in case of failures. We measured the time of
the loop inside read_efuse_byte() alone, and in this reproducer (which
involves the dummy_hcd emulation layer), it takes 15 seconds each. As a
consequence, we have the driver stuck in its probe routine for big time,
exposing a stack trace like below if we attempt to reboot the system, for
example:
task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000
Workqueue: usb_hub_wq hub_event
Call Trace:
__schedule+0xe22/0xeb6
schedule_timeout+0xe7/0x132
__wait_for_common+0xb5/0x12e
usb_start_wait_urb+0xc5/0x1ef
? usb_alloc_urb+0x95/0xa4
usb_control_msg+0xff/0x184
_usbctrl_vendorreq_sync+0xa0/0x161
_usb_read_sync+0xb3/0xc5
read_efuse_byte+0x13c/0x146
read_efuse+0x351/0x5f0
efuse_read_all_map+0x42/0x52
rtl_efuse_shadow_map_update+0x60/0xef
rtl_get_hwinfo+0x5d/0x1c2
rtl92cu_read_eeprom_info+0x10a/0x8d5
? rtl92c_read_chip_version+0x14f/0x17e
rtl_usb_probe+0x323/0x851
usb_probe_interface+0x278/0x34b
really_probe+0x202/0x4a4
__driver_probe_device+0x166/0x1b2
driver_probe_device+0x2f/0xd8
[...]
We propose hereby to drastically reduce the attempts of doing the I/O
reads in case of failures, restricted to USB devices (given that
they're inherently slower than PCIe ones). By retrying up to 10 times
(instead of 10000), we got reponsiveness in the reproducer, while seems
reasonable to believe that there's no sane USB device implementation in
the field requiring this amount of retries at every I/O read in order
to properly work. Based on that assumption, it'd be good to have it
backported to stable but maybe not since driver implementation (the 10k
number comes from day 0), perhaps up to 6.x series makes sense.
[0] Commit 15fffc6a56 ("driver core: Fix uevent_show() vs driver detach race")
[1] A note about that: this syzkaller report presents multiple reproducers
that differs by the type of emulated USB device. For this specific case,
check the entry from 2024/08/08 06:23 in the list of crashes; the C repro
is available at https://syzkaller.appspot.com/text?tag=ReproC&x=1521fc83980000.
Cc: stable@vger.kernel.org # v6.1+
Reported-by: syzbot+edd9fe0d3a65b14588d5@syzkaller.appspotmail.com
Tested-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20241101193412.1390391-1-gpiccoli@igalia.com
A few of the shared functions need small changes for the USB driver:
- firmware loading
- efuse reading
- rate mask updating
- rf register reading
- initial gain for scanning
Also, add a few macros to wifi.h and initialise rtlhal.interfaceindex
for USB devices.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://msgid.link/28100330-f421-4b85-b41b-f1045380cef2@gmail.com
Currently it takes almost 6 seconds to upload the firmware for RTL8192CU
(and 11 seconds for RTL8192DU). That's because the firmware is uploaded
one byte at a time.
Also, after plugging the device, the firmware gets uploaded three times
before a connection to the AP is established.
Maybe this is fine for most users, but when testing changes to the
driver it's really annoying to wait so long.
Speed up the firmware upload by writing chunks of 64 bytes at a time.
This way it takes about 110 ms for RTL8192CU (and about 210 ms for
RTL8192DU).
PCI devices could upload it in chunks of 4 bytes, but I don't have any
to test and commit 89d32c9071 ("rtlwifi: Download firmware as bytes
rather than as dwords") decided otherwise anyway.
Allocate memory for the firmware image with kmalloc instead of vzalloc
because this memory is passed directly to usb_control_msg(), which
can't take memory allocated by vmalloc.
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Acked-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://msgid.link/d9bd4949-6e92-4f35-8b60-3b45f9ad74ab@gmail.com
The macro name RT_TRACE makes it seem that it is used for tracing, when
is actually used for debugging. Change the name to rtl_dbg. Any Sparse
errors exposed by this change were also fixed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200723204244.24457-3-Larry.Finger@lwfinger.net
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/realtek/rtlwifi/efuse.c: In function efuse_pg_packet_write:
drivers/net/wireless/realtek/rtlwifi/efuse.c:937:24: warning: variable dataempty set but not used [-Wunused-but-set-variable]
drivers/net/wireless/realtek/rtlwifi/efuse.c: In function efuse_get_current_size:
drivers/net/wireless/realtek/rtlwifi/efuse.c:1202:5: warning: variable hoffset set but not used [-Wunused-but-set-variable]
They are not used since commit f1d2b4d338 ("rtlwifi:
rtl818x: Move drivers into new realtek directory")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
drivers/net/wireless/realtek/rtlwifi/efuse.c:16:31:
warning: RTL8712_SDIO_EFUSE_TABLE defined but not used [-Wunused-const-variable=]
drivers/net/wireless/realtek/rtlwifi/efuse.c:9:17:
warning: MAX_PGPKT_SIZE defined but not used [-Wunused-const-variable=]
They are never used, so can be removed.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The assignment of 0 to variable k is never read once we break out of
the loop, so the assignment is redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The variable badworden is assigned with a value that is never read and
it is re-assigned a new value immediately afterwards. The assignment is
redundant and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The types of problems fixed are as follows:
WARNING: Missing a blank line after declarations
CHECK: Please use a blank line after function/struct/union/enum declarations
CHECK: Please don't use multiple blank lines
There are no code changes.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
There are a number of CamelCase variables remaining in the source
files of modules rtl_pci, rtl_usb, and rtlwifi.
The following checkpatch excettions are also fixed:
for_kalle1/0001-rtlwifi-Remove-CamelCase-variables-from-base-code.patch
-----------------------------------------------------------------------
CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]'
#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377:
+ if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
+ rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) ||
+ (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
+ rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
1])) {
CHECK: Unnecessary parentheses around 'rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
1]'
#68: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:377:
+ if ((rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i] !=
+ rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i]) ||
+ (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
+ rtlefuse->efuse_map[EFUSE_MODIFY_MAP][base + i +
1])) {
WARNING: line over 80 characters
#70: FILE: drivers/net/wireless/realtek/rtlwifi/efuse.c:379:
+ (rtlefuse->efuse_map[EFUSE_INIT_MAP][base + i + 1] !=
CHECK: No space is necessary after a cast
#186: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c:396:
+ status->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc);
CHECK: No space is necessary after a cast
#208: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c:335:
+ stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc);
CHECK: No space is necessary after a cast
#243: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:301:
+ stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc);
CHECK: No space is necessary after a cast
#252: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192cu/trx.c:368:
+ stats.rx_is40mhzpacket = (bool) GET_RX_DESC_BW(rxdesc);
CHECK: No space is necessary after a cast
#265: FILE: drivers/net/wireless/realtek/rtlwifi/rtl8192de/trx.c:475:
+ stats->rx_is40mhzpacket = (bool) GET_RX_DESC_BW(pdesc);
WARNING: Unnecessary space before function pointer arguments
#455: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:1462:
+ void (*writen_sync) (struct rtl_priv *rtlpriv, u32 addr, void *buf,
WARNING: Unnecessary space before function pointer arguments
#483: FILE: drivers/net/wireless/realtek/rtlwifi/wifi.h:2257:
+ void (*fill_fake_txdesc) (struct ieee80211_hw *hw, u8 *pdesc,
Note that not all checkpatch exceptions are addressed. Those will be
handled in later patches.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The traditional license information is replaced by the SPDX form. There
are no code changes.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The new component phydm need to access efuse content, so we prepare ops
for reference.
Signed-off-by: Tsang-Shian Lin <thlin@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Acked-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
This is merged by Ping-Ke Shih from commit 85d309d53f ("staging:
rtlwifi: use kcalloc instead of multiply"), and original commit log
is reserved below.
checkpatch emits multiple warnings of type
WARNING:ALLOC_WITH_MULTIPLY: Prefer kcalloc over kzalloc with multiply
Replace two calls to kzalloc() with calls to kcalloc().
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The new code handles the package-type of the chip.
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
The firmware is read from disk as a little-endian byte string. The code
that loads the firmware into the device transfers it as 4-byte quantities.
The routines that write multi-byte quantities on BE hardware assume that
the data are in CPU order, and automatically do the conversion to the LE
order required by the device. As a result, the firmware is transmitted
incorrectly. Rather than do multiple byte swaps on the data, the download
routine is revised to transmit bytes rather than dwords. Although the
number of I/O operations is increased, the firmware is not often loaded.
All drivers have the same bug, and use essentially the same code to
download firmware. These routines have been moved into rtlwifi.
Some CamelCase variables have been renamed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
These messages are always logged and represent error conditions, thus
we can use pr_err().
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
All of the rtlwifi family of drivers have a similar routine that acquires
the hardware info from efuse and initializes a number of variables in the
driver's private area. A common routine is created for all drivers to use.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Now that a new mac80211-based driver for Realtek devices has been submitted,
it is time to reorganize the directories. Rather than having directories
rtlwifi and rtl818x be in drivers/net/wireless/, they will now be in
drivers/net/wireless/realtek/. This change simplifies the directory
structure, but does not result in any configuration changes that are
visable to the user.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
