Re: Internal vs. external barriers (was: Re: Interesting LKMM litmus test)

Alan Stern
2023-01-26T01:45:51Z

On Wed, Jan 25, 2023 at 03:33:08PM -0800, Paul E. McKenney wrote:
> Ah, and returning to the earlier question as to whether srcu_read_unlock()
> can use release semantics instead of smp_mb(), at the very least, this
> portion of the synchronize_srcu() function's header comment must change:
>
> On systems with more than one CPU, when synchronize_srcu()
> returns, each CPU is guaranteed to have executed a full
> memory barrier since the end of its last corresponding SRCU
> read-side critical section whose beginning preceded the call
> to synchronize_srcu().

Yes, that would not be true. But on the other hand, it would be true
that each CPU is guaranteed to have executed a release memory barrier
since the end of its last corresponding SRCU read-side critical section
whose beginning preceded the call to synchronize_srcu(), _and_ the CPU
executing synchronize_srcu() is guaranteed to have executed a full
memory barrier after seeing the values from all those release stores.
This is not quite the same thing but it ought to be just as good.

> I don't know of any SRCU code that relies on this, but it would be good to
> check. There used to (and might still) be RCU code relying on this, which
> is why this sentence was added to the header comment in the first place.

If there is code relying on that guarantee, it ought to work just as
well by relying on the modified guarantee.

Of course, there might be code relying on a guarantee that
srcu_read_unlock() executes a full memory barrier. This guarantee would
certainly no longer hold. But as I understand it, this guarantee was
never promised by the SRCU subsystem.

Alan