Giter VIP home page Giter VIP logo

Comments (6)

williamcroberts avatar williamcroberts commented on August 26, 2024

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.

from selinux.

stephensmalley avatar stephensmalley commented on August 26, 2024

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.

from selinux.

slightlyunconventional avatar slightlyunconventional commented on August 26, 2024

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.

from selinux.

stephensmalley avatar stephensmalley commented on August 26, 2024

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.

from selinux.

slightlyunconventional avatar slightlyunconventional commented on August 26, 2024

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.

from selinux.

slightlyunconventional avatar slightlyunconventional commented on August 26, 2024

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

from selinux.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.