linux-kernel - Re: [PATCH 5/5] usb_debug: EXPERIMENTAL

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:	Wed, 6 May 2009 11:18:07 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jason Wessel <jason.wessel@...driver.com>
cc:	greg@...ah.com, <linux-usb@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 5/5] usb_debug: EXPERIMENTAL - poll hcd device to force
 writes

On Tue, 5 May 2009, Jason Wessel wrote:

> The problem that this patch tries to solve is that data is lost
> because there are too many outstanding transmit urb's.
> 
> The question is what is the right way to force the controller to catch
> up, and ideally let the kernel do some other things in the mean time?

What do standard serial port drivers do?

> This patch takes the route of forcibly polling the hcd device to drain
> the urb queue and initiate the bulk write call backs.
> 
> NOTE this patch is not signed off, it is a question of what is the
> right way to do this?

This patch is highly questionable.

Is the idea to force the HCD to search for completed URBs before the
host controller has issued a completion interrupt?  Wouldn't it be
better instead to use more URBs?

Besides, why should there be too many outstanding transmit URBs?  A
normal serial debugging port running at 115200 baud can transmit no
more than 12 bytes per ms.  You should be able to surpass that using
only three URBs!  In fact, if you buffer up to 8 bytes per URB then
with only two URBs you could send 64 bytes per ms, which is equivalent
to 640000 baud.  Do you really need to go more than (say) ten times
faster than that?

Even if people do agree this is a reasonable thing to do (which I
doubt), the poll_hcd_irq() code doesn't belong hidden away in
serial/usb_debug.c.  It belongs in core/hcd.c.

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/