netdev - Re: [PATCHv3 net-next] ipmr: remove hard code cache_resolve_queue

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20190907.174942.662063905491373058.davem@davemloft.net>
Date:   Sat, 07 Sep 2019 17:49:42 +0200 (CEST)
From:   David Miller <davem@...emloft.net>
To:     liuhangbin@...il.com
Cc:     netdev@...r.kernel.org, karn@...q.net, sukumarg1973@...il.com,
        kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org,
        eric.dumazet@...il.com
Subject: Re: [PATCHv3 net-next] ipmr: remove hard code
 cache_resolve_queue_len limit

From: Hangbin Liu <liuhangbin@...il.com>
Date: Fri,  6 Sep 2019 15:36:01 +0800

> This is a re-post of previous patch wrote by David Miller[1].
> 
> Phil Karn reported[2] that on busy networks with lots of unresolved
> multicast routing entries, the creation of new multicast group routes
> can be extremely slow and unreliable.
> 
> The reason is we hard-coded multicast route entries with unresolved source
> addresses(cache_resolve_queue_len) to 10. If some multicast route never
> resolves and the unresolved source addresses increased, there will
> be no ability to create new multicast route cache.
> 
> To resolve this issue, we need either add a sysctl entry to make the
> cache_resolve_queue_len configurable, or just remove cache_resolve_queue_len
> limit directly, as we already have the socket receive queue limits of mrouted
> socket, pointed by David.
> 
> From my side, I'd perfer to remove the cache_resolve_queue_len limit instead
> of creating two more(IPv4 and IPv6 version) sysctl entry.
> 
> [1] https://lkml.org/lkml/2018/7/22/11
> [2] https://lkml.org/lkml/2018/7/21/343
> 
> v3: instead of remove cache_resolve_queue_len totally, let's only remove
> the hard code limit when allocate the unresolved cache, as Eric Dumazet
> suggested, so we don't need to re-count it in other places.
> 
> v2: hold the mfc_unres_lock while walking the unresolved list in
> queue_count(), as Nikolay Aleksandrov remind.
> 
> Reported-by: Phil Karn <karn@...q.net>
> Signed-off-by: Hangbin Liu <liuhangbin@...il.com>

Applied to net-next.