Netdev List
 help / color / mirror / Atom feed
From: Paolo Abeni <pabeni@redhat.com>
To: Eric Dumazet <edumazet@google.com>,
	"David S . Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>
Cc: Simon Horman <horms@kernel.org>,
	Kuniyuki Iwashima <kuniyu@google.com>,
	Ido Schimmel <idosch@nvidia.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	netdev@vger.kernel.org, eric.dumazet@gmail.com
Subject: Re: [PATCH net-next 0/3] vxlan: RCU protect vxlan_config and enable RTNL-less fill_info
Date: Fri, 10 Jul 2026 16:20:28 +0200	[thread overview]
Message-ID: <991ec032-c6fe-4236-be22-323a9e3cb07e@redhat.com> (raw)
In-Reply-To: <20260708160411.1355008-1-edumazet@google.com>

On 7/8/26 6:04 PM, Eric Dumazet wrote:
> This patch series converts VXLAN configuration (`struct vxlan_config`)
> to be RCU-protected, allowing lockless readers and enabling RTNL-less
> `vxlan_fill_info()` netlink link info dumping.
> 
> Work has been split into three distinct parts:
> 
> 1. Refactor helper functions in RX, TX, MDB, VNIFILTER, and OVS paths to
>    accept a `const struct vxlan_config *cfg` pointer (or pass specific
>    fields such as `flags`/`saddr_family`) rather than accessing
>    `vxlan->cfg` directly.
> 
> 2. Convert `vxlan->cfg` from an embedded struct into an RCU-protected
>    pointer (`struct vxlan_config __rcu *cfg`), dynamically allocated on
>    device creation or changelink, and freed via `kfree_rcu()`. Update
>    offload drivers (`mlxsw`) and OVS (`vport-vxlan.c`) accordingly.
> 
> 3. Update `vxlan_fill_info()` to run under `rcu_read_lock()` instead of
>    relying on RTNL lock, completing the transition to lockless link info
>    dumping for VXLAN devices.
I *suspect* this is triggering RCU splat in forwarding self-tests:

