Re: rcu pending

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Aug 18, 2024 at 10:01:42AM GMT, Paul E. McKenney wrote:
> But you only need one callback per live outstanding "cookie" returned
> from get_state_synchronize_rcu*() or start_poll_synchronize_rcu().
> Or am I missing something here?

Maybe I am?

I've been assuming that if rcu callbacks are getting punted off to a
kthread that we can't rely on them being completed in any particular
timeframe - i.e. the number of grace periods with outstanding callbacks
would be unbounded.

You're saying that NUM_ACTIVE_RCU_POLL_FULL_OLDSTATE _does_ include
grace periods with outstanding callbacks? Just want to be clear on that.

> If so, create a structure that as an rcu_head structure and a
> cookies.  Create an array of this structure (possibly on a per-CPU,
> per-shard, or whatever basis), sized by NUM_ACTIVE_RCU_POLL_OLDSTATE or
> NUM_ACTIVE_RCU_POLL_FULL_OLDSTATE, depending on which set of APIs you
> are using.  Have a lock that guards the full array.
> 
> You also need some sort of structure tracking whatever data elements
> for which the grace periods are intended, but I will not speculate
> on what that might be.
> 
> Then when you have a data element that needs to wait for a grace period:
> 
> 1.	Get a cookie from get_state_synchronize_rcu() or similar.
> 
> 2.	Acquire the lock.
> 
> 3.	If this cookie is already in the array, release the lock and
> 	you are done.  (Give or take associating the cookie with the
> 	data element, however you choose to do this.)
> 
> 4.	If this cookie has already expired (it can happen!), set the new
> 	data element up to be processed (or maybe process it immediately,
> 	as the case may be).  Proceed to the next step only for unexpired
> 	new cookies, otherwise, release the lock.

There's another race, though - we're associating sequence numbers from
get_state_synchrize_rcu() with call_rcu() callbacks, and that's racy -
they can end up with different grace periods...

I think solving that would require a call_rcu_for_gp() API that takes
the sequence number we previously got from get_state_synchronize_rcu().

I think we can avoid your race in #4 entirely by simply waiting until we
have irqs disabled to call get_state_synchronize_rcu() (at least for the
normal RCU variant, the SRCU variant will naturally need a
srcu_read_lock() if we want to handle it that way).

That might be beneficial because then call_rcu_for_gp() can never race
with the grace period expiring.




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux