linux-kernel - Re: [PATCH net] lan966x: Fix sleeping in atomic context

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: <a9d52718-0d4d-4d57-a00d-82b3e66e158a@intel.com>
Date: Wed, 5 Nov 2025 14:38:42 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Horatiu Vultur <horatiu.vultur@...rochip.com>,
	<UNGLinuxDriver@...rochip.com>, <andrew+netdev@...n.ch>,
	<davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>
CC: <netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net] lan966x: Fix sleeping in atomic context



On 11/4/2025 11:49 PM, Horatiu Vultur wrote:
> The following warning was seen when we try to connect using ssh to the device.
> 
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:575
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear
> preempt_count: 1, expected: 0
> INFO: lockdep is turned off.
> CPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G        W           6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE
> Tainted: [W]=WARN
> Hardware name: Generic DT based system
> Call trace:
>  unwind_backtrace from show_stack+0x10/0x14
>  show_stack from dump_stack_lvl+0x7c/0xac
>  dump_stack_lvl from __might_resched+0x16c/0x2b0
>  __might_resched from __mutex_lock+0x64/0xd34
>  __mutex_lock from mutex_lock_nested+0x1c/0x24
>  mutex_lock_nested from lan966x_stats_get+0x5c/0x558
>  lan966x_stats_get from dev_get_stats+0x40/0x43c
>  dev_get_stats from dev_seq_printf_stats+0x3c/0x184
>  dev_seq_printf_stats from dev_seq_show+0x10/0x30
>  dev_seq_show from seq_read_iter+0x350/0x4ec
>  seq_read_iter from seq_read+0xfc/0x194
>  seq_read from proc_reg_read+0xac/0x100
>  proc_reg_read from vfs_read+0xb0/0x2b0
>  vfs_read from ksys_read+0x6c/0xec
>  ksys_read from ret_fast_syscall+0x0/0x1c
> Exception stack(0xf0b11fa8 to 0xf0b11ff0)
> 1fa0:                   00000001 00001000 00000008 be9048d8 00001000 00000001
> 1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001
> 1fe0: 0005404c be9048c0 00018684 b6ec2cd8
> 
> It seems that we are using a mutex in a atomic context which is wrong.
> Change the mutex with a spinlock.
> 

Its a bit hard from just the diff context to confirm that a spinlock is
ok. I checked all the uses of stats_lock and they appear to be covering
only simple register reads and counter accumulations. None of the blocks
looked terribly lock, so a spin lock is probably fine.

Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>


Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)