[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171208.142931.969279261124372071.davem@davemloft.net>
Date: Fri, 08 Dec 2017 14:29:31 -0500 (EST)
From: David Miller <davem@...emloft.net>
To: david.daney@...ium.com
Cc: linux-mips@...ux-mips.org, ralf@...ux-mips.org,
james.hogan@...s.com, netdev@...r.kernel.org, robh+dt@...nel.org,
mark.rutland@....com, linux-kernel@...r.kernel.org,
steven.hill@...ium.com, devicetree@...r.kernel.org, andrew@...n.ch,
f.fainelli@...il.com, pombredanne@...b.com, cmunoz@...ium.com
Subject: Re: [PATCH v6 net-next,mips 6/7] netdev: octeon-ethernet: Add
Cavium Octeon III support.
From: David Daney <david.daney@...ium.com>
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.
Powered by blists - more mailing lists