Date: Tue, 19 Mar 2013 11:27:14 -0400 (EDT)
From: Alan Stern <stern@rowland.harvard.edu>
To: Ben Hutchings <ben@decadent.org.uk>
cc: stable@vger.kernel.org, <akpm@linux-foundation.org>,
        Joseph Salisbury <joseph.salisbury@canonical.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        LKML <linux-kernel@vger.kernel.org>
Subject: Re: [ 45/82] USB: EHCI: dont check DMA values in QH overlays
In-Reply-To: <1363662540.3937.366.camel@deadeye.wl.decadent.org.uk>
Message-ID: <Pine.LNX.4.44L0.1303191125100.15684-100000@netrider.rowland.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2114
Lines: 47

On Tue, 19 Mar 2013, Ben Hutchings wrote:

> On Mon, 2013-03-18 at 04:22 +0000, Ben Hutchings wrote:
> > 3.2-stable review patch.  If anyone has any objections, please let me know.
> > 
> > ------------------
> > 
> > From: Alan Stern <stern@rowland.harvard.edu>
> > 
> > commit feca7746d5d9e84b105a613b7f3b6ad00d327372 upstream.
> > 
> > This patch (as1661) fixes a rather obscure bug in ehci-hcd.  In a
> > couple of places, the driver compares the DMA address stored in a QH's
> > overlay region with the address of a particular qTD, in order to see
> > whether that qTD is the one currently being processed by the hardware.
> > (If it is then the status in the QH's overlay region is more
> > up-to-date than the status in the qTD, and if it isn't then the
> > overlay's value needs to be adjusted when the QH is added back to the
> > active schedule.)
> > 
> > However, DMA address in the overlay region isn't always valid.  It
> > sometimes will contain a stale value, which may happen by coincidence
> > to be equal to a qTD's DMA address.  Instead of checking the DMA
> > address, we should check whether the overlay region is active and
> > valid.  The patch tests the ACTIVE bit in the overlay, and clears this
> > bit when the overlay becomes invalid (which happens when the
> > currently-executing URB is unlinked).
> > 
> > This is the second part of a fix for the regression reported at:
> > 
> > 	https://bugs.launchpad.net/bugs/1088733
> 
> Alan, the first part (commit 6402c796d3b4 aka as1660) didn't apply and I
> couldn't see how to adapt it for 3.2.  Does this second part have any
> value without the first?  Or, if you could provide a backport of the
> first part, that would be very much appreciated.

Without the first part, the second part can actually be dangerous.  
Under the circumstances, I think it is best to apply neither.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/