netdev - Re: [PATCH net-next 13/15] vxlan: Do not treat dst cache initialization errors as fatal

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2c7972c1-ffcf-4d28-83ec-1dfe5dceb8d2@redhat.com>
Date: Tue, 22 Apr 2025 10:49:12 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Ido Schimmel <idosch@...dia.com>, netdev@...r.kernel.org
Cc: davem@...emloft.net, kuba@...nel.org, edumazet@...gle.com,
 andrew+netdev@...n.ch, horms@...nel.org, petrm@...dia.com,
 razor@...ckwall.org
Subject: Re: [PATCH net-next 13/15] vxlan: Do not treat dst cache
 initialization errors as fatal

On 4/15/25 2:11 PM, Ido Schimmel wrote:
> FDB entries are allocated in an atomic context as they can be added from
> the data path when learning is enabled.
> 
> After converting the FDB hash table to rhashtable, the insertion rate
> will be much higher (*) which will entail a much higher rate of per-CPU
> allocations via dst_cache_init().
> 
> When adding a large number of entries (e.g., 256k) in a batch, a small
> percentage (< 0.02%) of these per-CPU allocations will fail [1]. This
> does not happen with the current code since the insertion rate is low
> enough to give the per-CPU allocator a chance to asynchronously create
> new chunks of per-CPU memory.
> 
> Given that:
> 
> a. Only a small percentage of these per-CPU allocations fail.
> 
> b. The scenario where this happens might not be the most realistic one.
> 
> c. The driver can work correctly without dst caches. The dst_cache_*()
> APIs first check that the dst cache was properly initialized.
> 
> d. The dst caches are not always used (e.g., 'tos inherit').
> 
> It seems reasonable to not treat these allocation failures as fatal.
> 
> Therefore, do not bail when dst_cache_init() fails and suppress warnings
> by specifying '__GFP_NOWARN'.
> 
> [1] percpu: allocation failed, size=40 align=8 atomic=1, atomic alloc failed, no space left
> 
> (*) 97% reduction in average latency of vxlan_fdb_update() when adding
> 256k entries in a batch.
> 
> Reviewed-by: Petr Machata <petrm@...dia.com>
> Signed-off-by: Ido Schimmel <idosch@...dia.com>
> ---
>  drivers/net/vxlan/vxlan_core.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/vxlan/vxlan_core.c b/drivers/net/vxlan/vxlan_core.c
> index 2846c8c5234e..5c0752161529 100644
> --- a/drivers/net/vxlan/vxlan_core.c
> +++ b/drivers/net/vxlan/vxlan_core.c
> @@ -619,10 +619,10 @@ static int vxlan_fdb_append(struct vxlan_fdb *f,
>  	if (rd == NULL)
>  		return -ENOMEM;
>  
> -	if (dst_cache_init(&rd->dst_cache, GFP_ATOMIC)) {
> -		kfree(rd);
> -		return -ENOMEM;
> -	}
> +	/* The driver can work correctly without a dst cache, so do not treat
> +	 * dst cache initialization errors as fatal.
> +	 */
> +	dst_cache_init(&rd->dst_cache, GFP_ATOMIC | __GFP_NOWARN);

Note for a possible follow-up: AFAICS, when the allocation fail the
user-space will have no way to detect it, except for slow down on tx
using this specific FDB entry, which could be surprising/hard to debug
or investigate. What about adding an explicit pr_info() message here?

Thanks,

Paolo

>  
>  	rd->remote_ip = *ip;
>  	rd->remote_port = port;