From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ben Widawsky <ben@bwidawsk.net>
Subject: Re: [PATCH 3/3] drm/i915: close rps work vs. rps
	disable races
Date: Sun, 4 Sep 2011 19:50:08 +0000
Message-ID: <20110904195008.GA17304@cloud01>
References: <20110904084953.16cd10a2@bwidawsk.net>
	<1315150502-12537-1-git-send-email-daniel.vetter@ffwll.ch>
	<1315150502-12537-4-git-send-email-daniel.vetter@ffwll.ch>
	<20110904172330.GA16313@cloud01>
	<20110904191723.GA2799@phenom.ffwll.local>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org>
Received: from cloud01.chad-versace.us (184-106-247-128.static.cloud-ips.com
	[184.106.247.128])
	by gabe.freedesktop.org (Postfix) with ESMTP id 36B2DA0DED
	for <intel-gfx@lists.freedesktop.org>;
	Sun,  4 Sep 2011 12:46:52 -0700 (PDT)
Content-Disposition: inline
In-Reply-To: <20110904191723.GA2799@phenom.ffwll.local>
List-Unsubscribe: <http://lists.freedesktop.org/mailman/options/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=unsubscribe>
List-Archive: <http://lists.freedesktop.org/archives/intel-gfx>
List-Post: <mailto:intel-gfx@lists.freedesktop.org>
List-Help: <mailto:intel-gfx-request@lists.freedesktop.org?subject=help>
List-Subscribe: <http://lists.freedesktop.org/mailman/listinfo/intel-gfx>,
	<mailto:intel-gfx-request@lists.freedesktop.org?subject=subscribe>
Sender: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
Errors-To: intel-gfx-bounces+gcfxdi-intel-gfx=m.gmane.org@lists.freedesktop.org
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, intel-gfx@lists.freedesktop.org
List-Id: intel-gfx@lists.freedesktop.org

On Sun, Sep 04, 2011 at 09:17:24PM +0200, Daniel Vetter wrote:
> > >  	spin_lock_irq(&dev_priv->rps_lock);
> > >  	dev_priv->pm_iir = 0;
> > > +	I915_WRITE(GEN6_PMIER, 0);
> > >  	spin_unlock_irq(&dev_priv->rps_lock);
> > >  
> > >  	I915_WRITE(GEN6_PMIIR, I915_READ(GEN6_PMIIR));
> > I'm not sure this actually fixes a problem. The existing code:
> > 1. disables all interrupts (no more can occur).
> > 2. sets pm_iir to 0 safe in rps lock
> > <workqueues can run at this point, but IMR has no effect with IER = 0>
> > 
> > I think you should do the cancel work sync somewhere in the code before
> > module unload (to be correct). I just don't think this fixes a race.
> 
> Well, we definitely need the cancel_work_sync in the unload path
> somewhere. I prefer it in the rps disable function. In the context of the
> other patches my patch description is a bit lousy because I've really only
> wanted to fix the unload race (and the PMIMR inconsistency) with this
> patch.
> 
> -Daniel

I still fail to see the inconsitency. The value of PMR no longer matters once
IER is cleared. What the wq or irq handler does after this point should
be fine so long as everything is setup up properly at enable time. This
is a minor detail.

So I would rework some of your comments a bit, and I also think it's
about time we create a central place to cancel workqueue items. Mostly
because I think this patch is subject to a deadlock with struct_mutex
(you're holding it when you call gen6_disable_rps(), but you're doing
cancel_work_sync on a workqueue which attempts to acquire struct_mutex.

Ben