linux-kernel - Re: [BUG v6.0-rc2] lockdep splat on ct_kernel

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZABFX8rkPwC2vm8/@kroah.com>
Date:   Thu, 2 Mar 2023 07:42:39 +0100
From:   "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>
To:     Cheng-Jui Wang (王正睿) 
        <Cheng-Jui.Wang@...iatek.com>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "surenb@...gle.com" <surenb@...gle.com>,
        "rostedt@...dmis.org" <rostedt@...dmis.org>,
        "torvalds@...ux-foundation.org" <torvalds@...ux-foundation.org>,
        "paulmck@...nel.org" <paulmck@...nel.org>,
        wsd_upstream <wsd_upstream@...iatek.com>,
        Bobule Chang (張弘義) 
        <bobule.chang@...iatek.com>,
        "fweisbec@...il.com" <fweisbec@...il.com>
Subject: Re: [BUG v6.0-rc2] lockdep splat on ct_kernel_enter()

On Thu, Mar 02, 2023 at 03:42:12AM +0000, Cheng-Jui Wang (王正睿) wrote:
> On Wed, 2023-03-01 at 13:52 +0100, gregkh@...uxfoundation.org wrote:
> > On Wed, Mar 01, 2023 at 12:37:29PM +0000, Cheng-Jui Wang (王正睿) wrote:
> > > 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?
> > 
> > What "fixes" exactly are you referring to?  
> a01353cf1896 ("cpuidle: Fix ct_idle_*() usage") and other patches it
> needs.
> 
> > Can you provide a series of
> > git commit ids that cleanly apply or better yet, and series of
> > patches
> > that you have backported and tested to ensure that they work
> > properly?
> Suren has backported part of the patchset to fix this particular issue
> in android14-6.1: 
> https://android-review.googlesource.com/c/kernel/common/+/2449203 to 
> https://android-review.googlesource.com/c/kernel/common/+/2449212. I
> have tested these patches and confirmed these can fix this splat.
> 
> Following are the commit ids of the above series of patches in Linus'
> tree:
> 5e26aa93391195a64871db5d96d7163f0062ca4f
> 8e9ab9e8da1eae61fdff35690d998eaf8cd527dc
> 5fca0d9f5d76664786ca6c09076341def165a677
> e038f7b8028a1d1bc8ac82351c71ea538f19a879
> b3f46658ce40a3467cda82f920dd9d5325ab0eaf
> 4d1be9e745382b41492b0cb9000829863db7133a
> 4ce40e9dbe83153f60d7e4ccd24a1eb4f8264f6a
> c3d42418dca53d6c498a48c408f7a45289593650
> 0c5ffc3d7b15978c6b184938cd6b8af06e436424
> a01353cf1896ea5b8a7bbc5e2b2d38feed8b7aaa

Please submit the full set of backported patches, with your
signed-off-by, to the stable@...r.kernel.org mailing list, and we will
be glad to review them there.

thanks,

greg k-h