From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 00D02C43381 for ; Sun, 17 Feb 2019 17:55:46 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id C855F218AD for ; Sun, 17 Feb 2019 17:55:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=lunn.ch header.i=@lunn.ch header.b="bk+K/Wre" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727956AbfBQRzo (ORCPT ); Sun, 17 Feb 2019 12:55:44 -0500 Received: from vps0.lunn.ch ([185.16.172.187]:55810 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725811AbfBQRzo (ORCPT ); Sun, 17 Feb 2019 12:55:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=drtcFvAi3TprdOWqrre4WiNtBSmVOxMJ2uMAEWKWtJU=; b=bk+K/WreuqZjGwebsQCpNWh3Xw I2vaEiCZ6YnDqou8wne/eQdhLHJbOv45f+SRRCE4pKPzpzz6ETyqlEdVPA3wCVrEGNOoBh95lCzv7 ra454LR9sihnHab0cHf0gPo5O/beU0IQQwzbLXiv9NzLdbak0GkyTJeP59ZoZ7nvbMLo=; Received: from andrew by vps0.lunn.ch with local (Exim 4.89) (envelope-from ) id 1gvQfD-0003gu-Bp; Sun, 17 Feb 2019 18:55:39 +0100 Date: Sun, 17 Feb 2019 18:55:39 +0100 From: Andrew Lunn To: Russell King Cc: Florian Fainelli , Vivien Didelot , Heiner Kallweit , "David S. Miller" , netdev@vger.kernel.org Subject: Re: [PATCH net] net: dsa: fix lockdep warning Message-ID: <20190217175539.GI5968@lunn.ch> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sun, Feb 17, 2019 at 04:27:32PM +0000, Russell King wrote: > ====================================================== > 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] > -> #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 > > 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); Hi Russell I failed to reproduce it on a Freescale system. Which made me take a closer look at the above. This is a false positive. In #1 we are requesting the GPIO interrupt. In #2 we are requesting the chained interrupt from the mv88e6xxx global 1 interrupt handler. So these are different desc->request_mutex. The Freescale VF610 GPIO driver uses gpiochip_irqchip_add(), which creates a lock class for the GPIO. The marvell gpio-mvebu driver does not create a lock class. So when i test on Freescale, lockdep can tell they are different mutex, but on clearfog it cannot. So i think the real fix is probably two fold, although just doing one is sufficient: 1) Add lock classes to gpio-mvebu, by call irq_set_lockdep_class() 2) Add lock classes to chip.c global 1, by calling irq_set_lockdep_class() There is probably more value in 1) since the mvebu gpio driver is much more widely used than the mv88e6xxx driver. Andrew