Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 03 Mar 2020 14:59:16 -0800 (PST)
Message-Id: <20200303.145916.1506066510928020193.davem@davemloft.net>
To:     mkubecek@suse.cz
Cc:     kuba@kernel.org, netdev@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCH net] tun: fix ethtool_ops get_msglvl and set_msglvl
 handlers
From:   David Miller <davem@davemloft.net>
In-Reply-To: <20200303082252.81F7FE1F46@unicorn.suse.cz>
References: <20200303082252.81F7FE1F46@unicorn.suse.cz>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

From: Michal Kubecek <mkubecek@suse.cz>
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 <mkubecek@suse.cz>

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.