[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20160705175959.GW4650@linux.vnet.ibm.com>
Date: Tue, 5 Jul 2016 10:59:59 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Stephen Rothwell <sfr@...b.auug.org.au>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
intel-gfx@...ts.freedesktop.org, dri-devel@...ts.freedesktop.org,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: linux-next: build failure after merge of the tip tree (from the
drm-intel tree)
On Tue, Jul 05, 2016 at 10:25:12AM +0200, Peter Zijlstra wrote:
> On Tue, Jul 05, 2016 at 01:53:03PM +1000, Stephen Rothwell wrote:
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> > index d3502c0603e5..1f91f187b2a8 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3290,7 +3290,7 @@ i915_gem_retire_work_handler(struct work_struct *work)
> > * We do not need to do this test under locking as in the worst-case
> > * we queue the retire worker once too often.
> > */
> > - if (lockless_dereference(dev_priv->gt.awake))
> > + if (/*lockless_dereference*/(dev_priv->gt.awake))
> > queue_delayed_work(dev_priv->wq,
> > &dev_priv->gt.retire_work,
> > round_jiffies_up_relative(HZ));
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> > index f6de8dd567a2..2c1926418691 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -3095,7 +3095,7 @@ static void i915_hangcheck_elapsed(struct work_struct *work)
> > if (!i915.enable_hangcheck)
> > return;
> >
> > - if (!lockless_dereference(dev_priv->gt.awake))
> > + if (!/*lockless_dereference*/(dev_priv->gt.awake))
> > return;
> >
> > /* As enabling the GPU requires fairly extensive mmio access,
>
> Right, neither case appears to include a data dependency and thus
> lockless_dereference() seems misguided.
Agreed! At first glance, this code wants READ_ONCE() rather than
lockless_dereference().
Thanx, Paul
Powered by blists - more mailing lists