[ 1955.481960][T11074] =============================
[ 1955.482076][T11074] WARNING: suspicious RCU usage
[ 1955.482190][T11074] 7.2.0-rc2-virtme #1 Not tainted
[ 1955.482304][T11074] -----------------------------
[ 1955.482886][T11074] drivers/net/vxlan/vxlan_core.c:1872 suspicious rcu_dereference_check() usage!
[ 1955.483087][T11074] 
[ 1955.483087][T11074] other info that might help us debug this:
[ 1955.483087][T11074] 
[ 1955.483312][T11074] 
[ 1955.483312][T11074] rcu_scheduler_active = 2, debug_locks = 1
[ 1955.483489][T11074] 1 lock held by arping/11074:
[ 1955.483623][T11074]  #0: ffffffffbad91d60 (rcu_read_lock_bh){....}-{1:3}, at: __dev_queue_xmit+0x204/0x1b90
[ 1955.483836][T11074] 
[ 1955.483836][T11074] stack backtrace:
[ 1955.483977][T11074] CPU: 0 UID: 0 PID: 11074 Comm: arping Not tainted 7.2.0-rc2-virtme #1 PREEMPT(full) 
[ 1955.483980][T11074] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 1955.483982][T11074] Call Trace:
[ 1955.483983][T11074]  <TASK>
[ 1955.483984][T11074]  dump_stack_lvl+0x6f/0xa0
[ 1955.483990][T11074]  lockdep_rcu_suspicious.cold+0x37/0x89
[ 1955.483995][T11074]  arp_reduce.isra.0+0x9b9/0x1080 [vxlan]
[ 1955.484003][T11074]  ? mark_usage+0x61/0x170
[ 1955.484007][T11074]  ? __lock_acquire+0x518/0xc20
[ 1955.484010][T11074]  ? vxlan_nl2conf+0x5b30/0x5b30 [vxlan]
[ 1955.484015][T11074]  ? lock_acquire.part.0+0xbc/0x260
[ 1955.484017][T11074]  ? find_held_lock+0x2b/0x80
[ 1955.484020][T11074]  ? __lock_release.isra.0+0x6b/0x1a0
[ 1955.484025][T11074]  ? vxlan_xmit+0x128b/0x1660 [vxlan]
[ 1955.484029][T11074]  vxlan_xmit+0x128b/0x1660 [vxlan]
[ 1955.484034][T11074]  ? rcu_lockdep_current_cpu_online+0x39/0x1b0
[ 1955.484039][T11074]  dev_hard_start_xmit+0xf4/0x620
[ 1955.484042][T11074]  ? validate_xmit_skb+0x72/0x9a0
[ 1955.484045][T11074]  __dev_queue_xmit+0xc1a/0x1b90
[ 1955.484047][T11074]  ? _copy_from_iter+0x1bb/0x1810
[ 1955.484052][T11074]  ? __alloc_skb+0x342/0x5f0
[ 1955.484055][T11074]  ? _copy_from_iter_flushcache+0x1970/0x1970
[ 1955.484057][T11074]  ? ref_tracker_alloc+0x2e7/0x430
[ 1955.484060][T11074]  ? netdev_core_pick_tx+0x2c0/0x2c0
[ 1955.484064][T11074]  ? packet_parse_headers+0x325/0x830
[ 1955.484067][T11074]  ? __asan_memset+0x27/0x50
[ 1955.484070][T11074]  ? packet_parse_headers+0x325/0x830
[ 1955.484073][T11074]  ? skb_copy_datagram_from_iter+0xf3/0x6a0
[ 1955.484075][T11074]  ? packet_release+0xc70/0xc70
[ 1955.484079][T11074]  packet_snd+0xfad/0x1990
[ 1955.484085][T11074]  ? tpacket_snd+0x19e0/0x19e0
[ 1955.484087][T11074]  ? __might_fault+0x97/0x140
[ 1955.484093][T11074]  ? __might_fault+0x97/0x140
[ 1955.484095][T11074]  ? __might_fault+0x97/0x140
[ 1955.484098][T11074]  __sys_sendto+0x2aa/0x400
[ 1955.484101][T11074]  ? __ia32_sys_getpeername+0xd0/0xd0
[ 1955.484110][T11074]  ? do_user_addr_fault+0x325/0xe30
[ 1955.484116][T11074]  __x64_sys_sendto+0xe4/0x1f0
[ 1955.484117][T11074]  ? trace_irq_enable.constprop.0+0x9b/0x160
[ 1955.484121][T11074]  ? lockdep_hardirqs_on+0x8c/0x130
[ 1955.484123][T11074]  ? do_syscall_64+0x82/0x590
[ 1955.484126][T11074]  do_syscall_64+0x117/0x590
[ 1955.484127][T11074]  ? trace_hardirqs_off+0xd/0x30
[ 1955.484129][T11074]  ? exc_page_fault+0xee/0x100
[ 1955.484132][T11074]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
[ 1955.484134][T11074] RIP: 0033:0x7f138c3ec54e
[ 1955.484138][T11074] Code: 4d 89 d8 e8 b4 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 03 ff ff ff 0f 1f 00 f3 0f 1e fa
[ 1955.484139][T11074] RSP: 002b:00007ffc648f74e0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
[ 1955.484142][T11074] RAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007f138c3ec54e
[ 1955.484143][T11074] RDX: 000000000000001c RSI: 00007ffc648f7560 RDI: 0000000000000005
[ 1955.484144][T11074] RBP: 00007ffc648f74f0 R08: 00007ffc648f79e0 R09: 0000000000000014
[ 1955.484145][T11074] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
[ 1955.484146][T11074] R13: 00007ffc648f7910 R14: ffffffffffffffe8 R15: 0000000000000000

full log at:

https://netdev-ctrl.bots.linux.dev/logs/vmksft/net-dbg/results/728082/83-test-vxlan-nh-sh/stderr

Tentatively setting the series to 'changes requested'

/P


  parent reply	other threads:[~2026-07-10 14:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08 16:04 [PATCH net-next 0/3] vxlan: RCU protect vxlan_config and enable RTNL-less fill_info Eric Dumazet
2026-07-08 16:04 ` [PATCH net-next 1/3] vxlan: pass vxlan_config pointer to helper functions Eric Dumazet
2026-07-09  4:53   ` Pavan Chebbi
2026-07-08 16:04 ` [PATCH net-next 2/3] vxlan: convert configuration to RCU protection Eric Dumazet
2026-07-09  4:54   ` Pavan Chebbi
2026-07-08 16:04 ` [PATCH net-next 3/3] vxlan: no longer rely on RTNL in vxlan_fill_info() Eric Dumazet
2026-07-09  4:55   ` Pavan Chebbi
2026-07-10 14:20 ` Paolo Abeni [this message]
2026-07-10 14:22   ` [PATCH net-next 0/3] vxlan: RCU protect vxlan_config and enable RTNL-less fill_info Paolo Abeni
2026-07-10 15:03     ` Eric Dumazet

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=991ec032-c6fe-4236-be22-323a9e3cb07e@redhat.com \
    --to=pabeni@redhat.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=horms@kernel.org \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=netdev@vger.kernel.org \
    /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