netdev - Re: [net,v7] net: stmmac: fix 'ethtool -P' return -EBUSY

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:   Sat, 31 Jul 2021 11:35:58 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Hao Chen <chenhaoa@...ontech.com>,
        David Miller <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org
Subject: Re: [net,v7] net: stmmac: fix 'ethtool -P' return -EBUSY

On 31.07.2021 07:09, Hao Chen wrote:
> I want to get permanent MAC address when the card is down. And I think
"card is down" isn't precise. The interface is down, and the NIC may be
runtime-suspended.

> it is more convenient to get statistics in the down state by 'ethtool -S'.
> But current all of the ethool command return -EBUSY.
> 
> I don't think we should detect that the network card is up in '. Begin',

You don't mean detect but check here.

> which will cause that all the ethtool commands can't be used when the
> network card is down. If some ethtool commands can only be used in the
> up state, check it in the corresponding ethool OPS function is better.
> This is too rude and unreasonable.
> 
> I have checked the '.begin' implementation of other drivers, most of which
> support the submission of NIC driver for the first time.

What do you mean with "submission for the first time"?

> They are too old to know why '.begin' is implemented. I suspect that they
> have not noticed the usage of '.begin'.
> 
> Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet
> 		     controllers.")
> 

IMO it's not a bug that ethtool calls aren't supported if interface is
down. Therefore personally I'd see this for net-next. Final call is with
the maintainers.

> Compile-tested on arm64. Tested on an arm64 system with an on-board
> STMMAC chip.
> 
> Changes v6 ... v7:
> - fix arg type error of 'dev' to 'priv->device'.
> 
> Changes v5 ... v6:
> - The 4.19.90 kernel not support pm_runtime, so implemente '.begin' and
>   '.complete' again. Add return value check of pm_runtime function.
> 
> Changes v4 ... v5:
> - test the '.begin' will return -13 error on my machine based on 4.19.90
>   kernel. The platform driver does not supported pm_runtime. So remove the
>   implementation of '.begin' and '.complete'.
> 
> Changes v3 ... v4:
> - implement '.complete' ethtool OPS.
> 
> Changes v2 ... v3:
> - add linux/pm_runtime.h head file.
> 
> Changes v1 ... v2:
> - fix spell error of dev.
> 
> Signed-off-by: Hao Chen <chenhaoa@...ontech.com>
> ---
>  .../ethernet/stmicro/stmmac/stmmac_ethtool.c  | 21 +++++++++++++------
>  1 file changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> index d0ce608b81c3..fd5b68f6bf53 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c
> @@ -12,8 +12,9 @@
>  #include <linux/ethtool.h>
>  #include <linux/interrupt.h>
>  #include <linux/mii.h>
> -#include <linux/phylink.h>

Why moving the phylink include?

>  #include <linux/net_tstamp.h>
> +#include <linux/phylink.h>
> +#include <linux/pm_runtime.h>
>  #include <asm/io.h>
>  
>  #include "stmmac.h"
> @@ -410,11 +411,18 @@ static void stmmac_ethtool_setmsglevel(struct net_device *dev, u32 level)
>  
>  }
>  
> -static int stmmac_check_if_running(struct net_device *dev)
> +static int stmmac_ethtool_begin(struct net_device *dev)
>  {
> -	if (!netif_running(dev))
> -		return -EBUSY;
> -	return 0;
> +	struct stmmac_priv *priv = netdev_priv(dev);

Power-managed is the parent of the net_device.
So you could simply use dev->dev.parent.

> +
> +	return pm_runtime_resume_and_get(priv->device);
> +}
> +
> +static void stmmac_ethtool_complete(struct net_device *dev)
> +{
> +	struct stmmac_priv *priv = netdev_priv(dev);
> +
> +	pm_runtime_put(priv->device);
>  }
>  
>  static int stmmac_ethtool_get_regs_len(struct net_device *dev)
> @@ -1073,7 +1081,8 @@ static int stmmac_set_tunable(struct net_device *dev,
>  static const struct ethtool_ops stmmac_ethtool_ops = {
>  	.supported_coalesce_params = ETHTOOL_COALESCE_USECS |
>  				     ETHTOOL_COALESCE_MAX_FRAMES,
> -	.begin = stmmac_check_if_running,
> +	.begin = stmmac_ethtool_begin,
> +	.complete = stmmac_ethtool_complete,
>  	.get_drvinfo = stmmac_ethtool_getdrvinfo,
>  	.get_msglevel = stmmac_ethtool_getmsglevel,
>  	.set_msglevel = stmmac_ethtool_setmsglevel,
> 

You sent this patch to the mailing list only and missed to address the
maintainers.

I think the question whether an ethtool call should wake a network device
from runtime suspend is a general one (at least for all network drivers
with runtime pm support) and not restricted to stmmac. 
Strictly needed is waking the device only if e.g. a chip register is
accessed that isn't available during runtime-suspend. However personally
I'd be fine with the small overhead of always waking the device.

If there's an agreement that this makes sense in general then we may add
this to core code, by e.g. runtime-resuming netdev->dev.parent (and maybe
netdev->dev if netdev has no parent).