linux-kernel - Re: [PATCH net-next iproute2] iplink: display rx nohandler stats

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: <20160210132059.GB17296@redhat.com>
Date:	Wed, 10 Feb 2016 08:20:59 -0500
From:	Jarod Wilson <jarod@...hat.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	Jamal Hadi Salim <jhs@...atatu.com>,
	David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org, edumazet@...gle.com,
	jiri@...lanox.com, daniel@...earbox.net, tom@...bertland.com,
	j.vosburgh@...il.com, vfalico@...il.com, gospo@...ulusnetworks.com,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next iproute2] iplink: display rx nohandler stats

On Tue, Feb 09, 2016 at 08:52:38PM -0800, Eric Dumazet wrote:
> On Tue, 2016-02-09 at 17:41 -0800, Stephen Hemminger wrote:
> > On Tue, 9 Feb 2016 18:51:35 -0500
> > Jarod Wilson <jarod@...hat.com> wrote:
> > 
> > > On Tue, Feb 09, 2016 at 11:17:57AM -0800, Stephen Hemminger wrote:
> > > > Support for the new rx_nohandler statistic.
> > > > This code is designed to handle the case where the kernel reported statistic
> > > > structure is smaller than the larger structure in later releases (and vice versa).
> > > 
> > > This seems to work here, for the most part. However, if you are running a
> > > kernel with the new counter, and the counter happens to contain 0, aren't
> > > we going to not print anything?
> > 
> > That is the desirable outcome, since if run on older system the
> > output format will not change from current format.
> 
> The problem here is that a change in output might break some user
> scripts using sed/whatever games.
> 
> So it might be better to output a zero field, so that such breakages are
> detected early, even if no packet was dropped at the time the new kernel
> was tested.
> 
> Having a binary that adds the new field only in some cases hides the
> change. It looks fine for us humans, but not for programs processing the
> output.

On my test setup, my bond's active interface currently has 0, while the
backup interface has a few thousand, so I can alternate back and forth
checking the interfaces, and one doesn't print the counter while the other
does, which is what seemed odd to me and prompted the added ugliness. But
most setups (anything outside of bond/team currently) should never have
this counter incremented, we do have prior art with the compressed fields,
and scripts really probably ought to be scraping stats out of sysfs rather
than using ip, so I can sort of understand not wanting the added ugliness.
I do tend to prefer consistency though.

-- 
Jarod Wilson
jarod@...hat.com