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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