netdev - Re: [PATCH v2] l2tp: use per-cpu variables for u64

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: <1340832947.26242.169.camel@edumazet-glaptop>
Date:	Wed, 27 Jun 2012 23:35:47 +0200
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	Ben Greear <greearb@...delatech.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>,
	Rick Jones <rick.jones2@...com>,
	Tom Parkin <tparkin@...alix.com>, netdev@...r.kernel.org,
	David.Laight@...LAB.COM, James Chapman <jchapman@...alix.com>
Subject: Re: [PATCH v2] l2tp: use per-cpu variables for u64_stats updates

On Wed, 2012-06-27 at 14:31 -0700, Ben Greear wrote:

> For an example, see the VLAN code. rx-errors and tx-dropped are only 32-bit
> counters.  Now, in the real world, we wouldn't expect those counters to
> increase at high rates, but they are still 32-bit counters masquerading
> as 64, and they could wrap after a while, so any code that expected a wrap
> to mean a 64-bit wrap would be wrong.
> 
> At the time I was last complaining, there were lots more cases
> of this that I was fighting with, but I don't recall exactly what they
> were.  Once my user-space code got paranoid enough, it was able to
> at least mostly deal with 32 and 64 wraps.

Good, you now know how to deal correctly with these things.

Using 64bit fields for tx_dropped is what I call kernel bloat.

If only all drops were correctly accounted...

I believe 50% of drivers are buggy in this aspect.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html