From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj2-f4.google.com (mail-pj2-f4.google.com [74.125.227.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8109F3F39E8 for ; Fri, 17 Jul 2026 11:22:59 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.227.132 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784287388; cv=none; b=q0O95wlXulB7q9rVqz6r+UX+TSIRcsDI7PwuFVN6yr/F+ZgnYwKCKmxISKpVYpq8WwqihzPWb3OZFfdyyIQQqOJrZnjx/I+i2IWhvvtxf/AnabyF7YrGh+y9DK9wEOaRGBJTl4LaEFBNb9LgQhT/1LrA2TdmLha2w5W9/2cPvRw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784287388; c=relaxed/simple; bh=RDNlswz4ZIxm/iCbg7Dbu2G0uXSkNUzD6FcCRvIco6M=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=gNq3Il+/bIe+Y5gnbD/GSPWLOHR65uT8DSBysIYXDt4p4lwnFrRNq6yiY0xfsqePZ2GOosFvTb9tKb/hlwbQhn77sG6iu7/5nGABMPlvcTtnJJXhLPSo4Eeix3NVT0ys+YndGisofftRPxcx89HWB5p8d2zGrSoidKaWYkoQ42M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=go4/Pd3b; arc=none smtp.client-ip=74.125.227.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="go4/Pd3b" Received: by mail-pj2-f4.google.com with SMTP id 98e67ed59e1d1-381191ea2adso4760878a91.1 for ; Fri, 17 Jul 2026 04:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784287375; x=1784892175; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=6UDSn728tqCR6C0BD1BmgTGtViAWp/koJ11KufYNnZY=; b=go4/Pd3bMVrFZSJQyDguB+A5B2bSQm1nGccaFK9SwABfDh72+AkVoLjjq4nCJIcaWc TxbTS/N5df4KcMgZiuFkHcZgQEP315SxomRwSQa7uvbAUuvaS1w/zTpOnH7UoFjEMRp0 Ze3k/frkHr6Y+Iot2/6/6fWTw3YKStsuPqEZ58mMeH0r/lMVzUr/u2zOvxtW38pDEFjz IlMX9OgteAjWRBk3BKsB3rbB4z0uri51oFt3EJOPypc/EFEDFj6mrhET0O6UVl2AYW7C EbS06ObGYtWJ5tkm/rp+PNHc6Gos0mBQ5xi2onRpnxHN3Dg7J/wZLDo0ruuSbyxDknU0 mUdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784287375; x=1784892175; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=6UDSn728tqCR6C0BD1BmgTGtViAWp/koJ11KufYNnZY=; b=AukBf4vQWKLwiWj9EBFEBD1z74IOp8jzu86TBIgFpcR0UHuSdDgDDRfPxExnxpRGTU kVYDcj535An61KQq2Ri9gg744q1oA6ZXUCFs22DQVNfEaysBSs+NiYbfZd48NvX1hT3U V5O5INYH0RmUbRZFHYaounZrpgHXzM3q/llLQ3SbbVL4uNNUXMUjTJtwUlxNmKsZlwSX GY8DuEHqA//ILsnEAk4Z2jG4+fXd4K+BqrAjTVVL1vUZj8lyx8gtOZbziu8SN8N/FHcm xk0Q0yS4UWcABffQKqrE7rg1361vhxRl2uknpuZJQU+m60ORvy1djnqIVzoRyXMmkgAf b29g== X-Gm-Message-State: AOJu0YzXVK2GfBvWZJVZjnYBkQrrR9foVFYRymaTUXwu53i0Dba5xneu fFMbD4hmFY8ndNDAtc4bgtt9RWUhhNpMSNgK72+AUhEdQZ3pbFfMSYhT X-Gm-Gg: AfdE7cl2ZMfzQkQELVGH+ard/popgMHU0EyCvwItklq4deRPHLQNs3n0EKCgEPb4f69 7+6yoImsJup/7fjG2H6HjDm/0Cosh7toAHSTCQVXcq6nNl1Lp8kbP31bfVIyFqiBf0pTlSwV4ps 0touPtwqSyH7/RquK96Zsc3h/7AekkzVui+SZrh1lIR1z7+Hzj/uSifqsWk03npYNOD0Tnxbcf1 zk+vlMK1Qm1N8CxBmpY8uCB3MvZHsmPtqw6c/jHIhcp+MqtVbIHX4rdrrwFFKHMVfjhQu+kIYJ1 pAhNITOUm91N4LbFWjX/Wy2pbwXyGLmZ3y18BwaSF/2J4j51qmR2Q9cb7+gz8koCUJjQi1XTlFD KfsTHFKH2r8XQ5AJTQVn8E2ORk/gv9NJlCcD+g126oha1S5kgUMulvQCdNiJKic70rM+cmdK++m 6+9Oq01La3 X-Received: by 2002:a17:90b:3890:b0:38e:2d37:843d with SMTP id 98e67ed59e1d1-38e4b569e7amr1877325a91.32.1784287375401; Fri, 17 Jul 2026 04:22:55 -0700 (PDT) Received: from workstation.. ([182.180.105.19]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3142a1ddeb6sm7593233eec.20.2026.07.17.04.22.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 04:22:55 -0700 (PDT) From: Ali Tariq To: Thomas Gleixner Cc: linux-kernel@vger.kernel.org, Bjorn Helgaas , alitariq45892@gmail.com Subject: [RFC] synchronize_irq() does not wait for chained interrupt handlers Date: Fri, 17 Jul 2026 16:22:44 +0500 Message-Id: <20260717112244.231394-1-alitariq45892@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Hi, While reviewing drivers/pci/controller/plda/pcie-plda-host.c, I found that synchronize_irq() does not appear to provide the guarantee I expected for chained interrupt handlers (registered via irq_set_chained_handler_and_data()). Tracing through kernel/irq/manage.c: - synchronize_irq()'s wait relies on the IRQD_IRQ_INPROGRESS flag - That flag is set/cleared by handle_irq_event(), part of the normal (non-chained) dispatch path - Chained handlers bypass that path entirely and dispatch goes straight to desc->handle_irq - The fallback, __irq_get_irqchip_state() via .irq_get_irqchip_state(), only works if the irq_chip implements that callback In the PLDA PCIe driver's case, none of its irq_chip structures implement .irq_get_irqchip_state(), so synchronize_irq() called after irq_set_chained_handler_and_data(irq, NULL, NULL) returns immediately, regardless of whether the chained handler is still executing on another CPU. (I originally submitted a fix using synchronize_irq() for this driver; withdrawing it once I traced this through [1]) This was originally flagged by an automated review (Sashiko AI) on a patch I submitted for the StarFive PCIe driver [2]. Tracing through kernel/irq/manage.c to verify the finding led me to the IRQD_IRQ_INPROGRESS/chained-handler gap described above. Bjorn Helgaas then asked whether other drivers using the same pattern would need similar handling [3], which prompted the wider search below. I searched the tree for other callers of irq_set_chained_handler_and_data(irq, NULL, NULL) and found roughly 30 call sites with a similar shape, mostly in driver .remove()/teardown paths. I haven't individually verified severity for each - it seems to depend on what runs immediately after teardown in each specific driver (e.g. whether clocks/power are cut shortly after, as in the PLDA case). A partial list of files where the same call sequence is present: arch/arm/common/locomo.c arch/arm/common/sa1111.c drivers/gpio/gpio-brcmstb.c drivers/gpio/gpio-mpc8xxx.c drivers/gpio/gpio-mt7621.c drivers/gpio/gpio-mxc.c drivers/gpio/gpio-rockchip.c drivers/gpu/drm/imx/dc/dc-ic.c drivers/gpu/drm/msm/msm_mdss.c drivers/gpu/ipu-v3/ipu-common.c drivers/irqchip/irq-imgpdc.c drivers/irqchip/irq-lan966x-oic.c drivers/irqchip/irq-ls-scfg-msi.c drivers/irqchip/irq-ts4800.c drivers/mfd/fsl-imx25-tsadc.c drivers/pci/controller/pci-mvebu.c I'm not sure what the right fix looks like at scale - possibly implementing .irq_get_irqchip_state() where the hardware supports it, possibly a driver-local synchronization primitive where it doesn't map cleanly (which seems to be the case for PLDA, since its status register is acknowledged partway through handler execution, before the rest of the dispatch work completes). Is this a known/expected limitation of synchronize_irq() for chained handlers, or worth addressing more broadly? Happy to do more digging or send patches if there's a preferred direction. Thanks, Ali [1] https://lore.kernel.org/linux-pci/20260714174345.1073909-1-alitariq45892@gmail.com/ [2] https://lore.kernel.org/linux-pci/20260713150346.B57F11F000E9@smtp.kernel.org/ [3] https://lore.kernel.org/linux-pci/20260714175852.GA1387886@bhelgaas/