On Wed, Jun 16, 2021 at 02:19:49PM +1000, Nicholas Piggin wrote:
Excerpts from Andy Lutomirski's message of June 16, 2021 1:21 pm:
quoted
membarrier() needs a barrier after any CPU changes mm. There is currently
a comment explaining why this barrier probably exists in all cases. This
is very fragile -- any change to the relevant parts of the scheduler
might get rid of these barriers, and it's not really clear to me that
the barrier actually exists in all necessary cases.
The comments and barriers in the mmdrop() hunks? I don't see what is
fragile or maybe-buggy about this. The barrier definitely exists.
And any change can change anything, that doesn't make it fragile. My
lazy tlb refcounting change avoids the mmdrop in some cases, but it
replaces it with smp_mb for example.
I'm with Nick again, on this. You're adding extra barriers for no
discernible reason, that's not generally encouraged, seeing how extra
barriers is extra slow.
Both mmdrop() itself, as well as the callsite have comments saying how
membarrier relies on the implied barrier, what's fragile about that?