[Intel-gfx] [PATCH] Antigcc bitfield bikeshed

[Daniel Vetter]

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 at chris-wilson.co.uk> 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