Re: [PATCH net v3] net: stmmac: protect updates of 64-bit statistics counters

From: "Alexis Lothoré" <alexis.lothore@bootlin.com>
To: Eric Dumazet <edumazet@google.com>, Guenter Roeck <linux@roeck-us.net>
Cc: Jisheng Zhang <jszhang@kernel.org>,
	Petr Tesarik <petr@tesarici.cz>,
	Alexandre Torgue <alexandre.torgue@foss.st.com>,
	Jose Abreu <joabreu@synopsys.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Maxime Coquelin <mcoquelin.stm32@gmail.com>,
	Chen-Yu Tsai <wens@csie.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	"open list:STMMAC ETHERNET DRIVER" <netdev@vger.kernel.org>,
	"moderated list:ARM/STM32 ARCHITECTURE"
	<linux-stm32@st-md-mailman.stormreply.com>,
	"moderated list:ARM/STM32 ARCHITECTURE"
	<linux-arm-kernel@lists.infradead.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list:ARM/Allwinner sunXi SoC support"
	<linux-sunxi@lists.linux.dev>,
	Marc Haber <mh+netdev@zugschlus.de>, Andrew Lunn <andrew@lunn.ch>,
	Florian Fainelli <f.fainelli@gmail.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH net v3] net: stmmac: protect updates of 64-bit statistics counters
Date: Tue, 27 Feb 2024 10:40:42 +0100	[thread overview]
Message-ID: <951bc29a-4483-4f4a-9c4e-900db9391112@bootlin.com> (raw)
In-Reply-To: <CANn89iL1piwsbsBx4Z=kySUfmPa9LbZn-SNthgA+W6NEnojgSQ@mail.gmail.com>

Hello, 
FWIW I'm seeing this splat too on STM32MP157 with 6.8.0-rc5 (from wireless tree). It happens systematically a few seconds after link up

[   27.884703] ================================
[   27.888988] WARNING: inconsistent lock state
[   27.893271] 6.8.0-rc5-g59460f7f45e6-dirty #16 Not tainted
[   27.898671] --------------------------------
[   27.902951] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[   27.908954] swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
[   27.914155] d7b764ac (&syncp->seq#3){?.-.}-{0:0}, at: dwmac4_dma_interrupt+0xc4/0x2a8
[   27.921974] {HARDIRQ-ON-W} state was registered at:
[   27.926863]   lock_acquire+0x12c/0x388
[   27.930563]   __u64_stats_update_begin+0x138/0x214
[   27.935372]   stmmac_xmit+0x55c/0xd80
[   27.939064]   dev_hard_start_xmit+0xec/0x2f4
[   27.943362]   sch_direct_xmit+0x94/0x310
[   27.947255]   __dev_queue_xmit+0x3f8/0xd04
[   27.951347]   ip6_finish_output2+0x2fc/0xbc0
[   27.955642]   mld_sendpack+0x268/0x594
[   27.959329]   mld_ifc_work+0x268/0x568
[   27.963115]   process_one_work+0x20c/0x618
[   27.967216]   worker_thread+0x1e8/0x4ac
[   27.971009]   kthread+0x110/0x130
[   27.974296]   ret_from_fork+0x14/0x28
[   27.977982] irq event stamp: 12456
[   27.981353] hardirqs last  enabled at (12455): [<c08e3558>] default_idle_call+0x1c/0x2cc
[   27.989507] hardirqs last disabled at (12456): [<c0100b74>] __irq_svc+0x54/0xd0
[   27.996844] softirqs last  enabled at (12440): [<c010162c>] __do_softirq+0x318/0x4dc
[   28.004586] softirqs last disabled at (12429): [<c012b2a8>] __irq_exit_rcu+0x130/0x184
[   28.012530]
[   28.012530] other info that might help us debug this:
[   28.019040]  Possible unsafe locking scenario:
[   28.019040]
[   28.025043]        CPU0
[   28.027400]        ----
[   28.029857]   lock(&syncp->seq#3);
[   28.033253]   <Interrupt>
[   28.035912]     lock(&syncp->seq#3);
[   28.039410]
[   28.039410]  *** DEADLOCK ***
[   28.039410]
[   28.045416] no locks held by swapper/0/0.
[   28.049395]
[   28.049395] stack backtrace:
[   28.053781] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.8.0-rc5-g59460f7f45e6-dirty #16
[   28.061819] Hardware name: STM32 (Device Tree Support)
[   28.066918]  unwind_backtrace from show_stack+0x18/0x1c
[   28.072140]  show_stack from dump_stack_lvl+0x58/0x70
[   28.077253]  dump_stack_lvl from mark_lock+0xc40/0x12fc
[   28.082478]  mark_lock from __lock_acquire+0x968/0x2c20
[   28.087703]  __lock_acquire from lock_acquire+0x12c/0x388
[   28.093131]  lock_acquire from __u64_stats_update_begin+0x138/0x214
[   28.099372]  __u64_stats_update_begin from dwmac4_dma_interrupt+0xc4/0x2a8
[   28.106219]  dwmac4_dma_interrupt from stmmac_napi_check+0x48/0x1d0
[   28.112558]  stmmac_napi_check from stmmac_interrupt+0xa4/0x184
[   28.118490]  stmmac_interrupt from __handle_irq_event_percpu+0xb0/0x308
[   28.125036]  __handle_irq_event_percpu from handle_irq_event+0x40/0x88
[   28.131578]  handle_irq_event from handle_fasteoi_irq+0xa4/0x258
[   28.137610]  handle_fasteoi_irq from generic_handle_domain_irq+0x30/0x40
[   28.144348]  generic_handle_domain_irq from gic_handle_irq+0x7c/0x90
[   28.150682]  gic_handle_irq from generic_handle_arch_irq+0x34/0x44
[   28.156911]  generic_handle_arch_irq from __irq_svc+0x8c/0xd0
[   28.162631] Exception stack(0xc2201f30 to 0xc2201f78)
[   28.167732] 1f20:                                     ffffffff ffffffff 00000001 000030a7
[   28.175974] 1f40: c220c780 c0178dc4 c2208d54 c22c2e10 00000000 00000000 c0b06d28 c220c22c
[   28.184114] 1f60: 00000000 c2201f80 c08e3558 c08e355c 600f0013 ffffffff
[   28.190727]  __irq_svc from default_idle_call+0x20/0x2cc
[   28.196045]  default_idle_call from do_idle+0xd8/0x144
[   28.201165]  do_idle from cpu_startup_entry+0x30/0x34
[   28.206181]  cpu_startup_entry from rest_init+0xf4/0x198
[   28.211502]  rest_init from arch_post_acpi_subsys_init+0x0/0x18

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com