The get_msglvl and setmsglvl handlers only work as expected if TUN_DEBUG
is defined (which required editing the source). Otherwise tun_get_msglvl()
returns -EOPNOTSUPP but as this handler is not supposed to return error
code, it is not recognized as one and passed to userspace as is, resulting
in bogus output of ethtool command. The set_msglvl handler ignores its
argument and does nothing if TUN_DEBUG is left undefined.
The way to return EOPNOTSUPP to userspace for both requests is not to
provide these ethtool_ops callbacks at all if TUN_DEBUG is left undefined.
Signed-off-by: Michal Kubecek <[email protected]>
---
drivers/net/tun.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 650c937ed56b..0aae2d208398 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -3557,23 +3557,21 @@ static void tun_get_drvinfo(struct net_device *dev, struct ethtool_drvinfo *info
}
}
+#ifdef TUN_DEBUG
static u32 tun_get_msglevel(struct net_device *dev)
{
-#ifdef TUN_DEBUG
struct tun_struct *tun = netdev_priv(dev);
+
return tun->debug;
-#else
- return -EOPNOTSUPP;
-#endif
}
static void tun_set_msglevel(struct net_device *dev, u32 value)
{
-#ifdef TUN_DEBUG
struct tun_struct *tun = netdev_priv(dev);
+
tun->debug = value;
-#endif
}
+#endif /* TUN_DEBUG */
static int tun_get_coalesce(struct net_device *dev,
struct ethtool_coalesce *ec)
@@ -3600,8 +3598,10 @@ static int tun_set_coalesce(struct net_device *dev,
static const struct ethtool_ops tun_ethtool_ops = {
.get_drvinfo = tun_get_drvinfo,
+#ifdef TUN_DEBUG
.get_msglevel = tun_get_msglevel,
.set_msglevel = tun_set_msglevel,
+#endif
.get_link = ethtool_op_get_link,
.get_ts_info = ethtool_op_get_ts_info,
.get_coalesce = tun_get_coalesce,
--
2.25.1
From: Michal Kubecek <[email protected]>
Date: Tue, 3 Mar 2020 09:22:52 +0100 (CET)
> The get_msglvl and setmsglvl handlers only work as expected if TUN_DEBUG
> is defined (which required editing the source). Otherwise tun_get_msglvl()
> returns -EOPNOTSUPP but as this handler is not supposed to return error
> code, it is not recognized as one and passed to userspace as is, resulting
> in bogus output of ethtool command. The set_msglvl handler ignores its
> argument and does nothing if TUN_DEBUG is left undefined.
>
> The way to return EOPNOTSUPP to userspace for both requests is not to
> provide these ethtool_ops callbacks at all if TUN_DEBUG is left undefined.
>
> Signed-off-by: Michal Kubecek <[email protected]>
I agree with your analysis.
But this TUN_DEBUG thing stands outside of what we let drivers do. Either
this tracing is not so useful and can be deleted, or the tracing should
be available unconditionally so that it can be turned on by the vast
majority of users who do not edit the source.
I suspect making the TUN_DEBUG code unconditional is that way to go here.
On Tue, Mar 03, 2020 at 02:59:16PM -0800, David Miller wrote:
> From: Michal Kubecek <[email protected]>
> Date: Tue, 3 Mar 2020 09:22:52 +0100 (CET)
>
> > The get_msglvl and setmsglvl handlers only work as expected if TUN_DEBUG
> > is defined (which required editing the source). Otherwise tun_get_msglvl()
> > returns -EOPNOTSUPP but as this handler is not supposed to return error
> > code, it is not recognized as one and passed to userspace as is, resulting
> > in bogus output of ethtool command. The set_msglvl handler ignores its
> > argument and does nothing if TUN_DEBUG is left undefined.
> >
> > The way to return EOPNOTSUPP to userspace for both requests is not to
> > provide these ethtool_ops callbacks at all if TUN_DEBUG is left undefined.
> >
> > Signed-off-by: Michal Kubecek <[email protected]>
>
> I agree with your analysis.
>
> But this TUN_DEBUG thing stands outside of what we let drivers do. Either
> this tracing is not so useful and can be deleted, or the tracing should
> be available unconditionally so that it can be turned on by the vast
> majority of users who do not edit the source.
>
> I suspect making the TUN_DEBUG code unconditional is that way to go here.
I started to think in this direction too and ended up with
- DBG1() macro checks a variable which is never set; it's also used
only in one place which doesn't seem to differ from others where
tun_debug() is used
- many tun_debug() calls can be dropped as they only inform about
entering a function and sometimes show some if its arguments; we
have ftrace and kprobes for that
- the rest should be rewritten to netif_info()
- the two tun_debug() in packet processing path could use netif_dbg()
to avoid overhead when not turned on
...which is where I stopped and went with the quick fix instead.
On the other hand, there is no rush, the issue seems to exist since
before git. And unlike some other drivers doing strange things for
debugging, tun is widely used so it deserves a cleanup.
I'll send a patch (or patches) with proper cleanup for net-next.
Michal