netdev - Re: [PATCH net 1/3] bnxt_en: Fix accumulation of bp->net_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]

Date:   Tue, 26 May 2020 15:43:52 -0700
From:   Michael Chan <michael.chan@...adcom.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     David Miller <davem@...emloft.net>, Netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net 1/3] bnxt_en: Fix accumulation of bp->net_stats_prev.

On Tue, May 26, 2020 at 3:04 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Mon, 25 May 2020 17:41:17 -0400 Michael Chan wrote:
> > We have logic to maintain network counters across resets by storing
> > the counters in bp->net_stats_prev before reset.  But not all resets
> > will clear the counters.  Certain resets that don't need to change
> > the number of rings do not clear the counters.  The current logic
> > accumulates the counters before all resets, causing big jumps in
> > the counters after some resets, such as ethtool -G.
> >
> > Fix it by only accumulating the counters during reset if the irq_re_init
> > parameter is set.  The parameter signifies that all rings and interrupts
> > will be reset and that means that the counters will also be reset.
> >
> > Reported-by: Vijayendra Suman <vijayendra.suman@...cle.com>
> > Fixes: b8875ca356f1 ("bnxt_en: Save ring statistics before reset.")
> > Signed-off-by: Michael Chan <michael.chan@...adcom.com>
>
> Hi Michael!
>
> Could you explain why accumulating counters causes a jump?

Yes, during chip reset, we free most hardware resources including
possibly hardware counter resources.  After freeing the hardware
counters, the counters will go to zero.  To preserve the counters, we
take a snapshot of the hardware counters and add them to the
bp->net_stats_prev.  The counters in bp->net_stats_prev are always
added to the current hardware counters to provide the true counters.

The problem is that not all resets will free the hardware counters.
The old code is unconditionally taking the snapshot during reset.  So
when we don't free the hardware counters, the snapshot will cause us
to effectively double the hardware counters after the reset.