Re: [RFC PATCH 0/3] srcu: KVM: Add, export and use call_srcu_expedited()

[Sean Christopherson <seanjc@google.com>]

On Fri, Mar 13, 2026, Kunwu Chan wrote:
> On 3/10/26 03:30, Sean Christopherson wrote:
> > We've got a conundrum in KVM where we have multiple use cases that generally
> > want the same thing (eliminate waiting on guest configuration changes whenever
> > possible), but use KVM uAPIs in slightly different ways and effectively create
> > competing requirements.
> > 
> > The crux of the problem is that one use case wants KVM to free an object via
> > call_srcu() so that the task doesn't risk getting stalled waiting for a grace
> > period.  But for the other use case, using call_srcu() can trigger a
> > non-expedited grace period and cause a synchronize_srcu_expedited() in a
> > different ioctl (that must do a full sync, i.e. can't use call_srcu()) to stall
> > waiting for the non-expedited grace period.
> > 
> > Tagged RFC because while having the call_srcu() request do an expedited grace
> > period eliminates the unwanted synchronize_srcu_expedited() stalls, this feels
> > like a very crude fix.   That said, I'm definitely not opposed to this being a
> > final solution if it's the best option available.
> > 
> > Sean Christopherson (3):
> >   srcu: Declare exported symbols before including srcu{tiny,tree}.h
> >   srcu: Add and export call_srcu_expedited() to avoid transferring grace
> >     periods
> 
> Hi,
> 
> Thanks for writing this up.
> 
> The scenario you describe looks plausible.
> 
> That said, the cover letter wording might be a bit stronger than
> current SRCU behavior warrants. A later synchronize_srcu_expedited()
> can attempt to expedite an in-flight grace period, but it cannot
> avoid delay already incurred (for example, if the GP has already
> gone to sleep).
> 
> More generally, before adding an exported call_srcu_expedited()
> helper, should we consider improving existing in-flight promotion
> or delay behavior, or otherwise making the "expedite current GP"
> case more explicit without introducing a new callback-facing API?

I'm all for a general solution, but that's far, far beyond my SRCU knowledge level.
I was quite proud of myself for piecing together the incurred-delay. :-)

FYI, I'm going to be unavailable for ~2 weeks.  Nikita (Cc'd) can likely help test
potential fixes.

Thanks!