netdev - Re: [PATCH net] net/mlx5e: limit log messages due to (ovs) probing to

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]

Message-ID: <20200408215422.GA137894@localhost.localdomain>
Date:   Wed, 8 Apr 2020 18:54:22 -0300
From:   "marcelo.leitner@...il.com" <marcelo.leitner@...il.com>
To:     Saeed Mahameed <saeedm@...lanox.com>
Cc:     "linux-rdma@...r.kernel.org" <linux-rdma@...r.kernel.org>,
        "leon@...nel.org" <leon@...nel.org>, Roi Dayan <roid@...lanox.com>,
        Paul Blakey <paulb@...lanox.com>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Vlad Buslov <vladbu@...lanox.com>,
        Oz Shlomo <ozsh@...lanox.com>
Subject: Re: [PATCH net] net/mlx5e: limit log messages due to (ovs) probing
 to _once

On Wed, Apr 08, 2020 at 07:51:22PM +0000, Saeed Mahameed wrote:
...
> > > I understand it is for debug only but i strongly suggest to not
> > > totally
> > > suppress these messages and maybe just move them to tracepoints
> > > buffer
> > > ? for those who would want to really debug .. 
> > > 
> > > we already have some tracepoints implemented for en_tc.c 
> > > mlx5/core/diag/en_tc_tracepoints.c, maybe we should define a
> > > tracepoint
> > > for error reporting .. 
> > 
> > That, or s/netdev_warn/netdev_dbg/, but both are more hidden to the
> > user than the _once.
> > 
> 
> i don't see any reason to pollute kernel log with debug messages when
> we have tracepoint buffer for en_tc .. 

So we're agreeing that these need to be changed. Good.

I don't think a sysadmin would be using tracepoints for
troubleshooting this, but okay. My only objective here is exactly what
you said, to not pollute kernel log too much with these potentially
repetitive messages.