Netdev List
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Steffen Klassert <steffen.klassert@secunet.com>, stable@vger.kernel.org
Cc: davem@davemloft.net, edumazet@google.com,
	Herbert Xu <herbert@gondor.apana.org.au>,
	horms@kernel.org, kuba@kernel.org, linux-kernel@vger.kernel.org,
	netdev@vger.kernel.org, pabeni@redhat.com, alexanderduyck@fb.com,
	enewton@meta.com, vlad.wing@gmail.com
Subject: Re: [PATCH] xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit
Date: Tue, 26 May 2026 12:51:09 +0100	[thread overview]
Message-ID: <6c51fabe-5524-4857-8f23-b351f5e63e10@linux.dev> (raw)
In-Reply-To: <ahV1BxasOuDHX7Zy@secunet.com>



On 26/05/2026 11:25, Steffen Klassert wrote:
> On Thu, May 21, 2026 at 03:29:26AM -0700, Usama Arif wrote:
>> The struct pernet_operations docstring in include/net/net_namespace.h
>> explicitly warns against blocking RCU primitives in .exit handlers:
>>
>>     Exit methods using blocking RCU primitives, such as
>>     synchronize_rcu(), should be implemented via exit_batch.
>>     [...]
>>     Please, avoid synchronize_rcu() at all, where it's possible.
>>
>>     Note that a combination of pre_exit() and exit() can
>>     be used, since a synchronize_rcu() is guaranteed between
>>     the calls.
>>
>> xfrm_policy_fini() violates this: it calls synchronize_rcu() before
>> freeing the policy_bydst hash tables (so no RCU reader is mid-
>> traversal at free time), but runs from xfrm_net_ops.exit -- once per
>> namespace -- so a cleanup_net() of N namespaces pays N full RCU
>> grace periods serially.
>>
>> Use the documented pre_exit/exit split. Move the policy flush (and
>> the workqueue drains it depends on) into a new .pre_exit handler;
>> xfrm_policy_fini() then runs in .exit and frees the hash tables
>> after the synchronize_rcu_expedited() that cleanup_net() guarantees
>> between the two phases. Providing O(1) RCU grace periods per batch
>> instead of O(N).
>>
>> Observed on Linux 6.18 with a workload doing unshare(CLONE_NEWNET)
>> at ~13/sec sustained: cleanup_net() and the netns_wq rescuer kthread
>> both stuck in xfrm_policy_fini()'s synchronize_rcu(), >300k struct
>> net accumulated in the cleanup queue, Percpu in /proc/meminfo climbed
>> to 130+ GB on 256-CPU hosts, and memcg OOMs followed. setup_net and
>> __put_net counts were balanced, ruling out a refcount leak.
>>
>> Fixes: 069daad4f2ae ("xfrm: Wait for RCU readers during policy netns exit")
>> Signed-off-by: Usama Arif <usama.arif@linux.dev>
> 
> Applied, thanks Usama!


Thanks! Forgot to cc stable@vger.kernel.org

Adding it here 

      reply	other threads:[~2026-05-26 11:51 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-21 10:29 [PATCH] xfrm: move policy_bydst RCU sync from per-netns .exit to .pre_exit Usama Arif
2026-05-26 10:25 ` Steffen Klassert
2026-05-26 11:51   ` Usama Arif [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6c51fabe-5524-4857-8f23-b351f5e63e10@linux.dev \
    --to=usama.arif@linux.dev \
    --cc=alexanderduyck@fb.com \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=enewton@meta.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=steffen.klassert@secunet.com \
    --cc=vlad.wing@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox