Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753039AbdLHT3g (ORCPT ); Fri, 8 Dec 2017 14:29:36 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:57934 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752111AbdLHT3d (ORCPT ); Fri, 8 Dec 2017 14:29:33 -0500 Date: Fri, 08 Dec 2017 14:29:31 -0500 (EST) Message-Id: <20171208.142931.969279261124372071.davem@davemloft.net> To: david.daney@cavium.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, james.hogan@mips.com, netdev@vger.kernel.org, robh+dt@kernel.org, mark.rutland@arm.com, linux-kernel@vger.kernel.org, steven.hill@cavium.com, devicetree@vger.kernel.org, andrew@lunn.ch, f.fainelli@gmail.com, pombredanne@nexb.com, cmunoz@cavium.com Subject: Re: [PATCH v6 net-next,mips 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support. From: David Miller In-Reply-To: <20171208000934.6554-7-david.daney@cavium.com> References: <20171208000934.6554-1-david.daney@cavium.com> <20171208000934.6554-7-david.daney@cavium.com> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Fri, 08 Dec 2017 11:29:33 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 953 Lines: 33 From: David Daney Date: Thu, 7 Dec 2017 16:09:33 -0800 > +static void bgx_port_check_state(struct work_struct *work) > +{ ... > + mutex_lock(&priv->lock); > + if (priv->work_queued) > + queue_delayed_work(check_state_wq, &priv->dwork, HZ); > + mutex_unlock(&priv->lock); > +} ... > +int bgx_port_disable(struct net_device *netdev) > +{ ... > + mutex_lock(&priv->lock); > + if (priv->work_queued) { > + cancel_delayed_work_sync(&priv->dwork); > + priv->work_queued = false; This can deadlock. When you do a sync work cancel, it waits until all running work instances finish. You have the priv->lock, so if bgx_port_check_status() need to still take priv->lock to complete then no further progress will be made. I think it is pointless to use this weird work_queued boolean state. Just unconditionally, and without locking, cancel the delayed work, ragardless of whether it was actually used ever or not. Thank you.