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
  KVM: Expedite SRCU callbacks when freeing objects during I/O bus
    registration

 include/linux/srcu.h     | 10 +++++-----
 include/linux/srcutiny.h |  8 ++++++--
 include/linux/srcutree.h |  2 ++
 kernel/rcu/srcutree.c    |  7 +++++++
 virt/kvm/kvm_main.c      |  2 +-
 5 files changed, 21 insertions(+), 8 deletions(-)


base-commit: 5128b972fb2801ad9aca54d990a75611ab5283a9
-- 
2.53.0.473.g4a7958ca14-goog

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?


Thanx, Kunwu

>   KVM: Expedite SRCU callbacks when freeing objects during I/O bus
>     registration
> 
>  include/linux/srcu.h     | 10 +++++-----
>  include/linux/srcutiny.h |  8 ++++++--
>  include/linux/srcutree.h |  2 ++
>  kernel/rcu/srcutree.c    |  7 +++++++
>  virt/kvm/kvm_main.c      |  2 +-
>  5 files changed, 21 insertions(+), 8 deletions(-)
> 
> 
> base-commit: 5128b972fb2801ad9aca54d990a75611ab5283a9

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!