This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Tests for res_init
On 06/04/2017 07:10 AM, H.J. Lu wrote:
> This commit:
> commit c0303efeab7391ec51c337e0ac5740860ad01fe7
> Author: Jesper Dangaard Brouer <email@example.com>
> Date: Mon Jan 9 16:04:09 2017 +0100
> net: reduce cycles spend on ICMP replies that gets rate limited
> This patch split the global and per (inet)peer ICMP-reply limiter
> code, and moves the global limit check to earlier in the packet
> processing path. Thus, avoid spending cycles on ICMP replies that
> gets limited/suppressed anyhow.
> The global ICMP rate limiter icmp_global_allow() is a good solution,
> it just happens too late in the process. The kernel goes through the
> full route lookup (return path) for the ICMP message, before taking
> the rate limit decision of not sending the ICMP reply.
> Details: The kernels global rate limiter for ICMP messages got added
> in commit 4cdf507d5452 ("icmp: add a global rate limitation"). It is
> a token bucket limiter with a global lock. It brilliantly avoids
> locking congestion by only updating when 20ms (HZ/50) were elapsed. It
> can then avoids taking lock when credit is exhausted (when under
> pressure) and time constraint for refill is not yet meet.
> Signed-off-by: Jesper Dangaard Brouer <firstname.lastname@example.org>
> Acked-by: Eric Dumazet <email@example.com>
> Signed-off-by: David S. Miller <firstname.lastname@example.org>
> is the culprit. This patch for kernel 4.11.3 reverts it and fixes
> my problems.
Makes sense. There does not seem to be any check left that localhost
responses aren't rate-limited. Furthermore, the rate limit is not
namespace-specific, so the network namespace used in the test doesn't
provide any isolation.
I think I'll have enough information to write a reduced test case, and
I'll approach the kernel developers to get this fixed upstream.