[Bug 265974] SMR has several missing barriers
- In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 265974] SMR has several missing barriers"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 26 Aug 2022 21:40:19 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265974 --- Comment #6 from Pierre Habouzit <pierre@habouzit.net> --- (In reply to Mark Johnston from comment #4) > The suggested patch adds two barriers to smr_poll_scan() and none to smr_poll(), is that intentional? Yes, I cover this in my (2) paragraph: > 2. similarly smr_poll_scan() needs a full barrier after the scan _before_ it updates the global rd_seq, this is about serializing the fast path of smr_poll with CPUs that weren't in a critical section (while the one on entry of smr_poll() is about synchronizing with the CPUs inside an active SMR critical section and was demonstrated in (1)). fundamentally the first barrier is about sequencing the "scan" operation with CPUs actively inside an active SMR section (and basically pairs with their smr_enter()), but the second barrier is about all the sections we ignored because they weren't active and pairs with the last `smr_leave()` that that core executed. Writing the litmus test to exhibit this problem was more work than I was willing to put in. For full disclosure I am the author of XNU's smr.[hc] and am reporting this bug as a courtesy given that FreeBSD was the inspiration. In XNU I'm definitely going to put both barriers (the current open source drop doesn't have it but as I was reasoning through this code recently I convinced myself they were needed). -- You are receiving this mail because: You are the assignee for the bug.