diff options
author | Willem de Bruijn <willemb@google.com> | 2013-06-13 15:29:38 -0400 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2013-06-13 17:13:05 -0700 |
commit | 5f121b9a83b499a61ed44e5ba619c7de8f7271ad (patch) | |
tree | 6765d95f468e5c8c884af26f5fbfd2c6428d255d /mm/filemap_xip.c | |
parent | 85f16525a2eb66e6092cbd8dcf42371df8334ed0 (diff) | |
download | linux-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