linux-kernel - Re: [PATCH] usb: xhci: Prefer endpoint context dequeue pointer over stopped

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]

Date:	Tue, 15 Apr 2014 15:39:53 +0300
From:	Mathias Nyman <mathias.nyman@...ux.intel.com>
To:	Julius Werner <jwerner@...omium.org>
CC:	"Nyman, Mathias" <mathias.nyman@...el.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	Sarah Sharp <sarah.a.sharp@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Vincent Palatin <vpalatin@...omium.org>,
	Luigi Semenzato <semenzato@...omium.org>
Subject: Re: [PATCH] usb: xhci: Prefer endpoint context dequeue pointer over
 stopped_trb

On 04/03/2014 12:29 AM, Julius Werner wrote:
> Hi Mathias,
>
>> The patch looks fine.  Mathias is taking over for xHCI driver
>> maintainership in 3.15.  He's currently handling queuing bug fix patches
>> for 3.14 while I finish queueing feature patches for 3.15.  Mathias,
>> will you test and queue this up for 3.14?
>
> Did you pick this patch up anywhere yet or are there still issues with
> it? I just want to make sure it doesn't slip through the cracks.
> (Maybe I just didn't see it yet... are you still queueing patches in
> sarah/xhci.git or do you have your own repository somewhere?)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

I tried to apply this patch on top of 3.15-rc1, but it fails because of 
the streams support added to xhci_find_new_dequeue_state()

After some manual editing the interesting parts of 
xhci_find_new_dequeue_state() looks like this:

@@ -577,46 +568,57 @@ void xhci_find_new_dequeue_state(struct xhci_hcd 
*xhci,
         if (ep->ep_state & EP_HAS_STREAMS) {
                 struct xhci_stream_ctx *ctx =
                         &ep->stream_info->stream_ctx_array[stream_id];
-               state->new_cycle_state = 0x1 & 
le64_to_cpu(ctx->stream_ring);
+               hw_dequeue = le64_to_cpu(ctx->stream_ring);
         } else {
                 struct xhci_ep_ctx *ep_ctx
                         = xhci_get_ep_ctx(xhci, dev->out_ctx, ep_index);
-               state->new_cycle_state = 0x1 & le64_to_cpu(ep_ctx->deq);
+               hw_dequeue = le64_to_cpu(ep_ctx->deq);
         }

+       /* Find virtual address and segment of hardware dequeue pointer */
+       state->new_deq_seg = ep_ring->deq_seg;
+       state->new_deq_ptr = ep_ring->dequeue;
+       while (xhci_trb_virt_to_dma(state->new_deq_seg, state->new_deq_ptr)
+                       != (dma_addr_t)(hw_dequeue & ~0x1)) {
+               next_trb(xhci, ep_ring, &state->new_deq_seg,
+                                       &state->new_deq_ptr);
+               if (state->new_deq_ptr == ep_ring->dequeue) {
+                       WARN_ON(1);
+                       return;
+               }
+       }


But I'm still concerned about the dequeue pointer in the streams case. 
streams may be nested, we might be pointing at another stream context 
instead of the dequeue pointer.

Also the comparison of the dequeue pointers, using (hw_dequeue & ~0x1) 
might have some troubles with streams. Endpoint context TR dequeue 
pointer LO field has bits 3:1 reserved (probably zero) but stream 
context uses those bits. Would it make sense to use (hw_dequeue & ~0xf) 
here instead?

So there's still some work needed. Are you interested in re-working this 
to fit on top of 3.15-rc1 or should I add it to my todo list?

-Mathias



--
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/