netdev - Re: [PATCH] hso.c against 2.6.27-rc5 throttle/unthrottle to prevent loss of serial data

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:	Fri, 05 Sep 2008 15:30:00 +0200
From:	Denis Joseph Barrow <D.Barow@...ion.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	Linux USB kernel mailing list <linux-usb@...r.kernel.org>,
	Linux netdev Mailing list <netdev@...r.kernel.org>
Subject: Re: [PATCH]  hso.c against 2.6.27-rc5 throttle/unthrottle to prevent
 loss of serial data

Hi Alan,
You are very close to understanding me.
If my understanding of the n_tty.c code is correct it will
only start throttling when there is TTY_THRESHOLD_THROTTLE
i.e. 128 bytes left in the n_tty ring buffer this is a very low limit
for my driver. This means
that if I try to do a tty_flip_buffer_push of
of a tty buffer larger than 128 bytes when the threshold
is reached I will lose data. My urb buffers are 4k in
size 2 buffers of this size up to the tty layer in a row 
quickly I believe I'll lose data in the n_tty layer.

Alan Cox wrote:
> O> Alan you'll notice I'm calling tty_flip_buffer_push(tty)
>> i.e. flush_to_ldisc every 32 bytes as
>> TTY_THRESHOLD_THROTTLE in /drivers/char/n_tty.c is
>> only 128 bytes & I need to get unthrottled before
>> I lose characters it would be nice if the tty layer
>> could set the size of the throttle/unthrottle parameters
>> & the size of the n_tty ring buffer.
> 
> I don't really follow what you are trying to do here. You have two layers
> of buffering to consider
> 
>    Driver -> | tty buffer queue (64k) | n_tty - internal queue | user
> 
> 
> And it is when the internal queue gets full that we call throttle not
> when the 64K of tty buffering is full.
> 
> So you really shouldn't see a problem unless you have many Kbytes of USB
> requests floating around to consume all the buffering even after the tty
> is throttled.
> 
> As to the robustness - the USB tty code is generally pretty bad in this
> area so hso won't be any worse. Probably it is sufficient to keep an eye
> on what is in flight and when an URB completes don't just reissue it but
> reissue any others that didn't get posted due to errors.
> 
> The only other case you then have to trap is the nothing could be queued
> case which should never happen and I guess if you are passionate about
> robustness would need a timer.
> 
> Alan


-- 
best regards,
D.J. Barrow
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html