Re: [PATCH v5 3/4] KVM: s390: Change the fi->lock to a raw_spinlock for RT case

[Heiko Carstens]

Adding Peter :)

On Thu, May 07, 2026 at 09:17:00AM -0400, Matthew Rosato wrote:
> On 5/7/26 5:56 AM, Heiko Carstens wrote:
> > On Wed, May 06, 2026 at 10:50:52AM -0400, Douglas Freimuth wrote:
> >> On 5/6/26 12:57 AM, Heiko Carstens wrote:
> >>> On Tue, May 05, 2026 at 07:37:27PM +0200, Douglas Freimuth wrote:
> >>>> s390 needs to maintain support for an RT kernel. This requires the
> >>>> floating interrupt lock, fi->lock to be changed to a raw spin lock
> >>>> since the fi->lock maybe called with interrupts disabled in __inject_io.
> >>>>
> >>>> Signed-off-by: Douglas Freimuth <freimuth@xxxxxxxxxxxxx>
> >>>> ---
> >>>>   arch/s390/include/asm/kvm_host.h |  2 +-
> >>>>   arch/s390/kvm/intercept.c        |  4 +-
> >>>>   arch/s390/kvm/interrupt.c        | 68 ++++++++++++++++----------------
> >>>>   arch/s390/kvm/kvm-s390.c         |  2 +-
> >>>>   4 files changed, 38 insertions(+), 38 deletions(-)
> >>>
> >>> s390 does not support RT, but I guess you are referring to a lockdep splat
> >>> which you would see without doing this change, similar like we have seen at
> >>> other places.
> >>>
> >>> Can you include the relevant parts of the splat for reference, please?

...

> AFAIU it is only problematic if we (s390) should ever want to support RT
> in the future.

I don't see that coming, but nobody knows what happens in future.

...

> My original thinking was 'well, it won't hurt to use the raw spinlocks
> in the new code' so I set Doug down this road with my review comments --
> I did not consider that there would be a need for additional fallout
> like this patch, which means increased chance of regressions (see below)
> to accomodate a feature that we don't support today.
> 
> If you are saying it's OK to simply not care about RT for s390 now, then
> AFAICT it should be fine to just use s/raw_spin_)lock/spin_lock/ for
> this whole series, drop this patch and then ignore the subsequent
> Sashiko complaints about RT.
> 
> What do you think?

So... after having given this a second thought: we do not have
PROVE_RAW_LOCK_NESTING enabled in our debug_defconfig (either we missed it,
or somebody (cough) thought it is not relevant for s390). That said, I
believe we should enable it, fix all fallout and also make sure that new
code does not generate any lockdep splats with PROVE_RAW_LOCK_NESTING
enabled.

Rationale: even though it is not relevant for s390, we also change common
code; and by ignoring PROVE_RAW_LOCK_NESTING we might cause problems for
other architectures by introducing incorrect nesting of locks in common
code. So yes, your thinking is correct.

Peter, I just added you to cc, so you can correct me if I'm entirely wrong.