Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1800969pxp; Mon, 7 Mar 2022 02:39:57 -0800 (PST) X-Google-Smtp-Source: ABdhPJyFz7yU0+Yy1eg9SryMxXoxD4uMjaiH7vgnRKtUdB98SvB6mTC6Px7UGrSfncqNLksGid+L X-Received: by 2002:a17:907:3e82:b0:6da:6f15:ff38 with SMTP id hs2-20020a1709073e8200b006da6f15ff38mr8617494ejc.324.1646649597001; Mon, 07 Mar 2022 02:39:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646649596; cv=none; d=google.com; s=arc-20160816; b=Ds+npk7clfEkgeKkgBexUbRiHIUskmWiowneeqsffcpk8YjXdPK6GZakhZiIm2YMTT 69wXgRG+sZrr6RskHHDhaGU5xTD3eBUiLPvTE0tALIBmYeST03F8Si4AWBtkfo5IZThQ IGfVdv5ZzliaJgXK8BGPCZjrbLO/nh8DtZptG/jELMX5NGXRng9vSXv9WPO4gbRVJnzO Mc16Ptydc1D7EeRCSjBluk9vuWiqQKvIwL2R+xQDHCtt8GtC5bD64L+RGAKx61HzbD2S Q/p/5jm/J43Qv5UBaXSFJ58Er6logp+eIRI9Mxf67e2ontcXXF2vO1Y2nrknWTQkjaLt 3k6g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=CGtOi8Ops1kL60xVPLFn+beajXDoyFh7OnBmjRKHrck=; b=CMCK3Inq+gwpFbpFONjjXXmY9kuxskkbUa8kN2qhkZm50zVxpDBGOBqpA1bTN8qU9V Aye2ooYr4s2UjZmy8rvmGK8zrbqzVb9FAqzqQ6Xhp5dMCC1Ce5ED3QqTCVa5E7acqr7K 2cqlxkR2hV7Id6L8ndeL35l3BuH2ZFKP15tGF7i3ikg0AyxY3DZjG2Lk5fr0nf5uV34o mVxPTZ4jA7nmilE9/E9uqrP1BpTHTYWIQg40es7CWD9III37KeiQTYA3QOp6044XDev1 Mm4Uos+WGzTtGZd/+5QWxMMuCsABS3GOi1XYQsIHmB9Xf604M3BLzbGjmS9Zk7SkDlNF LFlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=efK96Z+x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b10-20020a056402350a00b00415e975298dsi8197073edd.191.2022.03.07.02.39.32; Mon, 07 Mar 2022 02:39:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=efK96Z+x; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242146AbiCGKLQ (ORCPT + 99 others); Mon, 7 Mar 2022 05:11:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240622AbiCGJvM (ORCPT ); Mon, 7 Mar 2022 04:51:12 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C901D6582B; Mon, 7 Mar 2022 01:44:58 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 59469B810CF; Mon, 7 Mar 2022 09:44:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC459C340F6; Mon, 7 Mar 2022 09:44:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646646296; bh=XNFfssC4dcywt09vS1FDrDsp4FKO7LtqQ6ia6lOx3UI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=efK96Z+xXbWq5juTOqlfP2+QztRpbmneHtmjQjDmlMp7kjiUPPvIgbmFSt+FlyuGA Arb9LnHEoTW8RB6SknZNJKs8XF77tVRg/NKRtC3G+HwVgq2GY5mTRpAfCqyuSuOrxB rAxNmCbaSIeSmGicUz1xO8+W3YhWdKoRDptMuMSQ= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Guenter Roeck , Samuel Holland , Jernej Skrabec , Linus Walleij Subject: [PATCH 5.15 197/262] pinctrl: sunxi: Use unique lockdep classes for IRQs Date: Mon, 7 Mar 2022 10:19:01 +0100 Message-Id: <20220307091708.187406745@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220307091702.378509770@linuxfoundation.org> References: <20220307091702.378509770@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Samuel Holland commit bac129dbc6560dfeb634c03f0c08b78024e71915 upstream. This driver, like several others, uses a chained IRQ for each GPIO bank, and forwards .irq_set_wake to the GPIO bank's upstream IRQ. As a result, a call to irq_set_irq_wake() needs to lock both the upstream and downstream irq_desc's. Lockdep considers this to be a possible deadlock when the irq_desc's share lockdep classes, which they do by default: ============================================ WARNING: possible recursive locking detected 5.17.0-rc3-00394-gc849047c2473 #1 Not tainted -------------------------------------------- init/307 is trying to acquire lock: c2dfe27c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0 but task is already holding lock: c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by init/307: #0: c1f29f18 (system_transition_mutex){+.+.}-{3:3}, at: __do_sys_reboot+0x90/0x23c #1: c20f7760 (&dev->mutex){....}-{3:3}, at: device_shutdown+0xf4/0x224 #2: c2e804d8 (&dev->mutex){....}-{3:3}, at: device_shutdown+0x104/0x224 #3: c3c0ac7c (&irq_desc_lock_class){-.-.}-{2:2}, at: __irq_get_desc_lock+0x58/0xa0 stack backtrace: CPU: 0 PID: 307 Comm: init Not tainted 5.17.0-rc3-00394-gc849047c2473 #1 Hardware name: Allwinner sun8i Family unwind_backtrace from show_stack+0x10/0x14 show_stack from dump_stack_lvl+0x68/0x90 dump_stack_lvl from __lock_acquire+0x1680/0x31a0 __lock_acquire from lock_acquire+0x148/0x3dc lock_acquire from _raw_spin_lock_irqsave+0x50/0x6c _raw_spin_lock_irqsave from __irq_get_desc_lock+0x58/0xa0 __irq_get_desc_lock from irq_set_irq_wake+0x2c/0x19c irq_set_irq_wake from irq_set_irq_wake+0x13c/0x19c [tail call from sunxi_pinctrl_irq_set_wake] irq_set_irq_wake from gpio_keys_suspend+0x80/0x1a4 gpio_keys_suspend from gpio_keys_shutdown+0x10/0x2c gpio_keys_shutdown from device_shutdown+0x180/0x224 device_shutdown from __do_sys_reboot+0x134/0x23c __do_sys_reboot from ret_fast_syscall+0x0/0x1c However, this can never deadlock because the upstream and downstream IRQs are never the same (nor do they even involve the same irqchip). Silence this erroneous lockdep splat by applying what appears to be the usual fix of moving the GPIO IRQs to separate lockdep classes. Fixes: a59c99d9eaf9 ("pinctrl: sunxi: Forward calls to irq_set_irq_wake") Reported-by: Guenter Roeck Signed-off-by: Samuel Holland Reviewed-by: Jernej Skrabec Tested-by: Guenter Roeck Link: https://lore.kernel.org/r/20220216040037.22730-1-samuel@sholland.org Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman --- drivers/pinctrl/sunxi/pinctrl-sunxi.c | 9 +++++++++ 1 file changed, 9 insertions(+) --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c @@ -36,6 +36,13 @@ #include "../core.h" #include "pinctrl-sunxi.h" +/* + * These lock classes tell lockdep that GPIO IRQs are in a different + * category than their parents, so it won't report false recursion. + */ +static struct lock_class_key sunxi_pinctrl_irq_lock_class; +static struct lock_class_key sunxi_pinctrl_irq_request_class; + static struct irq_chip sunxi_pinctrl_edge_irq_chip; static struct irq_chip sunxi_pinctrl_level_irq_chip; @@ -1551,6 +1558,8 @@ int sunxi_pinctrl_init_with_variant(stru for (i = 0; i < (pctl->desc->irq_banks * IRQ_PER_BANK); i++) { int irqno = irq_create_mapping(pctl->domain, i); + irq_set_lockdep_class(irqno, &sunxi_pinctrl_irq_lock_class, + &sunxi_pinctrl_irq_request_class); irq_set_chip_and_handler(irqno, &sunxi_pinctrl_edge_irq_chip, handle_edge_irq); irq_set_chip_data(irqno, pctl);