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: <20090506164141.55c8978c@lxorguk.ukuu.org.uk>
Date:	Wed, 6 May 2009 16:41:41 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	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

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

Stuff data into the chip and if need be maintain an internal buffer. One
of the problems with the serial stuff is that the buffering algorithms
you need to packetize serial streams without poor behaviour or overruns
are non trivial and the USB serial layer doesn't provide anything
remotely resembling sanity.

Secondly most USB serial drivers lie about their write room which causes
overruns.

What should happen is something like this

	foo_write_room()
	{
		if(no_urbs_left) return 0;
		if(one_urb_left) return bytes_in_urb_left;
		else return size_of_one_urb;
	}

	foo_write()
	{
		stuff bytes into urb
		if (urbs_left > 1 &&
		some_function_of_bytes_queued_and_speed())
			send_urb_now();
	}

In other words never lie in the write_room method. Try to send data as
early as possible, but don't queue data inefficiently when the port has
plenty left to send.

The rules for write_room are simple

	If you say you have space for X bytes you can't say you have room
	for less bytes unless those bytes have actually been written - no
	window shrinking so to speak.

If your write_room method works properly, and you fix the buffering logic
then the rest will work. Probably we need usb/serial/buffer.c which has a
generic implementation in then that can be used to replace the completely
bogus hacks in most of the drivers.

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