From nobody Tue Apr 7 04:36:40 2026 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (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 A072239C63D for ; Mon, 16 Mar 2026 14:05:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773669928; cv=none; b=QbnAckrLhCL4fUolxy9OsF1Gr/0I1Rz1MEcT05p8UEHX2ReL0qALOIJrAWGdmlApVgM6TPipxPuaFPPkKoZI1Sn8eXIYOvQlZIa0aFjG0hwak5c8vYewnrvk4uGyHFjnq5XIO3ZavfsE7We8yC+DLYs5/HdUMebJPJTULSYXsS4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773669928; c=relaxed/simple; bh=n6FYSU5YmxHfeq9L0JOIO5Jxr1WLOHeof8/dRnRSpTw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=IJ619gtaDO2C/6ywsgtKNeLnHO2sWwV7oRFhRk3uMMuxlPjFuQ3SCZiMurIP1BlneJkA0arYqyurq8CXXJvA1CkuQzA21pWTpTARJd8cCvLcEttLB/jiB870DrojNYc1vGvsVshrE30sWUXBjEnY4DbsbGG7DV6B+Ly1qIbNhGU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1w28ZI-0002G7-U9; Mon, 16 Mar 2026 15:05:16 +0100 Received: from dude04.red.stw.pengutronix.de ([2a0a:edc0:0:1101:1d::ac] helo=dude04) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w28ZH-000a8N-2n; Mon, 16 Mar 2026 15:05:15 +0100 Received: from ore by dude04 with local (Exim 4.98.2) (envelope-from ) id 1w28ZH-00000005twy-35wm; Mon, 16 Mar 2026 15:05:15 +0100 From: Oleksij Rempel To: Guenter Roeck , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Lee Jones , Peter Rosin , Linus Walleij Cc: Oleksij Rempel , Bartosz Golaszewski , kernel@pengutronix.de, linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-gpio@vger.kernel.org, David Jander Subject: [PATCH v5 4/7] gpio: gpiolib: fix allocation order in hierarchical IRQ domains Date: Mon, 16 Mar 2026 15:05:09 +0100 Message-ID: <20260316140514.1406588-5-o.rempel@pengutronix.de> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260316140514.1406588-1-o.rempel@pengutronix.de> References: <20260316140514.1406588-1-o.rempel@pengutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: ore@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" Allocate parent IRQs after setting the basic IRQ handler to avoid NULL pointer dereferences and RCU stalls. In gpiochip_hierarchy_irq_domain_alloc(), calling irq_domain_set_info() before parent allocation causes a NULL pointer dereference for slow-bus (SPI/I2C) IRQ chips because the child proxies .irq_bus_lock to a parent->chip that is not yet populated. Conversely, moving the entire configuration after parent allocation causes RCU stalls if a hardware interrupt is pending; the unconfigured descriptor defaults to handle_bad_irq and fails to acknowledge the interrupt. Fix this by splitting the initialization: set the handler and data before parent allocation to handle pending events, but defer setting the chip and hardware IRQ info until the parent is fully allocated. Signed-off-by: Oleksij Rempel Fixes: fdd61a013a24 ("gpio: Add support for hierarchical IRQ domains") Acked-by: Bartosz Golaszewski --- changes v5: - move this patch back to this series - split irq_domain_set_info(). Set the handler and data before parent allocatio and set the chip and hardware IRQ info after parent allocation. - previous version: https://lore.kernel.org/all/20260309134920.1918294-5-o.rempel@pengutronix= .de/ --- drivers/gpio/gpiolib.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 9550500e1690..3ee1a403ccf8 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1632,14 +1632,8 @@ static int gpiochip_hierarchy_irq_domain_alloc(struc= t irq_domain *d, * We set handle_bad_irq because the .set_type() should * always be invoked and set the right type of handler. */ - irq_domain_set_info(d, - irq, - hwirq, - gc->irq.chip, - gc, - girq->handler, - NULL, NULL); - irq_set_probe(irq); + irq_set_handler(irq, girq->handler); + irq_set_handler_data(irq, gc); =20 /* This parent only handles asserted level IRQs */ ret =3D girq->populate_parent_alloc_arg(gc, &gpio_parent_fwspec, @@ -1657,12 +1651,17 @@ static int gpiochip_hierarchy_irq_domain_alloc(stru= ct irq_domain *d, */ if (irq_domain_is_msi(d->parent) && (ret =3D=3D -EEXIST)) ret =3D 0; - if (ret) + if (ret) { gpiochip_err(gc, "failed to allocate parent hwirq %d for hwirq %lu\n", parent_hwirq, hwirq); + return ret; + } =20 - return ret; + irq_domain_set_hwirq_and_chip(d, irq, hwirq, gc->irq.chip, gc); + irq_set_probe(irq); + + return 0; } =20 static unsigned int gpiochip_child_offset_to_irq_noop(struct gpio_chip *gc, --=20 2.47.3