[ Upstream commit 4058c39bd176daf11a826802d940d86292a6b02b ]
The issue is that before entering the crash kernel, the DWC USB controller
did not perform operations such as resetting the interrupt mask bits.
After entering the crash kernel,before the USB interrupt handler
registration was completed while loading the DWC USB driver,an GINTSTS_SOF
interrupt was received.This triggered the misroute_irq process within the
GIC handling framework,ultimately leading to the misrouting of the
interrupt,causing it to be handled by the wrong interrupt handler
and resulting in the issue.
Summary:In a scenario where the kernel triggers a panic and enters
the crash kernel,it is necessary to ensure that the interrupt mask
bit is not enabled before the interrupt registration is complete.
If an interrupt reaches the CPU at this moment,it will certainly
not be handled correctly,especially in cases where this interrupt
is reported frequently.
Please refer to the Crashkernel dmesg information as follows
(the message on line 3 was added before devm_request_irq is
called by the dwc2_driver_probe function):
[ 5.866837][ T1] dwc2 JMIC0010:01: supply vusb_d not found, using dummy regulator
[ 5.874588][ T1] dwc2 JMIC0010:01: supply vusb_a not found, using dummy regulator
[ 5.882335][ T1] dwc2 JMIC0010:01: before devm_request_irq irq: [71], gintmsk[0xf300080e], gintsts[0x04200009]
[ 5.892686][ C0] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-jmnd1.2_RC #18
[ 5.900327][ C0] Hardware name: CMSS HyperCard4-25G/HyperCard4-25G, BIOS 1.6.4 Jul 8 2024
[ 5.908836][ C0] Call trace:
[ 5.911965][ C0] dump_backtrace+0x0/0x1f0
[ 5.916308][ C0] show_stack+0x20/0x30
[ 5.920304][ C0] dump_stack+0xd8/0x140
[ 5.924387][ C0] pcie_xxx_handler+0x3c/0x1d8
[ 5.930121][ C0] __handle_irq_event_percpu+0x64/0x1e0
[ 5.935506][ C0] handle_irq_event+0x80/0x1d0
[ 5.940109][ C0] try_one_irq+0x138/0x174
[ 5.944365][ C0] misrouted_irq+0x134/0x140
[ 5.948795][ C0] note_interrupt+0x1d0/0x30c
[ 5.953311][ C0] handle_irq_event+0x13c/0x1d0
[ 5.958001][ C0] handle_fasteoi_irq+0xd4/0x260
[ 5.962779][ C0] __handle_domain_irq+0x88/0xf0
[ 5.967555][ C0] gic_handle_irq+0x9c/0x2f0
[ 5.971985][ C0] el1_irq+0xb8/0x140
[ 5.975807][ C0] __setup_irq+0x3dc/0x7cc
[ 5.980064][ C0] request_threaded_irq+0xf4/0x1b4
[ 5.985015][ C0] devm_request_threaded_irq+0x80/0x100
[ 5.990400][ C0] dwc2_driver_probe+0x1b8/0x6b0
[ 5.995178][ C0] platform_drv_probe+0x5c/0xb0
[ 5.999868][ C0] really_probe+0xf8/0x51c
[ 6.004125][ C0] driver_probe_device+0xfc/0x170
[ 6.008989][ C0] device_driver_attach+0xc8/0xd0
[ 6.013853][ C0] __driver_attach+0xe8/0x1b0
[ 6.018369][ C0] bus_for_each_dev+0x7c/0xdc
[ 6.022886][ C0] driver_attach+0x2c/0x3c
[ 6.027143][ C0] bus_add_driver+0xdc/0x240
[ 6.031573][ C0] driver_register+0x80/0x13c
[ 6.036090][ C0] __platform_driver_register+0x50/0x5c
[ 6.041476][ C0] dwc2_platform_driver_init+0x24/0x30
[ 6.046774][ C0] do_one_initcall+0x50/0x25c
[ 6.051291][ C0] do_initcall_level+0xe4/0xfc
[ 6.055894][ C0] do_initcalls+0x80/0xa4
[ 6.060064][ C0] kernel_init_freeable+0x198/0x240
[ 6.065102][ C0] kernel_init+0x1c/0x12c
Signed-off-by: Shawn Shao <shawn.shao@jaguarmicro.com>
Link: https://lore.kernel.org/r/20240830031709.134-1-shawn.shao@jaguarmicro.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5d69a3b54e5a630c90d82a4c2bdce3d53dc78710 upstream.
Added functionality to exit from L1 state by device initiation
using remote wakeup signaling, in case when function driver queuing
request while core in L1 state.
Fixes: 273d576c4d41 ("usb: dwc2: gadget: Add functionality to exit from LPM L1 state")
Fixes: 88b02f2cb1e1 ("usb: dwc2: Add core state checking")
CC: stable@vger.kernel.org
Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Link: https://lore.kernel.org/r/b4d9de5382375dddbf7ef6049d9a82066ad87d5d.1710166393.git.Minas.Harutyunyan@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bae2bc73a59c200db53b6c15fb26bb758e2c6108 upstream.
Starting from core v4.30a changed order of programming
GPWRDN_PMUACTV to 0 in case of exit from hibernation on
remote wakeup signaling from device.
Fixes: c5c403dc4336 ("usb: dwc2: Add host/device hibernation functions")
CC: stable@vger.kernel.org
Signed-off-by: Minas Harutyunyan <Minas.Harutyunyan@synopsys.com>
Link: https://lore.kernel.org/r/99385ec55ce73445b6fbd0f471c9bd40eb1c9b9e.1708939799.git.Minas.Harutyunyan@synopsys.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0583bc776ca5b5a3f5752869fc31cf7322df2b35 upstream.
dwc2_hc_n_intr() writes back INTMASK as read but evaluates it
with intmask applied. In stress testing this causes spurious
interrupts like this:
[Mon Aug 14 10:51:07 2023] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 7 - ChHltd set, but reason is unknown
[Mon Aug 14 10:51:07 2023] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001
[Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 0 - ChHltd set, but reason is unknown
[Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001
[Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: dwc2_hc_chhltd_intr_dma: Channel 4 - ChHltd set, but reason is unknown
[Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: hcint 0x00000002, intsts 0x04600001
[Mon Aug 14 10:51:08 2023] dwc2 3f980000.usb: dwc2_update_urb_state_abn(): trimming xfer length
Applying INTMASK prevents this. The issue exists in all versions of the
driver.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
Tested-by: Ivan Ivanov <ivan.ivanov@suse.com>
Tested-by: Andrea della Porta <andrea.porta@suse.com>
Link: https://lore.kernel.org/r/20231115144514.15248-1-oneukum@suse.com
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit ef307bc6ef04e8c1ea843231db58e3afaafa9fa6 ]
In _dwc2_hcd_urb_enqueue(), "urb->hcpriv = NULL" is executed without
holding the lock "hsotg->lock". In _dwc2_hcd_urb_dequeue():
spin_lock_irqsave(&hsotg->lock, flags);
...
if (!urb->hcpriv) {
dev_dbg(hsotg->dev, "## urb->hcpriv is NULL ##\n");
goto out;
}
rc = dwc2_hcd_urb_dequeue(hsotg, urb->hcpriv); // Use urb->hcpriv
...
out:
spin_unlock_irqrestore(&hsotg->lock, flags);
When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are
concurrently executed, the NULL check of "urb->hcpriv" can be executed
before "urb->hcpriv = NULL". After urb->hcpriv is NULL, it can be used
in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL
pointer dereference.
This possible bug is found by an experimental static analysis tool
developed by myself. This tool analyzes the locking APIs to extract
function pairs that can be concurrently executed, and then analyzes the
instructions in the paired functions to identify possible concurrency
bugs including data races and atomicity violations. The above possible
bug is reported, when my tool analyzes the source code of Linux 6.5.
To fix this possible bug, "urb->hcpriv = NULL" should be executed with
holding the lock "hsotg->lock". After using this patch, my tool never
reports the possible bug, with the kernelconfiguration allyesconfig for
x86_64. Because I have no associated hardware, I cannot test the patch
in runtime testing, and just verify it according to the code logic.
Fixes: 33ad261aa62b ("usb: dwc2: host: spinlock urb_enqueue")
Signed-off-by: Jia-Ju Bai <baijiaju@buaa.edu.cn>
Link: https://lore.kernel.org/r/20230926024404.832096-1-baijiaju@buaa.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
