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: <20090506202821.GA12449@kroah.com>
Date:	Wed, 6 May 2009 13:28:21 -0700
From:	Greg KH <greg@...ah.com>
To:	Jason Wessel <jason.wessel@...driver.com>
Cc:	Oliver Neukum <oliver@...kum.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>, 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 03:24:33PM -0500, Jason Wessel wrote:
> 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.

Why not just make the upper bound of urbs very large?  We used to have
an unlimited number of in-flight urbs for some drivers until it was
pointed out that a simple:
	cat /dev/null > /dev/ttyUSB0
would cause a DoS :)

What happens if your upper bound is 400?  4000?  Will that work
properly?

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/