linux-kernel - Re: [V4.0.0-rc3] Xhci Regression: ERROR Transfer event TRB DMA ptr not part of current TD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1503110950470.1262-100000@iolanthe.rowland.org>
Date:	Wed, 11 Mar 2015 10:03:58 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	"Lu, Baolu" <baolu.lu@...ux.intel.com>
cc:	Mathias Nyman <mathias.nyman@...ux.intel.com>,
	Jörg Otte <jrg.otte@...il.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	USB list <linux-usb@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Mauro Carvalho Chehab <mchehab@....samsung.com>
Subject: Re: [V4.0.0-rc3] Xhci Regression: ERROR Transfer event TRB DMA ptr
 not part of current TD

On Wed, 11 Mar 2015, Lu, Baolu wrote:

> >> It's possible that there's something in usb core as well,
> >> but I think the following was what happened:
> >>
> >> 1. First a normal configure endpoint command is issued, it sets endpoint dequeue pointer
> >>     to xxx400 = start of ring segment
> >> 2. two urbs get queued -> two TDs put on endpoint ring.
> >> 3. xhci executes those, ring is in running (idle) state. sw dequeue at xxx430, No TDs queued.
> >>     Endpoint dequeue pointer is not written to the endpoint output context as the ring is still
> >>     in running state (even if idle, not advancing with no TDs queued) it still shows xxx400
> >> 4. -> something happends, xhci_endpoint_reset() is called, we do a new configure endpoint
> >>     to 'soft reset' the endpiont, but we copy the dequeue pointer from the old endpoint
> >>     output context to the configure endpoint input context, which re-initializes the old
> >>     dequeue xxx400 pointer to xhci hardware, and it starts executing the old TDs from the ring.
> 
> Is it possible to return an error message up to client driver? The 
> client driver then decides
> how to handle this kind of error. It, possibly, unlink all ongoing 
> transfers and ask host driver
> to soft reset this endpoint. When xhci_endpoint_reset is called, there 
> should be no ongoing
> transfers.

That doesn't seem to be the problem here.  Mathias is saying that all
the transfers have indeed completed, but when reconfiguring the
endpoint, the driver tells the controller that some transfers are still
active (because it stores a stale copy of the dequeue pointer).

But Mathias, what about the cycle bits in the TRBs?  Wouldn't they be
set to indicate that the OS now owns the TRBs?  This would cause the
endpoint to stop working, not cause the sort of error that Jörg saw.  
Or does the reconfigure command also store a stale copy of the Dequeue
Cycle State setting?

Alan Stern

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