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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AC6DDC433F5 for ; Thu, 17 Feb 2022 12:12:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240309AbiBQMMy (ORCPT ); Thu, 17 Feb 2022 07:12:54 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:50130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239451AbiBQMMx (ORCPT ); Thu, 17 Feb 2022 07:12:53 -0500 Received: from vps0.lunn.ch (vps0.lunn.ch [185.16.172.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1D9CF1FA55; Thu, 17 Feb 2022 04:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lunn.ch; s=20171124; h=In-Reply-To:Content-Disposition:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:From:Sender:Reply-To:Subject: Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description:Content-Disposition:In-Reply-To:References; bh=1KoWgBTUlo4nDLAUw7bf+UHEGG4Wj8YcA8JBHAxpzdA=; b=vU16ZIZEOKIv+Zy5HMk99Fl4NW m+Tihn9pusbecPWEJNsvCw0qXEMoe4znQwja8zPLQkV35QkKql5Jb0kW+jVXuGLDMH+Ga6LGxTVtk mOxEeJbyg3yAAZxIuCfntdxO7ZPWb/f4yYfiOiPQ9AOgimfSYYXtnE0En4rmJzjUBxJQ=; Received: from andrew by vps0.lunn.ch with local (Exim 4.94.2) (envelope-from ) id 1nKfdz-006ML2-GY; Thu, 17 Feb 2022 13:12:19 +0100 Date: Thu, 17 Feb 2022 13:12:19 +0100 From: Andrew Lunn To: Alvin =?utf-8?Q?=C5=A0ipraga?= Cc: Luiz Angelo Daros de Luca , Alvin =?utf-8?Q?=C5=A0ipraga?= , Linus Walleij , Vivien Didelot , Florian Fainelli , Vladimir Oltean , "David S. Miller" , Jakub Kicinski , Michael Rasmussen , =?utf-8?B?QXLEsW7DpyDDnE5BTA==?= , "open list:NETWORKING DRIVERS" , open list Subject: Re: [PATCH net-next 0/2] net: dsa: realtek: fix PHY register read corruption Message-ID: References: <20220216160500.2341255-1-alvin@pqrs.dk> <87k0dusmar.fsf@bang-olufsen.dk> <878ruasjd8.fsf@bang-olufsen.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <878ruasjd8.fsf@bang-olufsen.dk> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > Thank you Andrew for the clear explanation. > > Somewhat unrelated to this series, but are you able to explain to me the > difference between: > > mutex_lock(&bus->mdio_lock); > and > mutex_lock_nested(&bus->mdio_lock, MDIO_MUTEX_NESTED); > > While looking at other driver examples I noticed the latter form quite a > few times too. This is to do with the debug code for checking for deadlocks, CONFIG_PROVE_LOCKING. When that feature is enables, each lock/unlock of a mutex is tracked, and a list is made of what other locks are also taken, and the order. The code can find deadlocks where one thread takes A then B, while another thread takes B and then A. It can also detect when a thread takes lock A and then tries to take lock A again. Rather than track each individual mutex, it uses classes of mutex. So bus->mdio_lock is a class of mutex. The code simply tracks that a bus->mdio_lock has been taken, not a specific bus->mdio_lock. That is generally sufficient, but not always. The mv88e6xxx switch is like many switches, accessed over MDIO. But the mv88e6xxx switch offers an MDIO bus, and there is an MDIO bus driver inside the mv88e6xxx driver. So you have nested MDIO calls. So this debug code seems the same class of mutex being taken twice, and thinks it is a deadlock. You can tell it that nested MDIO calls are actually O.K, it won't deadlock. Andrew