netdev - Re: [PATCH net-next] ibmvnic: Increase driver logging

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:   Thu, 16 Jul 2020 13:22:00 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Michal Suchánek <msuchanek@...e.de>
Cc:     Thomas Falcon <tlfalcon@...ux.ibm.com>,
        David Miller <davem@...emloft.net>, drt@...ux.ibm.com,
        netdev@...r.kernel.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH net-next] ibmvnic: Increase driver logging

On Thu, 16 Jul 2020 18:07:37 +0200 Michal Suchánek wrote:
> On Thu, Jul 16, 2020 at 10:59:58AM -0500, Thomas Falcon wrote:
> > On 7/15/20 8:29 PM, David Miller wrote:  
> > > From: Jakub Kicinski <kuba@...nel.org>
> > > Date: Wed, 15 Jul 2020 17:06:32 -0700
> > >   
> > > > On Wed, 15 Jul 2020 18:51:55 -0500 Thomas Falcon wrote:  
> > > > >   	free_netdev(netdev);
> > > > >   	dev_set_drvdata(&dev->dev, NULL);
> > > > > +	netdev_info(netdev, "VNIC client device has been successfully removed.\n");  
> > > > A step too far, perhaps.
> > > > 
> > > > In general this patch looks a little questionable IMHO, this amount of
> > > > logging output is not commonly seen in drivers. All the the info
> > > > messages are just static text, not even carrying any extra information.
> > > > In an era of ftrace, and bpftrace, do we really need this?  
> > > Agreed, this is too much.  This is debugging, and thus suitable for tracing
> > > facilities, at best.  
> > 
> > Thanks for your feedback. I see now that I was overly aggressive with this
> > patch to be sure, but it would help with narrowing down problems at a first
> > glance, should they arise. The driver in its current state logs very little
> > of what is it doing without the use of additional debugging or tracing
> > facilities. Would it be worth it to pursue a less aggressive version or
> > would that be dead on arrival? What are acceptable driver operations to log
> > at this level?  

Sadly it's much more of an art than hard science. Most networking
drivers will print identifying information when they probe the device
and then only about major config changes or when link comes up or goes
down. And obviously when anything unexpected, like an error happens,
that's key.

You seem to be adding start / end information for each driver init /
deinit stage. I'd say try to focus on the actual errors you're trying
to catch.

> Also would it be advisable to add the messages as pr_dbg to be enabled on demand?

I personally have had a pretty poor experience with pr_debug() because
CONFIG_DYNAMIC_DEBUG is not always enabled. Since you're just printing
static text there shouldn't be much difference between pr_debug and
ftrace and/or bpftrace, honestly.

Again, slightly hard to advise not knowing what you're trying to catch.