On Mon, Jun 22, 2015 at 02:19:51PM -0700, Jesse Barnes wrote:
> On 06/17/2015 08:10 AM, Daniel Vetter wrote:
> > On Wed, Jun 17, 2015 at 05:28:20PM +0300, Jani Nikula wrote:
> >> On Wed, 17 Jun 2015, Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> wrote:
> >>> Here's an idea I want to float to see if anyone has a better idea.
> >>
> >> I'll give it some thought, but it pains me that things like this make it
> >> harder for source code cross referencers and even grep to find what you
> >> you're looking for.
> >
> > The minimal thing we've tossed around on irc (and we only need minimal
> > since there's just a few places that need the raw flags field) is to
> > hardcode the offsets and check them at runtime ...
>
> This one scares me a lot too; is there a thread on the memory ordering
> macros somewhere I can look at? The ordering constraints on x86 are
> pretty specific... if we need to annotate things in the code somehow
> that could be a plus (generally every *mb() should have a fat comment
> explaining the issue), but this seems like overkill at first glance.
This isn't about memory ordering at all but trying to implement
ACCESS_ONCE (which is only enforcing that gcc doesn't re-load a value and
end up with inconsistent control flow). Unfortunately ACCESS_ONCE doesn't
work on bitfield. Code example would be:
if (ACCESS_ONCE(obj->active)) {
/* complicated slowpath */
}
return;
Afaiui without the ACCESS_ONCE gcc might be allowed to re-load obj->active
and if we're really unluck it will only partiall execute the slowpath
since it decided to reload obj->active and it changed meanwhile. Or some
other really ugly thing.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
