summaryrefslogtreecommitdiffstats
path: root/mm/filemap_xip.c
diff options
context:
space:
mode:
authorWillem de Bruijn <willemb@google.com>2013-06-13 15:29:38 -0400
committerDavid S. Miller <davem@davemloft.net>2013-06-13 17:13:05 -0700
commit5f121b9a83b499a61ed44e5ba619c7de8f7271ad (patch)
tree6765d95f468e5c8c884af26f5fbfd2c6428d255d /mm/filemap_xip.c
parent85f16525a2eb66e6092cbd8dcf42371df8334ed0 (diff)
downloadlinux-5f121b9a83b499a61ed44e5ba619c7de8f7271ad.tar.bz2
net-rps: fixes for rps flow limit
Caught by sparse: - __rcu: missing annotation to sd->flow_limit - __user: direct access in cpumask_scnprintf Also - add endline character when printing bitmap if room in buffer - avoid bucket overflow by reducing FLOW_LIMIT_HISTORY The last item warrants some explanation. The hashtable buckets are subject to overflow if FLOW_LIMIT_HISTORY is larger than or equal to bucket size, since all packets may end up in a single bucket. The current (rather arbitrary) history value of 256 happens to match the buffer size (u8). As a result, with a single flow, the first 128 packets are accepted (correct), the second 128 packets dropped (correct) and then the history[] array has filled, so that each subsequent new packet causes an increment in the bucket for new_flow plus a decrement for old_flow: a steady state. This is fine if packets are dropped, as the steady state goes away as soon as a mix of traffic reappears. But, because the 256th packet overflowed the bucket to 0: no packets are dropped. Instead of explicitly adding an overflow check, this patch changes FLOW_LIMIT_HISTORY to never be able to overflow a single bucket. Reported-by: Fengguang Wu <fengguang.wu@intel.com> (first item) Signed-off-by: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'mm/filemap_xip.c')
0 files changed, 0 insertions, 0 deletions