Quoting Tvrtko Ursulin (2018-10-15 13:58:06)
>
> On 12/10/2018 16:15, Chris Wilson wrote:
> > For convenience, we want to interchange intel_wait/rb_node and treat a
> > NULL rb_node as a NULL intel_wait and vice versa. Assert that the
> > rb_node is at offset 0 in the intel_wait to ensure this.
> >
> > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> > ---
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> > index 84bf8d827136..44f117612193 100644
> > --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> > +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> > @@ -342,6 +342,7 @@ static bool __intel_breadcrumbs_enable_irq(struct intel_breadcrumbs *b)
> >
> > static inline struct intel_wait *to_wait(struct rb_node *node)
> > {
> > + BUILD_BUG_ON(offsetof(struct intel_wait, node));
> > return rb_entry(node, struct intel_wait, node);
> > }
> >
> >
>
> I expected to see someone checking to_wait(...) for (non)-null but can't
> really spot it. Only potential candidate might be GEM_BUG_ON(b->irq_wait
> == wait) in __intel_breadrcumbs_finish, but that one could check it
> explicitly. Am I missing some?
It was actually chain_wakeup() that caught my eye. There we check the
rb_node is not NULL, and was thinking about whether that required that
intel_wait itself is not NULL (thinking along the lines of extracting it
from the container, but as it is returned by rb_next() there isn't
actually a dependency to worry about.)
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
