linux-kernel - Re: [PATCH] arm: smp: Avoid false positive CPU hotplug Lockdep-RCU splat

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: <f15aea08-8daa-4994-a8f6-be0461b06539@nokia.com>
Date: Fri, 9 Aug 2024 15:37:38 +0200
From: Stefan Wiehler <stefan.wiehler@...ia.com>
To: "Russell King (Oracle)" <linux@...linux.org.uk>,
 Will Deacon <will@...nel.org>
Cc: Joel Fernandes <joel@...lfernandes.org>,
 "Paul E. McKenney" <paulmck@...nel.org>,
 Josh Triplett <josh@...htriplett.org>, Boqun Feng <boqun.feng@...il.com>,
 Steven Rostedt <rostedt@...dmis.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>,
 linux-arm-kernel@...ts.infradead.org, rcu@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm: smp: Avoid false positive CPU hotplug Lockdep-RCU
 splat

I'd like to revive the discussion and quickly summarize our options to
avoid a false-positive Lockdep-RCU splat when check_and_switch_context()
acquires the ASID spinlock:

1. Briefly report CPU as online again via
   rcutree_report_cpu_{starting|dead}()
2. Replace raw_spin_lock*() by arch_spin_lock()
3. Remove ASID spinlock

Both 1. and 2. are workarounds with different pros and cons/proponents.
Regarding 3., the last comment form Russell is:

> For 32-bit non-LPAE, I can't recall any issues, nor can I think of any
> because module space is just another few entries in the L1 page tables
> below the direct mapping (which isn't a problem because we don't use
> anything in hardware to separate the kernel space from user space in
> the page tables.) TTBCR is set to 0.
> 
> For LPAE, there may be issues there because TTBR0 and TTBR1 are both
> used, and TTBCR.T1SZ is set non-zero to:
> 
> arch/arm/include/asm/pgtable-3level-hwdef.h:#define TTBR1_SIZE (((PAGE_OFFSET >> 30) - 1) << 16)
> 
> so I suspect that's where the problems may lie - but then module
> mappings should also exist in init_mm (swapper_pg_dir) and should
> be global.

Unfortunately I'm don't feel qualified to contribute to the discussion
on option 3. Russell and Will, would you be able to spare some time to
drive this further? Otherwise I would propose to make a decision on
going for option 1 or 2.

Kind regards,

Stefan