On Tue, Aug 14, 2018 at 2:02 PM Hollis Blanchard <hollis_blanchard@xxxxxxxxxx> wrote: > > On 08/13/2018 02:18 PM, Tom Cherry wrote: > > 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. > Well, since there are no objections to this patch, I am happy to have it > committed to fix the build problem. :-) I have applied this patch. Thanks! Nicolas _______________________________________________ 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.
