Received: by 2002:a05:6a10:413:0:0:0:0 with SMTP id 19csp1785024pxp; Mon, 7 Mar 2022 02:15:17 -0800 (PST) X-Google-Smtp-Source: ABdhPJx1JAIK5tYRIWm5bd0J+nkkweaiq74Xrcq+C4eDX0vnLI8TS9RTAHOVLa+61MbHIV6r0Dv/ X-Received: by 2002:a50:c099:0:b0:415:f5c7:700e with SMTP id k25-20020a50c099000000b00415f5c7700emr10078760edf.205.1646648116946; Mon, 07 Mar 2022 02:15:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646648116; cv=none; d=google.com; s=arc-20160816; b=e4yvjYKEPjwLesb/HM5uqOg9NQQcavsl71VTiiHii1x0RvX/1Zp17ZFeQ0MGvXSxp8 5TY6t82tCwKLIAo2b63X+T+SrJFLLwXHZbNMg5UFkSiZO7i2rzq3KztIcHv2wxXTymCa HpeiBHEDyI7qGndba1uZSdisMcWR9e+JgB2JidMhep7I/d9gwPKGJm619JlS2yiw1UO5 CBA5HxVbTlGfmc/YvCEwYyxXBa/ay05Rt9rod7RcoeukBe+OCl956hCRqOKuW/BPprkg 60qJXzw2dKWRXMsdwqUwNPdoxoUBK7VOmG7YLMIj8IsA9F7kvu9HpaClGj+sTvhVXmtz MXyA== 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=+lDbc3IVDO6Tfa+rxjvwVQZ6eiG2afEDbUkowNkAdYg=; b=SZojKpgT9Vj7kZFzAC9vYxgwsJ5PLevOvXfK1AmeHLkxomz9RFLnPfGKJrr59MFtX8 5EV1eAd5VGQYNGLk5BLCYSR8iu8k1N36iCY6lVf8yXJVyg5kf1spawjJ94Lqmit3RByx 9R1Gn0rKMCg789rOul7ZkSbYXTSOMCECHrhWI/xCO6WOuTKqorhpY4Mn7uxMJFRNwmUt hxJmE0y+JD6zGZKpAX73OjJHJPE2KmiEv8GkjAGVpxrsIE66TXqSxEoT9VhW+fy7K86O VTQeasiQzaET141ulMjzbKMbmOuNcqhlsxJhkI5tDuubap6pXngJT1lkiJZv2x0dZyWq FgIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=czYr39C1; 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 c22-20020aa7df16000000b0041128ea9625si9356310edy.399.2022.03.07.02.14.53; Mon, 07 Mar 2022 02:15:16 -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=czYr39C1; 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 S238403AbiCGJrr (ORCPT + 99 others); Mon, 7 Mar 2022 04:47:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238652AbiCGJij (ORCPT ); Mon, 7 Mar 2022 04:38:39 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2955B6B082; Mon, 7 Mar 2022 01:33:07 -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 dfw.source.kernel.org (Postfix) with ESMTPS id 641CA61119; Mon, 7 Mar 2022 09:32:59 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5EF3EC340E9; Mon, 7 Mar 2022 09:32:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646645578; bh=K7m3Sfc/qWJ0tybqDLT00RD7TUonF20rm7LwRCpNImo=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=czYr39C14lsaKYKTMANsvWoZU3x/FCr3jiSZL8h02qWBHoPJ869GGiwUkjsPy2j1c WSqzgpTox5Al5hmOK3KdrZkygSj/RCECxTsBt6PjMmSS22Ub7EFirlkBCcuHppchEt VbLYP4LDdQXzXC+L5WBlHcAhTtEcHeDsHZjRE6g0= 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.10 077/105] pinctrl: sunxi: Use unique lockdep classes for IRQs Date: Mon, 7 Mar 2022 10:19:20 +0100 Message-Id: <20220307091646.343867452@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220307091644.179885033@linuxfoundation.org> References: <20220307091644.179885033@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; @@ -1552,6 +1559,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);