diff options
author | David S. Miller <davem@davemloft.net> | 2013-02-13 18:18:20 (GMT) |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2013-02-13 18:18:20 (GMT) |
commit | d0023f820e003857248d14f2213ac3930283f16c (patch) | |
tree | 8a821bff0bc791e23441e90835db6e348ffa407e /lib/interval_tree.c | |
parent | 959d5fdee7aa32fa04bc2c37e3d3871ad266fe97 (diff) | |
parent | 212079df6d77c0daada96b1d906f4b7749871411 (diff) | |
download | linux-fsl-qoriq-d0023f820e003857248d14f2213ac3930283f16c.tar.xz |
Merge branch 'gfar-ethtool-atomic' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux
Paul Gortmaker says:
====================
Eric noticed that the handling of local u64 ethtool counters for
this driver commonly found on Freescale ppc-32 boards was racy.
However, before converting them over to atomic64_t, I noticed
that an internal struct was being used to determine the offsets
for exporting this data into the ethtool buffer, and in doing
so, it assumed that the counters would always be u64. Rather
than keep this implicit assumption, a simple code cleanup gets
rid of the struct completely, and leaves less conversion sites.
The alternative solution would have been to take advantage of
the fact that the counters are all relating to error conditions,
and hence make them internally u32. In doing so, we'd be assuming
that U32_MAX of any particular error condition is highly unlikely.
This might have made sense if any increments were in a hot path.
Tested with "ethtool -S eth0" on sbc8548 board.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'lib/interval_tree.c')
0 files changed, 0 insertions, 0 deletions