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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090506152521.GA4603@kroah.com>
Date:	Wed, 6 May 2009 08:25:21 -0700
From:	Greg KH <greg@...ah.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Jason Wessel <jason.wessel@...driver.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 Wed, May 06, 2009 at 11:18:07AM -0400, Alan Stern wrote:
> 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?

Not this :)

They use the proper flow control hooks that the tty layer provides.

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

I agree.

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

Yeah, something seems wrong here.

Jason, why is this really needed?  With your ring buffer, you shouldn't
need this at all anymore.

Or if you do, just bump up the number outstanding urbs that are
possible.  Or the urb buffer size.

This patch isn't acceptable as-is.

thanks,

greg k-h
--
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/