summaryrefslogtreecommitdiffstats
path: root/mm/page_vma_mapped.c
diff options
context:
space:
mode:
authorJesper Dangaard Brouer <brouer@redhat.com>2017-06-14 13:27:37 +0200
committerDavid S. Miller <davem@davemloft.net>2017-06-14 15:33:58 -0400
commit849a44de91636c24cea799cb8ad8c36433feb913 (patch)
tree401229e174fa94ffe0234295777b5c4df181fafd /mm/page_vma_mapped.c
parentc4f65b09b459c6f0ec27b1a1a65302f7fea5c96f (diff)
downloadlinux-849a44de91636c24cea799cb8ad8c36433feb913.tar.gz
linux-849a44de91636c24cea799cb8ad8c36433feb913.tar.bz2
linux-849a44de91636c24cea799cb8ad8c36433feb913.zip
net: don't global ICMP rate limit packets originating from loopback
Florian Weimer seems to have a glibc test-case which requires that loopback interfaces does not get ICMP ratelimited. This was broken by commit c0303efeab73 ("net: reduce cycles spend on ICMP replies that gets rate limited"). An ICMP response will usually be routed back-out the same incoming interface. Thus, take advantage of this and skip global ICMP ratelimit when the incoming device is loopback. In the unlikely event that the outgoing it not loopback, due to strange routing policy rules, ICMP rate limiting still works via peer ratelimiting via icmpv4_xrlim_allow(). Thus, we should still comply with RFC1812 (section 4.3.2.8 "Rate Limiting"). This seems to fix the reproducer given by Florian. While still avoiding to perform expensive and unneeded outgoing route lookup for rate limited packets (in the non-loopback case). Fixes: c0303efeab73 ("net: reduce cycles spend on ICMP replies that gets rate limited") Reported-by: Florian Weimer <fweimer@redhat.com> Reported-by: "H.J. Lu" <hjl.tools@gmail.com> Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'mm/page_vma_mapped.c')
0 files changed, 0 insertions, 0 deletions