summaryrefslogtreecommitdiffstats
path: root/security/apparmor/policy_unpack.c
diff options
context:
space:
mode:
authorDavid S. Miller <davem@davemloft.net>2013-02-13 13:18:20 -0500
committerDavid S. Miller <davem@davemloft.net>2013-02-13 13:18:20 -0500
commitd0023f820e003857248d14f2213ac3930283f16c (patch)
tree8a821bff0bc791e23441e90835db6e348ffa407e /security/apparmor/policy_unpack.c
parent959d5fdee7aa32fa04bc2c37e3d3871ad266fe97 (diff)
parent212079df6d77c0daada96b1d906f4b7749871411 (diff)
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 'security/apparmor/policy_unpack.c')
0 files changed, 0 insertions, 0 deletions