From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7A7FD38DF9; Mon, 4 Aug 2025 00:33:43 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754267623; cv=none; b=BHJPljzLVes4yQVnpj5RVOrSj/AE4JywZqZ1yFpt3BSPEuVzCg1ECGwctXolCddA4/wrqx6hflz5jHxFk9EQtb/CdfkSw4+HAtoZJbS+tHV4Xvgsdb9Km4VuGbgPLWaoKoN8m/mm+ht4KBt65UTCKy9TScSeqmx3QWBa8LQ+aJA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1754267623; c=relaxed/simple; bh=XFN1lXPIyZ9Km1kHM3P6fTSkCBRl84ijQvjAJJ4PC9w=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version:Content-Type; b=u05/NaQJPGlhwZsjqK37AVyeynoSXTbt/u2sbGQ+UIWZjMUHousGqqeCSEy2YHXQ70p9tqLL+ltIb65y/TOJKOe3mBLBEJJB76gBDhtX9sL7+yZzKhoOpyfjikbIbXV97XWHrq3psl/OL8QCywPGlcC2Q3huIUWalWFzTzF4F0k= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=QTH4m+7m; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="QTH4m+7m" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0BE2C4CEEB; Mon, 4 Aug 2025 00:33:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1754267623; bh=XFN1lXPIyZ9Km1kHM3P6fTSkCBRl84ijQvjAJJ4PC9w=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=QTH4m+7mL2kL3Dzdgz6nzIarcZgHB3YeXboppqqnC1KbUA/mlrGmVoHBrSO3AWNw6 XQHi0qwDCPbqJXNfcn99apWy7fbrtZMSpQgwnxgZc5Q+yYbSljyboIUdJ+ql5aprZ2 TlN2mUJuWXozG8s1svutMvGCoHXU9mfaxDdjNZEzCSMvOqVYkuCR5QjJ2ijBZZScfG OxIi7lfJkeCn/hnpECri+HYSZfjJg+KvaHjn3tNQPwkdTMnkfsh2soH3p0G/WCRjDx 43lz4EpQtjfYzCFrxvV00p5iOVlnQjkkl7QY9okhpUeT1DU5O486qWDClFMZJg3b/6 MIS2qJOxFPjDg== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Yongbo Zhang , Heikki Krogerus , Greg Kroah-Hartman , Sasha Levin , krzysztof.kozlowski@linaro.org, sebastian.reichel@collabora.com Subject: [PATCH AUTOSEL 6.12 58/69] usb: typec: fusb302: fix scheduling while atomic when using virtio-gpio Date: Sun, 3 Aug 2025 20:31:08 -0400 Message-Id: <20250804003119.3620476-58-sashal@kernel.org> X-Mailer: git-send-email 2.39.5 In-Reply-To: <20250804003119.3620476-1-sashal@kernel.org> References: <20250804003119.3620476-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: patches@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.12.41 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Yongbo Zhang [ 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 Reviewed-by: Heikki Krogerus Link: https://lore.kernel.org/r/20250526043433.673097-1-giraffesnn123@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin --- 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 1. **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. 2. **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: 1. **Before**: Used regular IRQ handler that disabled the interrupt in top-half, scheduled work, then re-enabled in bottom-half 2. **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 1. **Fixes a bug affecting users**: YES - This fixes a kernel BUG that causes system instability 2. **Relatively small and contained**: YES - Only 7 lines changed, confined to one driver file 3. **Clear side effects**: NO - The fix is straightforward with no architectural changes 4. **Major architectural changes**: NO - Simply changes IRQ registration method 5. **Critical kernel subsystems**: NO - Limited to USB Type-C controller driver 6. **Stable tree mention**: NO - But follows stable tree rules perfectly 7. **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 e2fe479e16ad..2de597ea3dc9 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); if (ret < 0) { dev_err(dev, "cannot request IRQ for GPIO Int_N, ret=%d", ret); goto tcpm_unregister_port; @@ -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