Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp997850yba; Thu, 4 Apr 2019 02:04:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqzJMEXy5hxB9cyrELU6ZOJ4/tub7JW4pRMSaEuuy3IBjBDTV4QGlg8Pda48XNvcqvO8dx3t X-Received: by 2002:a63:fc5a:: with SMTP id r26mr4431729pgk.97.1554368663993; Thu, 04 Apr 2019 02:04:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554368663; cv=none; d=google.com; s=arc-20160816; b=Q+VErgsXC4jA9WIjf66LMLqrJXZ/MJasp1pXGGwOmhuC9sDIoOT6EZW37XIDqTGFMb tbohsizct2/vaGbxavkXrxXpNRlDHLSupo9+AJeEgw+G85Mx1pAlREliB9j6Xdk0UU0B 7P1940LkDelYll2TR384/UVorUbFLsKFjmWLpNRby1DA+Jm/rtMnCpPR8ndXTEfE09RK BCAqfAaF3KKh8ZmgSIBFKhaUmamSSPtzY15S/fRv26uCqnHke6Fh4r7GEka+Lm2bg3Oy MRR6Tn/mLHM2UE7soEOeRo204reXSH0AL8vM5UsGocLRpqIbbePZwtgUfLHbs5SA2H6Z C7iQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=hDnEzNEcM1CSuOP6U+HMfK92UxbKDWlZwRl0kiSZ+mg=; b=QJBO7GLg9JS0S26BPDrGJ6/+F5uz7MxhpfFGVduuR51+H6+OTO/eEOn0Y2o0HZktgu CB2wPIpizvw2HP4X3VeCgKsx6tJ2sYIFCgeDLfyl/Ji11zjvD7WMOf+9/mZ0hAsLFFLB s19YNB0Vq8CNrA+41l0QgzsdR2iEhYWe2Nb/e5P6GP3td9Gng0B1INgQIDtYy5q2uNou dr99Y8BdeOPu3HApdK1fWC88fXmJUAj4uj1Pol+YOKP7T8AIQ5Y9brEWCe4ml3G21zPz gXlis+swaZAgKHgMXEltw4lCY1wW8d8ulm7b9B3TrYZic9b6bC2ZJlsOugBp2NDhR50U 4F/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=dmHFMl2y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m72si16684011pfj.279.2019.04.04.02.03.38; Thu, 04 Apr 2019 02:04:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=dmHFMl2y; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731036AbfDDJBr (ORCPT + 99 others); Thu, 4 Apr 2019 05:01:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:38958 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731252AbfDDJBp (ORCPT ); Thu, 4 Apr 2019 05:01:45 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E15272147C; Thu, 4 Apr 2019 09:01:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1554368504; bh=3+WnXl05EX9cXr0wqvRXvanIPtJaSAHf0rJcG+m8sNI=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=dmHFMl2yqrtPpDBXB3G2laxuKdLdhDzgP/i9QH1pARCbK1M08XtRhz8Ay7DV/tNe+ 1zx3n7alpIkIS43wGvZWO2cWiJrCgkgx9BGOKWpfqHwy00OzWj6nlAo54VpgXfFdD5 V1ABvYhrwqP74EPUPNkiVWnzqGEXEPePc4cWpSIk= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Russell King , Andrew Lunn , "David S. Miller" , Sasha Levin Subject: [PATCH 4.19 064/187] net: dsa: mv88e6xxx: Add lockdep classes to fix false positive splat Date: Thu, 4 Apr 2019 10:46:41 +0200 Message-Id: <20190404084606.077077235@linuxfoundation.org> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190404084603.119654039@linuxfoundation.org> References: <20190404084603.119654039@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review X-Patchwork-Hint: ignore MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.19-stable review patch. If anyone has any objections, please let me know. ------------------ [ Upstream commit f6d9758b12660484b6639364cc406da92a918c96 ] The following false positive lockdep splat has been observed. ====================================================== WARNING: possible circular locking dependency detected 4.20.0+ #302 Not tainted ------------------------------------------------------ systemd-udevd/160 is trying to acquire lock: edea6080 (&chip->reg_lock){+.+.}, at: __setup_irq+0x640/0x704 but task is already holding lock: edff0340 (&desc->request_mutex){+.+.}, at: __setup_irq+0xa0/0x704 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&desc->request_mutex){+.+.}: mutex_lock_nested+0x1c/0x24 __setup_irq+0xa0/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_probe+0x41c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 -> #0 (&chip->reg_lock){+.+.}: __mutex_lock+0x50/0x8b8 mutex_lock_nested+0x1c/0x24 __setup_irq+0x640/0x704 request_threaded_irq+0xd0/0x150 mv88e6xxx_g2_irq_setup+0xcc/0x1b4 [mv88e6xxx] mv88e6xxx_probe+0x44c/0x694 [mv88e6xxx] mdio_probe+0x2c/0x54 really_probe+0x200/0x2c4 driver_probe_device+0x5c/0x174 __driver_attach+0xd8/0xdc bus_for_each_dev+0x58/0x7c bus_add_driver+0xe4/0x1f0 driver_register+0x7c/0x110 mdio_driver_register+0x24/0x58 do_one_initcall+0x74/0x2e8 do_init_module+0x60/0x1d0 load_module+0x1968/0x1ff4 sys_finit_module+0x8c/0x98 ret_fast_syscall+0x0/0x28 0xbedf2ae8 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&desc->request_mutex); lock(&chip->reg_lock); lock(&desc->request_mutex); lock(&chip->reg_lock); &desc->request_mutex refer to two different mutex. #1 is the GPIO for the chip interrupt. #2 is the chained interrupt between global 1 and global 2. Add lockdep classes to the GPIO interrupt to avoid this. Reported-by: Russell King Signed-off-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/dsa/mv88e6xxx/chip.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/net/dsa/mv88e6xxx/chip.c b/drivers/net/dsa/mv88e6xxx/chip.c index c078c791f481..dabe89968a78 100644 --- a/drivers/net/dsa/mv88e6xxx/chip.c +++ b/drivers/net/dsa/mv88e6xxx/chip.c @@ -442,12 +442,20 @@ out_mapping: static int mv88e6xxx_g1_irq_setup(struct mv88e6xxx_chip *chip) { + static struct lock_class_key lock_key; + static struct lock_class_key request_key; int err; err = mv88e6xxx_g1_irq_setup_common(chip); if (err) return err; + /* These lock classes tells lockdep that global 1 irqs are in + * a different category than their parent GPIO, so it won't + * report false recursion. + */ + irq_set_lockdep_class(chip->irq, &lock_key, &request_key); + err = request_threaded_irq(chip->irq, NULL, mv88e6xxx_g1_irq_thread_fn, IRQF_ONESHOT, -- 2.19.1