diff mbox series

[v2,net,09/16] ipv4: icmp: convert to dev_net_rcu()

Message ID 20250203143046.3029343-10-edumazet@google.com (mailing list archive)
State Superseded
Delegated to: Netdev Maintainers
Headers show
Series net: first round to use dev_net_rcu() | expand

Checks

Context Check Description
netdev/series_format fail Series longer than 15 patches
netdev/tree_selection success Clearly marked for net, async
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag present in non-next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 0 this patch: 0
netdev/build_tools success No tools touched, skip
netdev/cc_maintainers warning 1 maintainers not CCed: dsahern@kernel.org
netdev/build_clang success Errors and warnings before: 2 this patch: 2
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 2 this patch: 2
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 87 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 1 this patch: 1
netdev/source_inline success Was 0 now: 0
netdev/contest warning net-next-2025-02-03--21-00 (tests: 81)

Commit Message

Eric Dumazet Feb. 3, 2025, 2:30 p.m. UTC 
ICMP uses of dev_net() are safe, change them to dev_net_rcu()
to get LOCKDEP support.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
---
 net/ipv4/icmp.c | 22 +++++++++++-----------
 1 file changed, 11 insertions(+), 11 deletions(-)

Comments

Jakub Kicinski Feb. 3, 2025, 11:36 p.m. UTC | #1 
On Mon,  3 Feb 2025 14:30:39 +0000 Eric Dumazet wrote:
> @@ -611,9 +611,9 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info,
>  		goto out;
>  
>  	if (rt->dst.dev)
> -		net = dev_net(rt->dst.dev);
> +		net = dev_net_rcu(rt->dst.dev);
>  	else if (skb_in->dev)
> -		net = dev_net(skb_in->dev);
> +		net = dev_net_rcu(skb_in->dev);
>  	else
>  		goto out;

Hm. Weird. NIPA says this one is not under RCU.

