[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <833cecca4460ae3c371455cef75b40a1f3922758.camel@mediatek.com>
Date: Wed, 1 Mar 2023 12:37:29 +0000
From: Cheng-Jui Wang (王正睿)
<Cheng-Jui.Wang@...iatek.com>
To: "peterz@...radead.org" <peterz@...radead.org>,
"rostedt@...dmis.org" <rostedt@...dmis.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"surenb@...gle.com" <surenb@...gle.com>,
"torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
wsd_upstream <wsd_upstream@...iatek.com>,
"paulmck@...nel.org" <paulmck@...nel.org>,
Bobule Chang (張弘義)
<bobule.chang@...iatek.com>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"fweisbec@...il.com" <fweisbec@...il.com>
Subject: Re: [BUG v6.0-rc2] lockdep splat on ct_kernel_enter()
On Mon, 2022-08-22 at 16:44 -0400, Steven Rostedt wrote:
> My tests are failing because of this splat:
>
> [ 16.073659] ------------[ cut here ]------------
> [ 16.074407] bus: 'platform': add driver acpi-ged
> [ 16.074424] DEBUG_LOCKS_WARN_ON(lockdep_hardirqs_enabled())
> [ 16.074424] WARNING: CPU: 0 PID: 0 at
> kernel/locking/lockdep.c:5506 check_flags+0x114/0x1d0
> [ 16.074424] lock_is_held_type+0x6f/0x130
> [ 16.186284] rcu_read_lock_sched_held+0x4a/0x90
> [ 16.186284] trace_rcu_dyntick+0x3a/0xe0
> [ 16.186284] ct_kernel_enter.constprop.0+0x66/0xa0
> [ 16.186284] ct_idle_exit+0xd/0x30
> [ 16.186284] cpuidle_enter_state+0x28a/0x310
> [ 16.186284] cpuidle_enter+0x2e/0x50
> [ 16.186284] do_idle+0x1ec/0x280
Our test in v6.1 stable is failing due to this splat too. The v6.1
stable kernel still has this splat.
This splat can be fixed by Peter's patch
https://lore.kernel.org/all/20220608144516.808451191@infradead.org/
, but the fix is part of a big patchset
https://lore.kernel.org/all/20220608142723.103523089@infradead.org/
introduced in 6.2.
Could the fixes be backported to v6.1 stable?
Powered by blists - more mailing lists