Compatibility with GCC < 4.7 and ATOMICS

[rc-matthew-l-weber]

selinux/libselinux/src/label_file.h

Line 355 in f6e7613

__atomic_load_n(&spec->regex_compiled, __ATOMIC_ACQUIRE);

Would an approach using sync's like the suggestion here be viable?
http:https://buildroot-busybox.2317881.n4.nabble.com/PATCH-docs-manual-gcc-4-4-is-the-lowest-we-are-known-to-work-with-tp200075p200254.html

[williamcroberts]

Well, albeit slower, the use of atomics there could be removed and the existing mutex (spec->regex_compiled) be used within the mutex. Then their are no atomics. Not sure how badly that would affct performance, but I would wager it won't be noticeable.

[stephensmalley]

Just using the mutex was deemed unacceptable for performance reasons by the Android team when the patch was first proposed that addressed the thread safety issues in selabel_lookup.
Not opposed to the use of syncs on older gcc.

[slightlyunconventional]

Normal (non-atomic) accesses to 'spec->regex_compiled' would have equivalent effects to today's code.

Atomic accesses would only be needed if you were trying to implement thread-safe algorithm without any locks. But you're not; you're just doing a first pass "should we even attempt to lock?" filter. In the current code, the pre-lock accesses to regex_compiled will race whether atomic or not; it's the mutex that ensures safety.

[stephensmalley]

Yes, I questioned the need for atomics in the original patch. At the time, the author of the patch said "I was thinking of that, but I figure I don't want to fix a multi threading issue by introducing a potential / even more subtle multi threading issue by relying on the compiler / architecture to do what I want. The atomics make it explicit that if compile_regex() returns success, that the regex is ready to be used, which isn't necessarily a guarantee that can be made across architectures without them."
If that's a bogus argument, then I'm open to a patch to get rid of it, but probably ought to include the original author on that as well.

[slightlyunconventional]

I'm very very skeptical (see in particular POSIX 4.12 "Memory Synchronization"), but as an incremental improvement I'll just address the build issue.

[slightlyunconventional]

I guess I'll submit to [email protected] too, but that list doesn't seem to have public archives so I wouldn't be able to include a link here.

0001-Fix-build-break-around-_atomic-with-GCC-4.7.patch.txt