[  275.730657][    C1] ./include/net/net_namespace.h:404 suspicious rcu_dereference_check() usage!
[  275.731033][    C1] 
[  275.731033][    C1] other info that might help us debug this:
[  275.731033][    C1] 
[  275.731471][    C1] 
[  275.731471][    C1] rcu_scheduler_active = 2, debug_locks = 1
[  275.731799][    C1] 1 lock held by swapper/1/0:
[  275.732000][    C1]  #0: ffffc900001e0ae8 ((&n->timer)){+.-.}-{0:0}, at: call_timer_fn+0xe8/0x230
[  275.732354][    C1] 
[  275.732354][    C1] stack backtrace:
[  275.732638][    C1] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.13.0-virtme #1
[  275.732643][    C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[  275.732646][    C1] Call Trace:
[  275.732647][    C1]  <IRQ>
[  275.732651][    C1]  dump_stack_lvl+0xb0/0xd0
[  275.732663][    C1]  lockdep_rcu_suspicious+0x1ea/0x280
[  275.732678][    C1]  __icmp_send+0xb0d/0x1580
[  275.732695][    C1]  ? tcp_data_queue+0x8/0x22d0
[  275.732701][    C1]  ? lockdep_hardirqs_on_prepare+0x12b/0x410
[  275.732712][    C1]  ? __pfx___icmp_send+0x10/0x10
[  275.732719][    C1]  ? tcp_check_space+0x3ce/0x5f0
[  275.732742][    C1]  ? rcu_read_lock_any_held+0x43/0xb0
[  275.732750][    C1]  ? validate_chain+0x1fe/0xae0
[  275.732771][    C1]  ? __pfx_validate_chain+0x10/0x10
[  275.732778][    C1]  ? hlock_class+0x4e/0x130
[  275.732784][    C1]  ? mark_lock+0x38/0x3e0
[  275.732788][    C1]  ? sock_put+0x1a/0x60
[  275.732806][    C1]  ? __lock_acquire+0xb9a/0x1680
[  275.732822][    C1]  ipv4_send_dest_unreach+0x3b4/0x800
[  275.732829][    C1]  ? neigh_invalidate+0x1c7/0x540
[  275.732837][    C1]  ? __pfx_ipv4_send_dest_unreach+0x10/0x10
[  275.732850][    C1]  ipv4_link_failure+0x1b/0x190
[  275.732856][    C1]  arp_error_report+0x96/0x170
[  275.732862][    C1]  neigh_invalidate+0x209/0x540
[  275.732873][    C1]  neigh_timer_handler+0x87a/0xdf0
[  275.732883][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
[  275.732886][    C1]  call_timer_fn+0x13b/0x230
[  275.732891][    C1]  ? call_timer_fn+0xe8/0x230
[  275.732894][    C1]  ? call_timer_fn+0xe8/0x230
[  275.732899][    C1]  ? __pfx_call_timer_fn+0x10/0x10
[  275.732902][    C1]  ? mark_lock+0x38/0x3e0
[  275.732920][    C1]  __run_timers+0x545/0x810
[  275.732925][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
[  275.732936][    C1]  ? __pfx___run_timers+0x10/0x10
[  275.732939][    C1]  ? __lock_release+0x103/0x460
[  275.732947][    C1]  ? do_raw_spin_lock+0x131/0x270
[  275.732952][    C1]  ? __pfx_do_raw_spin_lock+0x10/0x10
[  275.732956][    C1]  ? lock_acquire+0x32/0xc0
[  275.732958][    C1]  ? timer_expire_remote+0x96/0xf0
[  275.732967][    C1]  timer_expire_remote+0x9e/0xf0
[  275.732970][    C1]  tmigr_handle_remote_cpu+0x278/0x440
[  275.732977][    C1]  ? __pfx_tmigr_handle_remote_cpu+0x10/0x10
[  275.732981][    C1]  ? __pfx___lock_release+0x10/0x10
[  275.732985][    C1]  ? __pfx_lock_acquire.part.0+0x10/0x10
[  275.733015][    C1]  tmigr_handle_remote_up+0x1a6/0x270
[  275.733027][    C1]  ? __pfx_tmigr_handle_remote_up+0x10/0x10
[  275.733036][    C1]  __walk_groups.isra.0+0x44/0x160
[  275.733051][    C1]  tmigr_handle_remote+0x20b/0x300

Decoded:
https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/976941/vm-crash-thr0-1
Eric Dumazet Feb. 4, 2025, 4:14 a.m. UTC | #2 
On Tue, Feb 4, 2025 at 12:36 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon,  3 Feb 2025 14:30:39 +0000 Eric Dumazet wrote:
> > @@ -611,9 +611,9 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info,
> >               goto out;
> >
> >       if (rt->dst.dev)
> > -             net = dev_net(rt->dst.dev);
> > +             net = dev_net_rcu(rt->dst.dev);
> >       else if (skb_in->dev)
> > -             net = dev_net(skb_in->dev);
> > +             net = dev_net_rcu(skb_in->dev);
> >       else
> >               goto out;
>
> Hm. Weird. NIPA says this one is not under RCU.
>
> [  275.730657][    C1] ./include/net/net_namespace.h:404 suspicious rcu_dereference_check() usage!
> [  275.731033][    C1]
> [  275.731033][    C1] other info that might help us debug this:
> [  275.731033][    C1]
> [  275.731471][    C1]
> [  275.731471][    C1] rcu_scheduler_active = 2, debug_locks = 1
> [  275.731799][    C1] 1 lock held by swapper/1/0:
> [  275.732000][    C1]  #0: ffffc900001e0ae8 ((&n->timer)){+.-.}-{0:0}, at: call_timer_fn+0xe8/0x230
> [  275.732354][    C1]
> [  275.732354][    C1] stack backtrace:
> [  275.732638][    C1] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.13.0-virtme #1
> [  275.732643][    C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [  275.732646][    C1] Call Trace:
> [  275.732647][    C1]  <IRQ>
> [  275.732651][    C1]  dump_stack_lvl+0xb0/0xd0
> [  275.732663][    C1]  lockdep_rcu_suspicious+0x1ea/0x280
> [  275.732678][    C1]  __icmp_send+0xb0d/0x1580
> [  275.732695][    C1]  ? tcp_data_queue+0x8/0x22d0
> [  275.732701][    C1]  ? lockdep_hardirqs_on_prepare+0x12b/0x410
> [  275.732712][    C1]  ? __pfx___icmp_send+0x10/0x10
> [  275.732719][    C1]  ? tcp_check_space+0x3ce/0x5f0
> [  275.732742][    C1]  ? rcu_read_lock_any_held+0x43/0xb0
> [  275.732750][    C1]  ? validate_chain+0x1fe/0xae0
> [  275.732771][    C1]  ? __pfx_validate_chain+0x10/0x10
> [  275.732778][    C1]  ? hlock_class+0x4e/0x130
> [  275.732784][    C1]  ? mark_lock+0x38/0x3e0
> [  275.732788][    C1]  ? sock_put+0x1a/0x60
> [  275.732806][    C1]  ? __lock_acquire+0xb9a/0x1680
> [  275.732822][    C1]  ipv4_send_dest_unreach+0x3b4/0x800
> [  275.732829][    C1]  ? neigh_invalidate+0x1c7/0x540
> [  275.732837][    C1]  ? __pfx_ipv4_send_dest_unreach+0x10/0x10
> [  275.732850][    C1]  ipv4_link_failure+0x1b/0x190
> [  275.732856][    C1]  arp_error_report+0x96/0x170
> [  275.732862][    C1]  neigh_invalidate+0x209/0x540
> [  275.732873][    C1]  neigh_timer_handler+0x87a/0xdf0
> [  275.732883][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
> [  275.732886][    C1]  call_timer_fn+0x13b/0x230
> [  275.732891][    C1]  ? call_timer_fn+0xe8/0x230
> [  275.732894][    C1]  ? call_timer_fn+0xe8/0x230
> [  275.732899][    C1]  ? __pfx_call_timer_fn+0x10/0x10
> [  275.732902][    C1]  ? mark_lock+0x38/0x3e0
> [  275.732920][    C1]  __run_timers+0x545/0x810
> [  275.732925][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
> [  275.732936][    C1]  ? __pfx___run_timers+0x10/0x10
> [  275.732939][    C1]  ? __lock_release+0x103/0x460
> [  275.732947][    C1]  ? do_raw_spin_lock+0x131/0x270
> [  275.732952][    C1]  ? __pfx_do_raw_spin_lock+0x10/0x10
> [  275.732956][    C1]  ? lock_acquire+0x32/0xc0
> [  275.732958][    C1]  ? timer_expire_remote+0x96/0xf0
> [  275.732967][    C1]  timer_expire_remote+0x9e/0xf0
> [  275.732970][    C1]  tmigr_handle_remote_cpu+0x278/0x440
> [  275.732977][    C1]  ? __pfx_tmigr_handle_remote_cpu+0x10/0x10
> [  275.732981][    C1]  ? __pfx___lock_release+0x10/0x10
> [  275.732985][    C1]  ? __pfx_lock_acquire.part.0+0x10/0x10
> [  275.733015][    C1]  tmigr_handle_remote_up+0x1a6/0x270
> [  275.733027][    C1]  ? __pfx_tmigr_handle_remote_up+0x10/0x10
> [  275.733036][    C1]  __walk_groups.isra.0+0x44/0x160
> [  275.733051][    C1]  tmigr_handle_remote+0x20b/0x300
>
> Decoded:
> https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/976941/vm-crash-thr0-1

Oops, I thought I ran the tests on the whole series. I missed this one.
Eric Dumazet Feb. 4, 2025, 4:57 a.m. UTC | #3 
On Tue, Feb 4, 2025 at 5:14 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Feb 4, 2025 at 12:36 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Mon,  3 Feb 2025 14:30:39 +0000 Eric Dumazet wrote:
> > > @@ -611,9 +611,9 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info,
> > >               goto out;
> > >
> > >       if (rt->dst.dev)
> > > -             net = dev_net(rt->dst.dev);
> > > +             net = dev_net_rcu(rt->dst.dev);
> > >       else if (skb_in->dev)
> > > -             net = dev_net(skb_in->dev);
> > > +             net = dev_net_rcu(skb_in->dev);
> > >       else
> > >               goto out;
> >
> > Hm. Weird. NIPA says this one is not under RCU.
> >
> > [  275.730657][    C1] ./include/net/net_namespace.h:404 suspicious rcu_dereference_check() usage!
> > [  275.731033][    C1]
> > [  275.731033][    C1] other info that might help us debug this:
> > [  275.731033][    C1]
> > [  275.731471][    C1]
> > [  275.731471][    C1] rcu_scheduler_active = 2, debug_locks = 1
> > [  275.731799][    C1] 1 lock held by swapper/1/0:
> > [  275.732000][    C1]  #0: ffffc900001e0ae8 ((&n->timer)){+.-.}-{0:0}, at: call_timer_fn+0xe8/0x230
> > [  275.732354][    C1]
> > [  275.732354][    C1] stack backtrace:
> > [  275.732638][    C1] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.13.0-virtme #1
> > [  275.732643][    C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > [  275.732646][    C1] Call Trace:
> > [  275.732647][    C1]  <IRQ>
> > [  275.732651][    C1]  dump_stack_lvl+0xb0/0xd0
> > [  275.732663][    C1]  lockdep_rcu_suspicious+0x1ea/0x280
> > [  275.732678][    C1]  __icmp_send+0xb0d/0x1580
> > [  275.732695][    C1]  ? tcp_data_queue+0x8/0x22d0
> > [  275.732701][    C1]  ? lockdep_hardirqs_on_prepare+0x12b/0x410
> > [  275.732712][    C1]  ? __pfx___icmp_send+0x10/0x10
> > [  275.732719][    C1]  ? tcp_check_space+0x3ce/0x5f0
> > [  275.732742][    C1]  ? rcu_read_lock_any_held+0x43/0xb0
> > [  275.732750][    C1]  ? validate_chain+0x1fe/0xae0
> > [  275.732771][    C1]  ? __pfx_validate_chain+0x10/0x10
> > [  275.732778][    C1]  ? hlock_class+0x4e/0x130
> > [  275.732784][    C1]  ? mark_lock+0x38/0x3e0
> > [  275.732788][    C1]  ? sock_put+0x1a/0x60
> > [  275.732806][    C1]  ? __lock_acquire+0xb9a/0x1680
> > [  275.732822][    C1]  ipv4_send_dest_unreach+0x3b4/0x800
> > [  275.732829][    C1]  ? neigh_invalidate+0x1c7/0x540
> > [  275.732837][    C1]  ? __pfx_ipv4_send_dest_unreach+0x10/0x10
> > [  275.732850][    C1]  ipv4_link_failure+0x1b/0x190
> > [  275.732856][    C1]  arp_error_report+0x96/0x170
> > [  275.732862][    C1]  neigh_invalidate+0x209/0x540
> > [  275.732873][    C1]  neigh_timer_handler+0x87a/0xdf0
> > [  275.732883][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
> > [  275.732886][    C1]  call_timer_fn+0x13b/0x230
> > [  275.732891][    C1]  ? call_timer_fn+0xe8/0x230
> > [  275.732894][    C1]  ? call_timer_fn+0xe8/0x230
> > [  275.732899][    C1]  ? __pfx_call_timer_fn+0x10/0x10
> > [  275.732902][    C1]  ? mark_lock+0x38/0x3e0
> > [  275.732920][    C1]  __run_timers+0x545/0x810
> > [  275.732925][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
> > [  275.732936][    C1]  ? __pfx___run_timers+0x10/0x10
> > [  275.732939][    C1]  ? __lock_release+0x103/0x460
> > [  275.732947][    C1]  ? do_raw_spin_lock+0x131/0x270
> > [  275.732952][    C1]  ? __pfx_do_raw_spin_lock+0x10/0x10
> > [  275.732956][    C1]  ? lock_acquire+0x32/0xc0
> > [  275.732958][    C1]  ? timer_expire_remote+0x96/0xf0
> > [  275.732967][    C1]  timer_expire_remote+0x9e/0xf0
> > [  275.732970][    C1]  tmigr_handle_remote_cpu+0x278/0x440
> > [  275.732977][    C1]  ? __pfx_tmigr_handle_remote_cpu+0x10/0x10
> > [  275.732981][    C1]  ? __pfx___lock_release+0x10/0x10
> > [  275.732985][    C1]  ? __pfx_lock_acquire.part.0+0x10/0x10
> > [  275.733015][    C1]  tmigr_handle_remote_up+0x1a6/0x270
> > [  275.733027][    C1]  ? __pfx_tmigr_handle_remote_up+0x10/0x10
> > [  275.733036][    C1]  __walk_groups.isra.0+0x44/0x160
> > [  275.733051][    C1]  tmigr_handle_remote+0x20b/0x300
> >
> > Decoded:
> > https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/976941/vm-crash-thr0-1
>
> Oops, I thought I ran the tests on the whole series. I missed this one.

BTW, ICMPv6 has the same potential problem, I will amend both cases.
Eric Dumazet Feb. 4, 2025, 10:35 a.m. UTC | #4 
On Tue, Feb 4, 2025 at 5:57 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Feb 4, 2025 at 5:14 AM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Tue, Feb 4, 2025 at 12:36 AM Jakub Kicinski <kuba@kernel.org> wrote:
> > >
> > > On Mon,  3 Feb 2025 14:30:39 +0000 Eric Dumazet wrote:
> > > > @@ -611,9 +611,9 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info,
> > > >               goto out;
> > > >
> > > >       if (rt->dst.dev)
> > > > -             net = dev_net(rt->dst.dev);
> > > > +             net = dev_net_rcu(rt->dst.dev);
> > > >       else if (skb_in->dev)
> > > > -             net = dev_net(skb_in->dev);
> > > > +             net = dev_net_rcu(skb_in->dev);
> > > >       else
> > > >               goto out;
> > >
> > > Hm. Weird. NIPA says this one is not under RCU.
> > >
> > > [  275.730657][    C1] ./include/net/net_namespace.h:404 suspicious rcu_dereference_check() usage!
> > > [  275.731033][    C1]
> > > [  275.731033][    C1] other info that might help us debug this:
> > > [  275.731033][    C1]
> > > [  275.731471][    C1]
> > > [  275.731471][    C1] rcu_scheduler_active = 2, debug_locks = 1
> > > [  275.731799][    C1] 1 lock held by swapper/1/0:
> > > [  275.732000][    C1]  #0: ffffc900001e0ae8 ((&n->timer)){+.-.}-{0:0}, at: call_timer_fn+0xe8/0x230
> > > [  275.732354][    C1]
> > > [  275.732354][    C1] stack backtrace:
> > > [  275.732638][    C1] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.13.0-virtme #1
> > > [  275.732643][    C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > > [  275.732646][    C1] Call Trace:
> > > [  275.732647][    C1]  <IRQ>
> > > [  275.732651][    C1]  dump_stack_lvl+0xb0/0xd0
> > > [  275.732663][    C1]  lockdep_rcu_suspicious+0x1ea/0x280
> > > [  275.732678][    C1]  __icmp_send+0xb0d/0x1580
> > > [  275.732695][    C1]  ? tcp_data_queue+0x8/0x22d0
> > > [  275.732701][    C1]  ? lockdep_hardirqs_on_prepare+0x12b/0x410
> > > [  275.732712][    C1]  ? __pfx___icmp_send+0x10/0x10
> > > [  275.732719][    C1]  ? tcp_check_space+0x3ce/0x5f0
> > > [  275.732742][    C1]  ? rcu_read_lock_any_held+0x43/0xb0
> > > [  275.732750][    C1]  ? validate_chain+0x1fe/0xae0
> > > [  275.732771][    C1]  ? __pfx_validate_chain+0x10/0x10
> > > [  275.732778][    C1]  ? hlock_class+0x4e/0x130
> > > [  275.732784][    C1]  ? mark_lock+0x38/0x3e0
> > > [  275.732788][    C1]  ? sock_put+0x1a/0x60
> > > [  275.732806][    C1]  ? __lock_acquire+0xb9a/0x1680
> > > [  275.732822][    C1]  ipv4_send_dest_unreach+0x3b4/0x800
> > > [  275.732829][    C1]  ? neigh_invalidate+0x1c7/0x540
> > > [  275.732837][    C1]  ? __pfx_ipv4_send_dest_unreach+0x10/0x10
> > > [  275.732850][    C1]  ipv4_link_failure+0x1b/0x190
> > > [  275.732856][    C1]  arp_error_report+0x96/0x170
> > > [  275.732862][    C1]  neigh_invalidate+0x209/0x540
> > > [  275.732873][    C1]  neigh_timer_handler+0x87a/0xdf0
> > > [  275.732883][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
> > > [  275.732886][    C1]  call_timer_fn+0x13b/0x230
> > > [  275.732891][    C1]  ? call_timer_fn+0xe8/0x230
> > > [  275.732894][    C1]  ? call_timer_fn+0xe8/0x230
> > > [  275.732899][    C1]  ? __pfx_call_timer_fn+0x10/0x10
> > > [  275.732902][    C1]  ? mark_lock+0x38/0x3e0
> > > [  275.732920][    C1]  __run_timers+0x545/0x810
> > > [  275.732925][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
> > > [  275.732936][    C1]  ? __pfx___run_timers+0x10/0x10
> > > [  275.732939][    C1]  ? __lock_release+0x103/0x460
> > > [  275.732947][    C1]  ? do_raw_spin_lock+0x131/0x270
> > > [  275.732952][    C1]  ? __pfx_do_raw_spin_lock+0x10/0x10
> > > [  275.732956][    C1]  ? lock_acquire+0x32/0xc0
> > > [  275.732958][    C1]  ? timer_expire_remote+0x96/0xf0
> > > [  275.732967][    C1]  timer_expire_remote+0x9e/0xf0
> > > [  275.732970][    C1]  tmigr_handle_remote_cpu+0x278/0x440
> > > [  275.732977][    C1]  ? __pfx_tmigr_handle_remote_cpu+0x10/0x10
> > > [  275.732981][    C1]  ? __pfx___lock_release+0x10/0x10
> > > [  275.732985][    C1]  ? __pfx_lock_acquire.part.0+0x10/0x10
> > > [  275.733015][    C1]  tmigr_handle_remote_up+0x1a6/0x270
> > > [  275.733027][    C1]  ? __pfx_tmigr_handle_remote_up+0x10/0x10
> > > [  275.733036][    C1]  __walk_groups.isra.0+0x44/0x160
> > > [  275.733051][    C1]  tmigr_handle_remote+0x20b/0x300
> > >
> > > Decoded:
> > > https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/976941/vm-crash-thr0-1
> >
> > Oops, I thought I ran the tests on the whole series. I missed this one.
>
> BTW, ICMPv6 has the same potential problem, I will amend both cases.

I ran again the tests for v3, got an unrelated crash, FYI.

14237.095216] #PF: supervisor instruction fetch in kernel mode
[14237.095570] #PF: error_code(0x0010) - not-present page
[14237.095915] PGD 1e58067 P4D 1e58067 PUD ce1c067 PMD 0
[14237.096991] Oops: Oops: 0010 [#1] SMP DEBUG_PAGEALLOC NOPTI
[14237.097507] CPU: 0 UID: 0 PID: 6371 Comm: python3 Not tainted
6.13.0-virtme #1559
[14237.098045] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
BIOS 1.16.3-debian-1.16.3-2 04/01/2014
[14237.098578] RIP: 0010:0x0
[14237.099324] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[14237.099752] RSP: 0018:ffffacfd4486bed0 EFLAGS: 00000286
[14237.100079] RAX: 0000000000000000 RBX: ffff9af502607200 RCX: 0000000000000002
[14237.100452] RDX: 00007fffc684a690 RSI: 0000000000005401 RDI: ffff9af502607200
[14237.100821] RBP: 0000000000005401 R08: 0000000000000001 R09: 0000000000000000
[14237.101182] R10: 0000000000000001 R11: 0000000000000000 R12: 00007fffc684a690
[14237.101542] R13: ffff9af50888ed68 R14: ffff9af502607200 R15: 0000000000000000
[14237.101956] FS:  00007f76b73f95c0(0000) GS:ffff9af57cc00000(0000)
knlGS:0000000000000000
[14237.102372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[14237.102679] CR2: ffffffffffffffd6 CR3: 00000000039ca000 CR4: 00000000000006f0
[14237.103160] Call Trace:
[14237.103435]  <TASK>
[14237.103720]  ? __die_body.cold+0x19/0x26
[14237.104340]  ? page_fault_oops+0x134/0x2a0
[14237.104553]  ? cp_new_stat+0x157/0x190
[14237.104799]  ? exc_page_fault+0x68/0x230
[14237.105013]  ? asm_exc_page_fault+0x26/0x30
[14237.105259]  full_proxy_unlocked_ioctl+0x63/0x90
[14237.105546]  __x64_sys_ioctl+0x97/0xc0
[14237.105754]  do_syscall_64+0x72/0x180
[14237.105949]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
Matthieu Baerts (NGI0) Feb. 4, 2025, 4:21 p.m. UTC | #5 
Hi Eric,

On 04/02/2025 11:35, Eric Dumazet wrote:
> On Tue, Feb 4, 2025 at 5:57 AM Eric Dumazet <edumazet@google.com> wrote:
>>
>> On Tue, Feb 4, 2025 at 5:14 AM Eric Dumazet <edumazet@google.com> wrote:
>>>
>>> On Tue, Feb 4, 2025 at 12:36 AM Jakub Kicinski <kuba@kernel.org> wrote:
>>>>
>>>> On Mon,  3 Feb 2025 14:30:39 +0000 Eric Dumazet wrote:
>>>>> @@ -611,9 +611,9 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info,
>>>>>               goto out;
>>>>>
>>>>>       if (rt->dst.dev)
>>>>> -             net = dev_net(rt->dst.dev);
>>>>> +             net = dev_net_rcu(rt->dst.dev);
>>>>>       else if (skb_in->dev)
>>>>> -             net = dev_net(skb_in->dev);
>>>>> +             net = dev_net_rcu(skb_in->dev);
>>>>>       else
>>>>>               goto out;
>>>>
>>>> Hm. Weird. NIPA says this one is not under RCU.
>>>>
>>>> [  275.730657][    C1] ./include/net/net_namespace.h:404 suspicious rcu_dereference_check() usage!
>>>> [  275.731033][    C1]
>>>> [  275.731033][    C1] other info that might help us debug this:
>>>> [  275.731033][    C1]
>>>> [  275.731471][    C1]
>>>> [  275.731471][    C1] rcu_scheduler_active = 2, debug_locks = 1
>>>> [  275.731799][    C1] 1 lock held by swapper/1/0:
>>>> [  275.732000][    C1]  #0: ffffc900001e0ae8 ((&n->timer)){+.-.}-{0:0}, at: call_timer_fn+0xe8/0x230
>>>> [  275.732354][    C1]
>>>> [  275.732354][    C1] stack backtrace:
>>>> [  275.732638][    C1] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.13.0-virtme #1
>>>> [  275.732643][    C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
>>>> [  275.732646][    C1] Call Trace:
>>>> [  275.732647][    C1]  <IRQ>
>>>> [  275.732651][    C1]  dump_stack_lvl+0xb0/0xd0
>>>> [  275.732663][    C1]  lockdep_rcu_suspicious+0x1ea/0x280
>>>> [  275.732678][    C1]  __icmp_send+0xb0d/0x1580
>>>> [  275.732695][    C1]  ? tcp_data_queue+0x8/0x22d0
>>>> [  275.732701][    C1]  ? lockdep_hardirqs_on_prepare+0x12b/0x410
>>>> [  275.732712][    C1]  ? __pfx___icmp_send+0x10/0x10
>>>> [  275.732719][    C1]  ? tcp_check_space+0x3ce/0x5f0
>>>> [  275.732742][    C1]  ? rcu_read_lock_any_held+0x43/0xb0
>>>> [  275.732750][    C1]  ? validate_chain+0x1fe/0xae0
>>>> [  275.732771][    C1]  ? __pfx_validate_chain+0x10/0x10
>>>> [  275.732778][    C1]  ? hlock_class+0x4e/0x130
>>>> [  275.732784][    C1]  ? mark_lock+0x38/0x3e0
>>>> [  275.732788][    C1]  ? sock_put+0x1a/0x60
>>>> [  275.732806][    C1]  ? __lock_acquire+0xb9a/0x1680
>>>> [  275.732822][    C1]  ipv4_send_dest_unreach+0x3b4/0x800
>>>> [  275.732829][    C1]  ? neigh_invalidate+0x1c7/0x540
>>>> [  275.732837][    C1]  ? __pfx_ipv4_send_dest_unreach+0x10/0x10
>>>> [  275.732850][    C1]  ipv4_link_failure+0x1b/0x190
>>>> [  275.732856][    C1]  arp_error_report+0x96/0x170
>>>> [  275.732862][    C1]  neigh_invalidate+0x209/0x540
>>>> [  275.732873][    C1]  neigh_timer_handler+0x87a/0xdf0
>>>> [  275.732883][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
>>>> [  275.732886][    C1]  call_timer_fn+0x13b/0x230
>>>> [  275.732891][    C1]  ? call_timer_fn+0xe8/0x230
>>>> [  275.732894][    C1]  ? call_timer_fn+0xe8/0x230
>>>> [  275.732899][    C1]  ? __pfx_call_timer_fn+0x10/0x10
>>>> [  275.732902][    C1]  ? mark_lock+0x38/0x3e0
>>>> [  275.732920][    C1]  __run_timers+0x545/0x810
>>>> [  275.732925][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
>>>> [  275.732936][    C1]  ? __pfx___run_timers+0x10/0x10
>>>> [  275.732939][    C1]  ? __lock_release+0x103/0x460
>>>> [  275.732947][    C1]  ? do_raw_spin_lock+0x131/0x270
>>>> [  275.732952][    C1]  ? __pfx_do_raw_spin_lock+0x10/0x10
>>>> [  275.732956][    C1]  ? lock_acquire+0x32/0xc0
>>>> [  275.732958][    C1]  ? timer_expire_remote+0x96/0xf0
>>>> [  275.732967][    C1]  timer_expire_remote+0x9e/0xf0
>>>> [  275.732970][    C1]  tmigr_handle_remote_cpu+0x278/0x440
>>>> [  275.732977][    C1]  ? __pfx_tmigr_handle_remote_cpu+0x10/0x10
>>>> [  275.732981][    C1]  ? __pfx___lock_release+0x10/0x10
>>>> [  275.732985][    C1]  ? __pfx_lock_acquire.part.0+0x10/0x10
>>>> [  275.733015][    C1]  tmigr_handle_remote_up+0x1a6/0x270
>>>> [  275.733027][    C1]  ? __pfx_tmigr_handle_remote_up+0x10/0x10
>>>> [  275.733036][    C1]  __walk_groups.isra.0+0x44/0x160
>>>> [  275.733051][    C1]  tmigr_handle_remote+0x20b/0x300
>>>>
>>>> Decoded:
>>>> https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/976941/vm-crash-thr0-1
>>>
>>> Oops, I thought I ran the tests on the whole series. I missed this one.
>>
>> BTW, ICMPv6 has the same potential problem, I will amend both cases.
> 
> I ran again the tests for v3, got an unrelated crash, FYI.
> 
> 14237.095216] #PF: supervisor instruction fetch in kernel mode
> [14237.095570] #PF: error_code(0x0010) - not-present page
> [14237.095915] PGD 1e58067 P4D 1e58067 PUD ce1c067 PMD 0
> [14237.096991] Oops: Oops: 0010 [#1] SMP DEBUG_PAGEALLOC NOPTI
> [14237.097507] CPU: 0 UID: 0 PID: 6371 Comm: python3 Not tainted
> 6.13.0-virtme #1559
> [14237.098045] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
> BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> [14237.098578] RIP: 0010:0x0
> [14237.099324] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
> [14237.099752] RSP: 0018:ffffacfd4486bed0 EFLAGS: 00000286
> [14237.100079] RAX: 0000000000000000 RBX: ffff9af502607200 RCX: 0000000000000002
> [14237.100452] RDX: 00007fffc684a690 RSI: 0000000000005401 RDI: ffff9af502607200
> [14237.100821] RBP: 0000000000005401 R08: 0000000000000001 R09: 0000000000000000
> [14237.101182] R10: 0000000000000001 R11: 0000000000000000 R12: 00007fffc684a690
> [14237.101542] R13: ffff9af50888ed68 R14: ffff9af502607200 R15: 0000000000000000
> [14237.101956] FS:  00007f76b73f95c0(0000) GS:ffff9af57cc00000(0000)
> knlGS:0000000000000000
> [14237.102372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [14237.102679] CR2: ffffffffffffffd6 CR3: 00000000039ca000 CR4: 00000000000006f0
> [14237.103160] Call Trace:
> [14237.103435]  <TASK>
> [14237.103720]  ? __die_body.cold+0x19/0x26
> [14237.104340]  ? page_fault_oops+0x134/0x2a0
> [14237.104553]  ? cp_new_stat+0x157/0x190
> [14237.104799]  ? exc_page_fault+0x68/0x230
> [14237.105013]  ? asm_exc_page_fault+0x26/0x30
> [14237.105259]  full_proxy_unlocked_ioctl+0x63/0x90
> [14237.105546]  __x64_sys_ioctl+0x97/0xc0
> [14237.105754]  do_syscall_64+0x72/0x180
> [14237.105949]  entry_SYSCALL_64_after_hwframe+0x76/0x7e

I think I got this issue as well on MPTCP side, when using GCOV, but
something else using the debugfs could trigger that as well I guess. It
is apparently fixed in the Linus tree, see 57b314752ec0 ("debugfs: Fix
the missing initializations in __debugfs_file_get()")

https://lore.kernel.org/all/20250129191937.GR1977892@ZenIV/

Cheers,
Matt
Jakub Kicinski Feb. 4, 2025, 4:21 p.m. UTC | #6 
On Tue, 4 Feb 2025 11:35:46 +0100 Eric Dumazet wrote:
> > > Oops, I thought I ran the tests on the whole series. I missed this one.  
> >
> > BTW, ICMPv6 has the same potential problem, I will amend both cases.  
> 
> I ran again the tests for v3, got an unrelated crash, FYI.

Yes, FWIW that's
https://lore.kernel.org/all/20250129191937.GR1977892@ZenIV/
we have the fix queued up locally in NIPA. Merge windows are fun!
Eric Dumazet Feb. 4, 2025, 4:56 p.m. UTC | #7 
On Tue, Feb 4, 2025 at 5:21 PM Matthieu Baerts <matttbe@kernel.org> wrote:
>
> Hi Eric,
>
> On 04/02/2025 11:35, Eric Dumazet wrote:
> > On Tue, Feb 4, 2025 at 5:57 AM Eric Dumazet <edumazet@google.com> wrote:
> >>
> >> On Tue, Feb 4, 2025 at 5:14 AM Eric Dumazet <edumazet@google.com> wrote:
> >>>
> >>> On Tue, Feb 4, 2025 at 12:36 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >>>>
> >>>> On Mon,  3 Feb 2025 14:30:39 +0000 Eric Dumazet wrote:
> >>>>> @@ -611,9 +611,9 @@ void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info,
> >>>>>               goto out;
> >>>>>
> >>>>>       if (rt->dst.dev)
> >>>>> -             net = dev_net(rt->dst.dev);
> >>>>> +             net = dev_net_rcu(rt->dst.dev);
> >>>>>       else if (skb_in->dev)
> >>>>> -             net = dev_net(skb_in->dev);
> >>>>> +             net = dev_net_rcu(skb_in->dev);
> >>>>>       else
> >>>>>               goto out;
> >>>>
> >>>> Hm. Weird. NIPA says this one is not under RCU.
> >>>>
> >>>> [  275.730657][    C1] ./include/net/net_namespace.h:404 suspicious rcu_dereference_check() usage!
> >>>> [  275.731033][    C1]
> >>>> [  275.731033][    C1] other info that might help us debug this:
> >>>> [  275.731033][    C1]
> >>>> [  275.731471][    C1]
> >>>> [  275.731471][    C1] rcu_scheduler_active = 2, debug_locks = 1
> >>>> [  275.731799][    C1] 1 lock held by swapper/1/0:
> >>>> [  275.732000][    C1]  #0: ffffc900001e0ae8 ((&n->timer)){+.-.}-{0:0}, at: call_timer_fn+0xe8/0x230
> >>>> [  275.732354][    C1]
> >>>> [  275.732354][    C1] stack backtrace:
> >>>> [  275.732638][    C1] CPU: 1 UID: 0 PID: 0 Comm: swapper/1 Not tainted 6.13.0-virtme #1
> >>>> [  275.732643][    C1] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> >>>> [  275.732646][    C1] Call Trace:
> >>>> [  275.732647][    C1]  <IRQ>
> >>>> [  275.732651][    C1]  dump_stack_lvl+0xb0/0xd0
> >>>> [  275.732663][    C1]  lockdep_rcu_suspicious+0x1ea/0x280
> >>>> [  275.732678][    C1]  __icmp_send+0xb0d/0x1580
> >>>> [  275.732695][    C1]  ? tcp_data_queue+0x8/0x22d0
> >>>> [  275.732701][    C1]  ? lockdep_hardirqs_on_prepare+0x12b/0x410
> >>>> [  275.732712][    C1]  ? __pfx___icmp_send+0x10/0x10
> >>>> [  275.732719][    C1]  ? tcp_check_space+0x3ce/0x5f0
> >>>> [  275.732742][    C1]  ? rcu_read_lock_any_held+0x43/0xb0
> >>>> [  275.732750][    C1]  ? validate_chain+0x1fe/0xae0
> >>>> [  275.732771][    C1]  ? __pfx_validate_chain+0x10/0x10
> >>>> [  275.732778][    C1]  ? hlock_class+0x4e/0x130
> >>>> [  275.732784][    C1]  ? mark_lock+0x38/0x3e0
> >>>> [  275.732788][    C1]  ? sock_put+0x1a/0x60
> >>>> [  275.732806][    C1]  ? __lock_acquire+0xb9a/0x1680
> >>>> [  275.732822][    C1]  ipv4_send_dest_unreach+0x3b4/0x800
> >>>> [  275.732829][    C1]  ? neigh_invalidate+0x1c7/0x540
> >>>> [  275.732837][    C1]  ? __pfx_ipv4_send_dest_unreach+0x10/0x10
> >>>> [  275.732850][    C1]  ipv4_link_failure+0x1b/0x190
> >>>> [  275.732856][    C1]  arp_error_report+0x96/0x170
> >>>> [  275.732862][    C1]  neigh_invalidate+0x209/0x540
> >>>> [  275.732873][    C1]  neigh_timer_handler+0x87a/0xdf0
> >>>> [  275.732883][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
> >>>> [  275.732886][    C1]  call_timer_fn+0x13b/0x230
> >>>> [  275.732891][    C1]  ? call_timer_fn+0xe8/0x230
> >>>> [  275.732894][    C1]  ? call_timer_fn+0xe8/0x230
> >>>> [  275.732899][    C1]  ? __pfx_call_timer_fn+0x10/0x10
> >>>> [  275.732902][    C1]  ? mark_lock+0x38/0x3e0
> >>>> [  275.732920][    C1]  __run_timers+0x545/0x810
> >>>> [  275.732925][    C1]  ? __pfx_neigh_timer_handler+0x10/0x10
> >>>> [  275.732936][    C1]  ? __pfx___run_timers+0x10/0x10
> >>>> [  275.732939][    C1]  ? __lock_release+0x103/0x460
> >>>> [  275.732947][    C1]  ? do_raw_spin_lock+0x131/0x270
> >>>> [  275.732952][    C1]  ? __pfx_do_raw_spin_lock+0x10/0x10
> >>>> [  275.732956][    C1]  ? lock_acquire+0x32/0xc0
> >>>> [  275.732958][    C1]  ? timer_expire_remote+0x96/0xf0
> >>>> [  275.732967][    C1]  timer_expire_remote+0x9e/0xf0
> >>>> [  275.732970][    C1]  tmigr_handle_remote_cpu+0x278/0x440
> >>>> [  275.732977][    C1]  ? __pfx_tmigr_handle_remote_cpu+0x10/0x10
> >>>> [  275.732981][    C1]  ? __pfx___lock_release+0x10/0x10
> >>>> [  275.732985][    C1]  ? __pfx_lock_acquire.part.0+0x10/0x10
> >>>> [  275.733015][    C1]  tmigr_handle_remote_up+0x1a6/0x270
> >>>> [  275.733027][    C1]  ? __pfx_tmigr_handle_remote_up+0x10/0x10
> >>>> [  275.733036][    C1]  __walk_groups.isra.0+0x44/0x160
> >>>> [  275.733051][    C1]  tmigr_handle_remote+0x20b/0x300
> >>>>
> >>>> Decoded:
> >>>> https://netdev-3.bots.linux.dev/vmksft-mptcp-dbg/results/976941/vm-crash-thr0-1
> >>>
> >>> Oops, I thought I ran the tests on the whole series. I missed this one.
> >>
> >> BTW, ICMPv6 has the same potential problem, I will amend both cases.
> >
> > I ran again the tests for v3, got an unrelated crash, FYI.
> >
> > 14237.095216] #PF: supervisor instruction fetch in kernel mode
> > [14237.095570] #PF: error_code(0x0010) - not-present page
> > [14237.095915] PGD 1e58067 P4D 1e58067 PUD ce1c067 PMD 0
> > [14237.096991] Oops: Oops: 0010 [#1] SMP DEBUG_PAGEALLOC NOPTI
> > [14237.097507] CPU: 0 UID: 0 PID: 6371 Comm: python3 Not tainted
> > 6.13.0-virtme #1559
> > [14237.098045] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),
> > BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> > [14237.098578] RIP: 0010:0x0
> > [14237.099324] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
> > [14237.099752] RSP: 0018:ffffacfd4486bed0 EFLAGS: 00000286
> > [14237.100079] RAX: 0000000000000000 RBX: ffff9af502607200 RCX: 0000000000000002
> > [14237.100452] RDX: 00007fffc684a690 RSI: 0000000000005401 RDI: ffff9af502607200
> > [14237.100821] RBP: 0000000000005401 R08: 0000000000000001 R09: 0000000000000000
> > [14237.101182] R10: 0000000000000001 R11: 0000000000000000 R12: 00007fffc684a690
> > [14237.101542] R13: ffff9af50888ed68 R14: ffff9af502607200 R15: 0000000000000000
> > [14237.101956] FS:  00007f76b73f95c0(0000) GS:ffff9af57cc00000(0000)
> > knlGS:0000000000000000
> > [14237.102372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [14237.102679] CR2: ffffffffffffffd6 CR3: 00000000039ca000 CR4: 00000000000006f0
> > [14237.103160] Call Trace:
> > [14237.103435]  <TASK>
> > [14237.103720]  ? __die_body.cold+0x19/0x26
> > [14237.104340]  ? page_fault_oops+0x134/0x2a0
> > [14237.104553]  ? cp_new_stat+0x157/0x190
> > [14237.104799]  ? exc_page_fault+0x68/0x230
> > [14237.105013]  ? asm_exc_page_fault+0x26/0x30
> > [14237.105259]  full_proxy_unlocked_ioctl+0x63/0x90
> > [14237.105546]  __x64_sys_ioctl+0x97/0xc0
> > [14237.105754]  do_syscall_64+0x72/0x180
> > [14237.105949]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> I think I got this issue as well on MPTCP side, when using GCOV, but
> something else using the debugfs could trigger that as well I guess. It
> is apparently fixed in the Linus tree, see 57b314752ec0 ("debugfs: Fix
> the missing initializations in __debugfs_file_get()")
>
> https://lore.kernel.org/all/20250129191937.GR1977892@ZenIV/

Great, thanks for the info :)
diff mbox series

Patch

diff --git a/net/ipv4/icmp.c b/net/ipv4/icmp.c
index 094084b61bff8a17c4e85c99019b84e9cba21599..19bf8edd6759872fe667af82790b77b01212271b 100644
--- a/net/ipv4/icmp.c
+++ b/net/ipv4/icmp.c
@@ -401,7 +401,7 @@  static void icmp_reply(struct icmp_bxm *icmp_param, struct sk_buff *skb)
 {
 	struct ipcm_cookie ipc;
 	struct rtable *rt = skb_rtable(skb);
-	struct net *net = dev_net(rt->dst.dev);
+	struct net *net = dev_net_rcu(rt->dst.dev);
 	bool apply_ratelimit = false;
 	struct flowi4 fl4;
 	struct sock *sk;
@@ -611,9 +611,9 @@  void __icmp_send(struct sk_buff *skb_in, int type, int code, __be32 info,
 		goto out;
 
 	if (rt->dst.dev)
-		net = dev_net(rt->dst.dev);
+		net = dev_net_rcu(rt->dst.dev);
 	else if (skb_in->dev)
-		net = dev_net(skb_in->dev);
+		net = dev_net_rcu(skb_in->dev);
 	else
 		goto out;
 
@@ -834,7 +834,7 @@  static void icmp_socket_deliver(struct sk_buff *skb, u32 info)
 	 * avoid additional coding at protocol handlers.
 	 */
 	if (!pskb_may_pull(skb, iph->ihl * 4 + 8)) {
-		__ICMP_INC_STATS(dev_net(skb->dev), ICMP_MIB_INERRORS);
+		__ICMP_INC_STATS(dev_net_rcu(skb->dev), ICMP_MIB_INERRORS);
 		return;
 	}
 
@@ -868,7 +868,7 @@  static enum skb_drop_reason icmp_unreach(struct sk_buff *skb)
 	struct net *net;
 	u32 info = 0;
 
-	net = dev_net(skb_dst(skb)->dev);
+	net = dev_net_rcu(skb_dst(skb)->dev);
 
 	/*
 	 *	Incomplete header ?
@@ -979,7 +979,7 @@  static enum skb_drop_reason icmp_unreach(struct sk_buff *skb)
 static enum skb_drop_reason icmp_redirect(struct sk_buff *skb)
 {
 	if (skb->len < sizeof(struct iphdr)) {
-		__ICMP_INC_STATS(dev_net(skb->dev), ICMP_MIB_INERRORS);
+		__ICMP_INC_STATS(dev_net_rcu(skb->dev), ICMP_MIB_INERRORS);
 		return SKB_DROP_REASON_PKT_TOO_SMALL;
 	}
 
@@ -1011,7 +1011,7 @@  static enum skb_drop_reason icmp_echo(struct sk_buff *skb)
 	struct icmp_bxm icmp_param;
 	struct net *net;
 
-	net = dev_net(skb_dst(skb)->dev);
+	net = dev_net_rcu(skb_dst(skb)->dev);
 	/* should there be an ICMP stat for ignored echos? */
 	if (READ_ONCE(net->ipv4.sysctl_icmp_echo_ignore_all))
 		return SKB_NOT_DROPPED_YET;
@@ -1040,9 +1040,9 @@  static enum skb_drop_reason icmp_echo(struct sk_buff *skb)
 
 bool icmp_build_probe(struct sk_buff *skb, struct icmphdr *icmphdr)
 {
+	struct net *net = dev_net_rcu(skb->dev);
 	struct icmp_ext_hdr *ext_hdr, _ext_hdr;
 	struct icmp_ext_echo_iio *iio, _iio;
-	struct net *net = dev_net(skb->dev);
 	struct inet6_dev *in6_dev;
 	struct in_device *in_dev;
 	struct net_device *dev;
@@ -1181,7 +1181,7 @@  static enum skb_drop_reason icmp_timestamp(struct sk_buff *skb)
 	return SKB_NOT_DROPPED_YET;
 
 out_err:
-	__ICMP_INC_STATS(dev_net(skb_dst(skb)->dev), ICMP_MIB_INERRORS);
+	__ICMP_INC_STATS(dev_net_rcu(skb_dst(skb)->dev), ICMP_MIB_INERRORS);
 	return SKB_DROP_REASON_PKT_TOO_SMALL;
 }
 
@@ -1198,7 +1198,7 @@  int icmp_rcv(struct sk_buff *skb)
 {
 	enum skb_drop_reason reason = SKB_DROP_REASON_NOT_SPECIFIED;
 	struct rtable *rt = skb_rtable(skb);
-	struct net *net = dev_net(rt->dst.dev);
+	struct net *net = dev_net_rcu(rt->dst.dev);
 	struct icmphdr *icmph;
 
 	if (!xfrm4_policy_check(NULL, XFRM_POLICY_IN, skb)) {
@@ -1371,9 +1371,9 @@  int icmp_err(struct sk_buff *skb, u32 info)
 	struct iphdr *iph = (struct iphdr *)skb->data;
 	int offset = iph->ihl<<2;
 	struct icmphdr *icmph = (struct icmphdr *)(skb->data + offset);
+	struct net *net = dev_net_rcu(skb->dev);
 	int type = icmp_hdr(skb)->type;
 	int code = icmp_hdr(skb)->code;
-	struct net *net = dev_net(skb->dev);
 
 	/*
 	 * Use ping_err to handle all icmp errors except those