netdev - Re: [PATCH v2 net-next 4/7] Revert "ipv6: sr: switch to GFP_ATOMIC flag to allocate memory during seg6local LWT setup"

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: <20250520033705.662cb221ec3e55a4ad08736a@uniroma2.it>
Date: Tue, 20 May 2025 03:37:05 +0200
From: Andrea Mayer <andrea.mayer@...roma2.it>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: "David S. Miller" <davem@...emloft.net>, David Ahern
 <dsahern@...nel.org>,
        Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
 <kuba@...nel.org>,
        "Paolo Abeni" <pabeni@...hat.com>, Simon Horman
 <horms@...nel.org>,
        Kuniyuki Iwashima <kuni1840@...il.com>, <netdev@...r.kernel.org>,
        Andrea Mayer <andrea.mayer@...roma2.it>
Subject: Re: [PATCH v2 net-next 4/7] Revert
 "ipv6: sr: switch to GFP_ATOMIC flag to allocate memory during seg6local LWT setup"

On Thu, 15 May 2025 19:27:20 -0700
Kuniyuki Iwashima <kuniyu@...zon.com> wrote:

> The previous patch fixed the same issue mentioned in
> commit 14a0087e7236 ("ipv6: sr: switch to GFP_ATOMIC
> flag to allocate memory during seg6local LWT setup").
> 
> Let's revert it.
> 
> Signed-off-by: Kuniyuki Iwashima <kuniyu@...zon.com>
> ---
>  net/ipv6/seg6_local.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Patch [1] was originally intended to fix the creation of seg6local lwtunnels
within an RCU-protected block executed from inet6_rtm_newroute(), where recent
changes to locking mechanisms were introduced.

Patch [2], included in this patchset, aims to redesign and correct the RCU
usage in inet6_rtm_newroute().
>From the perspective of the SRv6 subsystem, the creation of a seg6local
lwtunnel is no longer performed within an RCU-protected section. This change
allows us to sleep again and enables memory allocations with GFP_KERNEL, which
is clearly preferable.

After applying this patch (along with the corresponding patchset), it appears
that creating a seg6local lwtunnel instance works fine.

Therefore, I believe it is ok to revert [1] in favor of the current approach.

Thanks,
Andrea

[1] ipv6: sr: switch to GFP_ATOMIC flag to allocate memory during seg6local LWT setup
    https://patch.msgid.link/20250429132453.31605-1-andrea.mayer@uniroma2.it

[2] ipv6: Narrow down RCU critical section in inet6_rtm_newroute()
    https://lore.kernel.org/all/20250516022759.44392-4-kuniyu@amazon.com/


Reviewed-by: Andrea Mayer <andrea.mayer@...roma2.it>


> 
> diff --git a/net/ipv6/seg6_local.c b/net/ipv6/seg6_local.c
> index ee5e448cc7a8..ac1dbd492c22 100644
> --- a/net/ipv6/seg6_local.c
> +++ b/net/ipv6/seg6_local.c
> @@ -1671,7 +1671,7 @@ static int parse_nla_srh(struct nlattr **attrs, struct seg6_local_lwt *slwt,
>  	if (!seg6_validate_srh(srh, len, false))
>  		return -EINVAL;
>  
> -	slwt->srh = kmemdup(srh, len, GFP_ATOMIC);
> +	slwt->srh = kmemdup(srh, len, GFP_KERNEL);
>  	if (!slwt->srh)
>  		return -ENOMEM;
>  
> @@ -1911,7 +1911,7 @@ static int parse_nla_bpf(struct nlattr **attrs, struct seg6_local_lwt *slwt,
>  	if (!tb[SEG6_LOCAL_BPF_PROG] || !tb[SEG6_LOCAL_BPF_PROG_NAME])
>  		return -EINVAL;
>  
> -	slwt->bpf.name = nla_memdup(tb[SEG6_LOCAL_BPF_PROG_NAME], GFP_ATOMIC);
> +	slwt->bpf.name = nla_memdup(tb[SEG6_LOCAL_BPF_PROG_NAME], GFP_KERNEL);
>  	if (!slwt->bpf.name)
>  		return -ENOMEM;
>  
> @@ -1994,7 +1994,7 @@ static int parse_nla_counters(struct nlattr **attrs,
>  		return -EINVAL;
>  
>  	/* counters are always zero initialized */
> -	pcounters = seg6_local_alloc_pcpu_counters(GFP_ATOMIC);
> +	pcounters = seg6_local_alloc_pcpu_counters(GFP_KERNEL);
>  	if (!pcounters)
>  		return -ENOMEM;
>  
> -- 
> 2.49.0