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!
