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: <4A01F201.3020406@windriver.com>
Date:	Wed, 06 May 2009 15:24:33 -0500
From:	Jason Wessel <jason.wessel@...driver.com>
To:	Oliver Neukum <oliver@...kum.org>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, 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

Oliver Neukum wrote:
> Am Mittwoch, 6. Mai 2009 21:24:56 schrieb Alan Stern:
>   
>> Converting \n to \r\n will add some complication
>> but not too much.
>>     

This conversion is done in the tty layer "the high level".  By the time
the low level driver gets it character stream via the tty call backs
everything is already processed.

>> 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
>>     
>
> Why? You can always calculate with the number of URBs you'd
> allocate as a maximum.
>
>   

In the scheme originally posted with the cap of 42 "in flight" urbs, I
had not seen it run out while using the standard tty driver.   The tty
driver really is not really the key problem I was after with the forced
poll patch.

The console driver is where all the character loss is going on.  There
is no tty interface, and there are no "write room" checks.  The present
kernel interface to the uart console callbacks is synchronous.

Here is a back trace to illustrate the typical 8250 driver.

#0  serial8250_console_putchar at drivers/serial/8250.c:2690
#1  0xc03977d4 in uart_console_write at drivers/serial/serial_core.c:1810
#2  0xc039cbb8 in serial8250_console_write at drivers/serial/8250.c:2729
#3  0xc022802b in __call_console_drivers at kernel/printk.c:419
#4  0xc022808b in _call_console_drivers at kernel/printk.c:449
#5  0xc0228269 in call_console_drivers at kernel/printk.c:499
#6  release_console_sem at kernel/printk.c:1020
#7  0xc022872b in vprintk at kernel/printk.c:749
#8  0xc022889b in printk at kernel/printk.c:582

Doing enough printk's such as in register_console() will cause loss
because you run out of URBs unless you can force them to complete.

Is there a valid way we can force the urbs to complete short of "polling
the heck out of the host controller" or have a synchronous interface in
the case of the console write call back?

There are two different call paths into the USB serial drivers just like
the uart drivers.  One is for the tty callbacks and other is for the
console call backs.  I am most interested how to fix the console writes
(with respect to the original experimental patch).

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