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]

Message-ID: <20090507010634.52bef075@lxorguk.ukuu.org.uk>
Date:	Thu, 7 May 2009 01:06:34 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Oliver Neukum <oliver@...kum.org>,
	Jason Wessel <jason.wessel@...driver.com>, <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

>     Write routine:
> 	Copy bytes into the available URB buffers, submitting URBs as 
> 	they get filled.  At the end, if the next URB is partially full 
> 	then submit it only if NIF < P.

There are good known algorithms for this and essentially the logic is
about speed and time estimation. You don't need to queue a partially
filled URB until you reach the time point that the hardware is in danger
of having sent everything already queued. So under load once you've
stuffed 4K down the pipe you know at 38400 baud that you can relax for
quite some time.

You could even entirely decouple write() from sending URBs.

>     Completion routine:
> 	If the next URB to send is partially filled, submit it.
> 
>     write_room routine:
> 	Return the actual number of bytes remaining in the available 
> 	URBs, but no more than (N-P)*B.

Providing your URBs can be allocated to say 512 bytes an URB then it'll
work fine to simply return the bytes left in the last URB (max the bytes
in the last URB). The tty code will then end up going

	room ?
		512 bytes
		fire away
	room ? 
		512 bytes
		fire away
	room ?
		...

until you run short of space

> 
> How does that sound?  Converting \n to \r\n will add some complication 
> but not too much.  
> 
> Allocating URBs on the fly adds a lot of complication.  There has to be 
> a minimum number of pre-allocated URBs; otherwise write_room could 
> never return a positive value.  If you allocate additional URBs 
> later on, when would you free them?

write_room can allocate URBs I think (would need to be atomic allocations)

	write_room()
		if no_urbs && urbs_queued < max_queued
			allocate an urb
		return space_in_last_urb;


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