diff options
author | Eric Dumazet <edumazet@google.com> | 2015-04-25 09:35:24 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2015-04-26 16:07:57 -0400 |
commit | a31196b07f8034eba6a3487a1ad1bb5ec5cd58a5 (patch) | |
tree | 7f870304863599f718850712a8c02e51359f0897 /drivers/net/bonding | |
parent | 7cdbc6f74f8e6c06304b69b4e944fbd669581c7c (diff) | |
download | linux-stable-a31196b07f8034eba6a3487a1ad1bb5ec5cd58a5.tar.gz linux-stable-a31196b07f8034eba6a3487a1ad1bb5ec5cd58a5.tar.bz2 linux-stable-a31196b07f8034eba6a3487a1ad1bb5ec5cd58a5.zip |
net: rfs: fix crash in get_rps_cpus()
Commit 567e4b79731c ("net: rfs: add hash collision detection") had one
mistake :
RPS_NO_CPU is no longer the marker for invalid cpu in set_rps_cpu()
and get_rps_cpu(), as @next_cpu was the result of an AND with
rps_cpu_mask
This bug showed up on a host with 72 cpus :
next_cpu was 0x7f, and the code was trying to access percpu data of an
non existent cpu.
In a follow up patch, we might get rid of compares against nr_cpu_ids,
if we init the tables with 0. This is silly to test for a very unlikely
condition that exists only shortly after table initialization, as
we got rid of rps_reset_sock_flow() and similar functions that were
writing this RPS_NO_CPU magic value at flow dismantle : When table is
old enough, it never contains this value anymore.
Fixes: 567e4b79731c ("net: rfs: add hash collision detection")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Tom Herbert <tom@herbertland.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'drivers/net/bonding')
0 files changed, 0 insertions, 0 deletions