linux-kernel - Re: [RFC] powerpc/kvm: Fix spinlock member access for PREEMPT

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: <8734l373eb.fsf@mail.lhotse>
Date: Fri, 11 Oct 2024 13:57:16 +1100
From: Michael Ellerman <mpe@...erman.id.au>
To: Paolo Bonzini <pbonzini@...hat.com>, Vishal Chourasia
 <vishalc@...ux.ibm.com>, linuxppc-dev@...ts.ozlabs.org, Nicholas Piggin
 <npiggin@...il.com>, Christophe Leroy <christophe.leroy@...roup.eu>,
 Naveen N Rao <naveen@...nel.org>, Madhavan Srinivasan
 <maddy@...ux.ibm.com>, kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [RFC] powerpc/kvm: Fix spinlock member access for PREEMPT_RT

Paolo Bonzini <pbonzini@...hat.com> writes:
> On 10/10/24 20:09, Vishal Chourasia wrote:
>> Hi,
>> 
>> While building the kernel with CONFIG_PREEMPT_RT, I encountered several
>> compilation errors in the PowerPC KVM code. The issues appear in
>> book3s_hv_rm_mmu.c where it tries to access the 'rlock' member of struct
>> spinlock, which doesn't exist in the RT configuration.
>
> How was this tested? I suspect that putting to sleep a task that is 
> running in real mode is a huge no-no.

Yeah.

Even without preempt, spin_lock() can end up in debug/tracing code that
will blow up in real mode.

Vishal, if you look at the history of that file you'll see eg:

  87013f9c602c ("powerpc/kvm/book3s: switch from raw_spin_*lock to arch_spin_lock.")

> The actual solution would have to 
> be to split mmu_lock into a spin_lock and a raw_spin_lock, but that's a 
> huge amount of work probably.  I'd just add a "depends on !PPC || 
> !KVM_BOOK3S_64_HV" or something like that, to prevent enabling KVM-HV on 
> PREEMPT_RT kernels.

Yeah that should work to get something building.

The bulk (or all?) of that file is not used for Radix guests, only for
hash page table MMU guests.

So I think it should be possible to hide that code behind a new CONFIG
option that controls support for HPT guests. And then that option could
be incompatible with PREEMPT_RT. But that will require unstitching some
of the connections between that code and the other ppc KVM code.

cheers