linux-mips
[Top] [All Lists]

Re: [PATCH v6 net-next,mips 6/7] netdev: octeon-ethernet: Add Cavium Oct

To: david.daney@cavium.com
Subject: Re: [PATCH v6 net-next,mips 6/7] netdev: octeon-ethernet: Add Cavium Octeon III support.
From: David Miller <davem@davemloft.net>
Date: Fri, 08 Dec 2017 14:29:31 -0500 (EST)
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
In-reply-to: <20171208000934.6554-7-david.daney@cavium.com>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20171208000934.6554-1-david.daney@cavium.com> <20171208000934.6554-7-david.daney@cavium.com>
Sender: linux-mips-bounce@linux-mips.org
From: David Daney <david.daney@cavium.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.

<Prev in Thread] Current Thread [Next in Thread>