netdev - Re: [PATCH 10/13] ftgmac100: Add a reset task and use it for link changes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170402184237.GB5189@lunn.ch>
Date:   Sun, 2 Apr 2017 20:42:37 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:     netdev@...r.kernel.org
Subject: Re: [PATCH 10/13] ftgmac100: Add a reset task and use it for link
 changes

> +static void ftgmac100_reset_task(struct work_struct *work)
> +{
> +	struct ftgmac100 *priv = container_of(work, struct ftgmac100,
> +					      reset_task);
> +	struct net_device *netdev = priv->netdev;
> +	int err;
> +
> +	netdev_dbg(netdev, "Resetting NIC...\n");
> +
> +	/* Block PHY polling */
> +	if (netdev->phydev)
> +		mutex_lock(&netdev->phydev->lock);
> +
> +	rtnl_lock();

Hi Ben

Have you run lockdep tests on this? I think it is normal to take the
rtnl lock first, then the phydev lock. Try some ethtool operations and
see if you get a splat.

Also, do you need to be worried about mdio operations? Do you need to
take that lock as well, since there might be other PHYs, or an
Ethernet switch on the bus?

    Andrew