On Mon, Aug 13, 2018 at 1:49 PM Hollis Blanchard <hollis_blanchard@xxxxxxxxxx> wrote: > > On 08/13/2018 01:45 PM, Tom Cherry wrote: > > On Mon, Aug 13, 2018 at 12:43 PM Hollis Blanchard > > <hollis_blanchard@xxxxxxxxxx> wrote: > >> The __atomic_* GCC primitives were introduced in GCC 4.7, but Red Hat > >> Enterprise Linux 6.x (for example) provides GCC 4.4. Tweak the current code to > >> use the (most conservative) __sync_synchronize() primitive provided by those > >> older GCC versions. > >> > >> Fixes https://github.com/SELinuxProject/selinux/issues/97 > >> > >> (Really, no __atomic or __sync operations are needed here at all, since POSIX > >> 4.12 "Memory Synchronization" says pthread_mutex_lock() and > >> pthread_mutex_unlock() "synchronize memory with respect to other threads"...) > > That section means that pthread_mutex_lock() and > > pthread_mutex_unlock() will perform an acquire / release operation > > respectively, so if you're guarding shared data with them, you don't > > need additional memory synchronization. > > > > In this case however, the fast path does not call pthread_mutex_lock() > > and thus there is no acquire operation. pthread_mutex_unlock() will > > perform a release operation in the thread that actually compiled the > > regex (so technically, we don't actually need the __atomic_store_n), > > but we still need an acquire operation on the fast path, which is why > > we need the atomic. > You really don't. The fast path access will race whether it's "atomic" > or not. Luckily, it doesn't matter if you get false positives or false > negatives, because it will be checked for real under the mutex. It does matter if you get false positives. False positives do not lock the mutex and return immediately that the regex has been compiled. Without the acquire operation, it's possible that spec->regex_compiled is true, but the value of spec->regex hasn't been made visible to the processor executing this thread, which results in an error. Keep in mind, this code runs on ARM as well as x86, and ARM doesn't guarantee strong memory ordering. > > Hollis Blanchard > Mentor Graphics Emulation Division > _______________________________________________ Selinux mailing list Selinux@xxxxxxxxxxxxx To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx. To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
