netdev - Re: Thinkpad P17 keep hanging in ipv6_addrconf addrconf_verify

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

Message-ID: <69717129398d05b18df1c1300bfb41da268c52a0.camel@sipsolutions.net>
Date: Mon, 04 Dec 2023 11:57:44 +0100
From: Johannes Berg <johannes@...solutions.net>
To: Marc MERLIN <marc@...lins.org>, Linux Kernel Mailing List
	 <linux-kernel@...r.kernel.org>, netdev@...r.kernel.org, 
	linux-wireless@...r.kernel.org, ilw@...ux.intel.com
Cc: "Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: Thinkpad P17 keep hanging in ipv6_addrconf addrconf_verify_work
 / netlink in 6.4 and 6.6

On Sun, 2023-12-03 at 23:35 -0800, Marc MERLIN wrote:
> So, I thought that maybe my custom built kernel had options that somehow
> made P17 unhappy, and went to a stock debian kernel.
> It's not really looking better with that kernel unfortunately :-/
> 
> Still seems unhappy with networking, first wireless and then ethtool.
> Adding wireless lists to Cc just in case

Well clearly something is not unlocking the RTNL, but digging through
the below I only found places that want to acquire the RTNL and wait
forever on it (including wireless), but none that actually got stuck
while having it acquired already.


Actually ... no that's wrong.

I can:

> > [  363.945427] INFO: task powertop:6279 blocked for more than 120 seconds.
> > [  363.945446]       Tainted: G     U             6.6.3-amd64-preempt-sysrq-20220227 #4
> > [  363.945452] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> > [  363.945456] task:powertop        state:D stack:0     pid:6279  ppid:6267   flags:0x00004002
> > [  363.945468] Call Trace:
> > [  363.945473]  <TASK>
> > [  363.945481]  __schedule+0xba0/0xc05
> > [  363.945497]  schedule+0x95/0xce
> > [  363.945504]  schedule_preempt_disabled+0x15/0x22
> > [  363.945511]  __mutex_lock.constprop.0+0x18b/0x291
> > [  363.945520]  ? __pfx_pci_pm_runtime_resume+0x40/0x40
> > [  363.945531]  igc_resume+0x18b/0x1ca [igc 1a96e277f8878a2a3c9599226acd0eeb7de577b7]

this is trying to acquire the RTNL, by looking at the code

> > [  363.945566]  __rpm_callback+0x7a/0xe7
> > [  363.945578]  rpm_callback+0x35/0x64
> > [  363.945587]  ? __pfx_pci_pm_runtime_resume+0x40/0x40
> > [  363.945592]  rpm_resume+0x342/0x44a
> > [  363.945600]  ? __kmem_cache_alloc_node+0x123/0x154
> > [  363.945614]  __pm_runtime_resume+0x5a/0x7a
> > [  363.945624]  dev_ethtool+0x15a/0x24e7

but this already holds it

So looks like bug in the 'igc' driver wrt. runtime PM locking.

johannes