netdev - Re: [PATCH] net: stmmac: ethtool: Fixed calltrace caused by unbalanced disable_irq

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] [day] [month] [year] [list]

Message-ID: <264E2933B2545567+20240117151759.0dc40c3d@john-PC>
Date: Wed, 17 Jan 2024 15:17:59 +0800
From: Qiang Ma <maqianga@...ontech.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: alexandre.torgue@...s.st.com, joabreu@...opsys.com, davem@...emloft.net,
 edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
 mcoquelin.stm32@...il.com, netdev@...r.kernel.org,
 linux-stm32@...md-mailman.stormreply.com,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] net: stmmac: ethtool: Fixed calltrace caused by
 unbalanced disable_irq_wake calls

On Tue, 16 Jan 2024 23:27:39 +0100
Andrew Lunn <andrew@...n.ch> wrote:

> On Fri, Jan 12, 2024 at 10:12:49AM +0800, Qiang Ma wrote:
> > We found the following dmesg calltrace when testing the GMAC NIC
> > notebook:
> > 
> > [9.448656] ------------[ cut here ]------------
> > [9.448658] Unbalanced IRQ 43 wake disable
> > [9.448673] WARNING: CPU: 3 PID: 1083 at kernel/irq/manage.c:688
> > irq_set_irq_wake+0xe0/0x128 [9.448717] CPU: 3 PID: 1083 Comm:
> > ethtool Tainted: G           O      4.19 #1 [9.448773]         ...
> > [9.448774] Call Trace:
> > [9.448781] [<9000000000209b5c>] show_stack+0x34/0x140
> > [9.448788] [<9000000000d52700>] dump_stack+0x98/0xd0
> > [9.448794] [<9000000000228610>] __warn+0xa8/0x120
> > [9.448797] [<9000000000d2fb60>] report_bug+0x98/0x130
> > [9.448800] [<900000000020a418>] do_bp+0x248/0x2f0
> > [9.448805] [<90000000002035f4>] handle_bp_int+0x4c/0x78
> > [9.448808] [<900000000029ea40>] irq_set_irq_wake+0xe0/0x128
> > [9.448813] [<9000000000a96a7c>] stmmac_set_wol+0x134/0x150
> > [9.448819] [<9000000000be6ed0>] dev_ethtool+0x1368/0x2440
> > [9.448824] [<9000000000c08350>] dev_ioctl+0x1f8/0x3e0
> > [9.448827] [<9000000000bb2a34>] sock_ioctl+0x2a4/0x450
> > [9.448832] [<900000000046f044>] do_vfs_ioctl+0xa4/0x738
> > [9.448834] [<900000000046f778>] ksys_ioctl+0xa0/0xe8
> > [9.448837] [<900000000046f7d8>] sys_ioctl+0x18/0x28
> > [9.448840] [<9000000000211ab4>] syscall_common+0x20/0x34
> > [9.448842] ---[ end trace 40c18d9aec863c3e ]---
> > 
> > Multiple disable_irq_wake() calls will keep decreasing the IRQ
> > wake_depth, When wake_depth is 0, calling disable_irq_wake() again,
> > will report the above calltrace.
> > 
> > Due to the need to appear in pairs, we cannot call
> > disable_irq_wake() without calling enable_irq_wake(). Fix this by
> > making sure there are no unbalanced disable_irq_wake() calls.  
> 
> Just for my understanding. You trigger this by doing lots of
> 
> ethtool -s eth42 wol g
> 
> or similar without doing a matching
> 
> ethtool -s eth42 wol d
> 
> to disable wol?
> 
> Its a bit late now, but its good to give instructions how to reproduce
> the issue in the commit message.
> 
>     Andrew
> 

yes, my environment has not call enable_irq_wake(), so calling
disable_irq_wake() directly through the "ethtool -s ethxx wol d"
command will cause this problem.

    Qiang Ma