Hello Sasha,
On Sun, Aug 03, 2025 at 08:23:22PM -0400, Sasha Levin wrote:
From: Yongbo Zhang giraffesnn123@gmail.com
[ Upstream commit 1c2d81bded1993bb2c7125a911db63612cdc8d40 ]
When the gpio irqchip connected to a slow bus(e.g., i2c bus or virtio bus), calling disable_irq_nosync() in top-half ISR handler will trigger the following kernel BUG:
BUG: scheduling while atomic: RenderEngine/253/0x00010002 ... Call trace: dump_backtrace+0x0/0x1c8 show_stack+0x1c/0x2c dump_stack_lvl+0xdc/0x12c dump_stack+0x1c/0x64 __schedule_bug+0x64/0x80 schedule_debug+0x98/0x118 __schedule+0x68/0x704 schedule+0xa0/0xe8 schedule_timeout+0x38/0x124 wait_for_common+0xa4/0x134 wait_for_completion+0x1c/0x2c _virtio_gpio_req+0xf8/0x198 virtio_gpio_irq_bus_sync_unlock+0x94/0xf0 __irq_put_desc_unlock+0x50/0x54 disable_irq_nosync+0x64/0x94 fusb302_irq_intn+0x24/0x84 __handle_irq_event_percpu+0x84/0x278 handle_irq_event+0x64/0x14c handle_level_irq+0x134/0x1d4 generic_handle_domain_irq+0x40/0x68 virtio_gpio_event_vq+0xb0/0x130 vring_interrupt+0x7c/0x90 vm_interrupt+0x88/0xd8 __handle_irq_event_percpu+0x84/0x278 handle_irq_event+0x64/0x14c handle_fasteoi_irq+0x110/0x210 __handle_domain_irq+0x80/0xd0 gic_handle_irq+0x78/0x154 el0_irq_naked+0x60/0x6c
This patch replaces request_irq() with devm_request_threaded_irq() to avoid the use of disable_irq_nosync().
Signed-off-by: Yongbo Zhang giraffesnn123@gmail.com Reviewed-by: Heikki Krogerus heikki.krogerus@linux.intel.com Link: https://lore.kernel.org/r/20250526043433.673097-1-giraffesnn123@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org
I suggest to wait wait a bit with backporting this commit until the discussion I just started has been resolved (also applies to all the other stable kernel releases you included this patch for):
https://lore.kernel.org/linux-usb/m7n22g5fsfvpjz4s5d6zfcfddrzrj3ixgaqehrjkg7...
Greetings,
-- Sebastian
LLM Generated explanations, may be completely bogus:
**Backport Status: YES**
This commit should be backported to stable kernel trees. Here's my extensive analysis:
## Bug Analysis
The commit fixes a critical "scheduling while atomic" bug that occurs when the fusb302 USB Type-C controller uses GPIO interrupts connected through slow buses (like I2C or virtio). The bug manifests as a kernel BUG with the following call trace showing `__schedule_bug` being triggered from within an atomic context.
## Technical Details of the Bug
**Root Cause**: The fusb302 driver's interrupt handler (`fusb302_irq_intn`) calls `disable_irq_nosync()` from the top-half ISR context (lines 1480-1481 in the original code). When the GPIO controller is connected via a slow bus like virtio-gpio, the `disable_irq_nosync()` operation requires bus transactions that can sleep, which is forbidden in atomic/interrupt context.
**The Problem Flow**:
- Hardware interrupt occurs → `fusb302_irq_intn` ISR runs in atomic context
- ISR calls `disable_irq_nosync(chip->gpio_int_n_irq)`
- virtio-gpio's `virtio_gpio_irq_bus_sync_unlock()` needs to communicate over virtio bus
- This requires `wait_for_completion()` which can sleep
- Sleeping in atomic context triggers the kernel BUG
## The Fix
The fix replaces `request_irq()` with `devm_request_threaded_irq()` and removes the problematic `disable_irq_nosync()`/`enable_irq()` pattern:
- **Before**: Used regular IRQ handler that disabled the interrupt in top-half, scheduled work, then re-enabled in bottom-half
- **After**: Uses threaded IRQ handler which naturally handles the interrupt masking/unmasking without explicit calls
Key changes:
- Line 1751-1754: Changed from `request_irq()` to `devm_request_threaded_irq()` with NULL top-half handler
- Line 1481: Removed `disable_irq_nosync()` call from ISR
- Line 1625: Removed corresponding `enable_irq()` call from work function
- Line 1750: Removed `free_irq()` call (handled by devm_*)
## Stable Backport Criteria Evaluation
- **Fixes a bug affecting users**: YES - This fixes a kernel BUG that causes system instability
- **Relatively small and contained**: YES - Only 7 lines changed, confined to one driver file
- **Clear side effects**: NO - The fix is straightforward with no architectural changes
- **Major architectural changes**: NO - Simply changes IRQ registration method
- **Critical kernel subsystems**: NO - Limited to USB Type-C controller driver
- **Stable tree mention**: NO - But follows stable tree rules perfectly
- **Follows stable rules**: YES - Important bugfix with minimal risk
## Additional Considerations
- The bug only manifests with specific hardware configurations (virtio- gpio or slow I2C GPIO expanders)
- The fix is a standard pattern used throughout the kernel for similar issues
- Using `devm_request_threaded_irq()` is actually cleaner and provides automatic cleanup
- No functional changes to the driver's behavior, only fixes the atomic scheduling violation
- Similar fixes have been applied to other drivers facing the same issue pattern
This is an ideal stable backport candidate: it fixes a real bug that causes kernel panics, the fix is minimal and well-understood, and there's virtually no risk of regression.
drivers/usb/typec/tcpm/fusb302.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/typec/tcpm/fusb302.c b/drivers/usb/typec/tcpm/fusb302.c index f15c63d3a8f4..f2801279c4b5 100644 --- a/drivers/usb/typec/tcpm/fusb302.c +++ b/drivers/usb/typec/tcpm/fusb302.c @@ -1477,9 +1477,6 @@ static irqreturn_t fusb302_irq_intn(int irq, void *dev_id) struct fusb302_chip *chip = dev_id; unsigned long flags;
- /* Disable our level triggered IRQ until our irq_work has cleared it */
- disable_irq_nosync(chip->gpio_int_n_irq);
- spin_lock_irqsave(&chip->irq_lock, flags); if (chip->irq_suspended) chip->irq_while_suspended = true;
@@ -1622,7 +1619,6 @@ static void fusb302_irq_work(struct work_struct *work) } done: mutex_unlock(&chip->lock);
- enable_irq(chip->gpio_int_n_irq);
} static int init_gpio(struct fusb302_chip *chip) @@ -1747,9 +1743,10 @@ static int fusb302_probe(struct i2c_client *client) goto destroy_workqueue; }
- ret = request_irq(chip->gpio_int_n_irq, fusb302_irq_intn,
IRQF_ONESHOT | IRQF_TRIGGER_LOW,"fsc_interrupt_int_n", chip);
- ret = devm_request_threaded_irq(dev, chip->gpio_int_n_irq,
NULL, fusb302_irq_intn,IRQF_ONESHOT | IRQF_TRIGGER_LOW,"fsc_interrupt_int_n", chip);@@ -1774,7 +1771,6 @@ static void fusb302_remove(struct i2c_client *client) struct fusb302_chip *chip = i2c_get_clientdata(client); disable_irq_wake(chip->gpio_int_n_irq);
- free_irq(chip->gpio_int_n_irq, chip); cancel_work_sync(&chip->irq_work); cancel_delayed_work_sync(&chip->bc_lvl_handler); tcpm_unregister_port(chip->tcpm_port);
-- 2.39.5