linux-kernel - Re: uart : lost characters when system is busy

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] [day] [month] [year] [list]

Message-ID: <20110610123541.7d93a4fc@lxorguk.ukuu.org.uk>
Date:	Fri, 10 Jun 2011 12:35:41 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Matthieu CASTET <matthieu.castet@...rot.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-serial@...r.kernel.org" <linux-serial@...r.kernel.org>
Subject: Re: uart : lost characters when system is busy

> Also I believe some virtual usb uart (3G dongle, cdc-acm) that use higher rate
> (more than 10 Mbps)  will have the same problem. They will fill the buffer very
> quickly.

PPP doesn't use throttling so those dongles which are use modem emulation
will flow control at the IP level which is probably better anyway.

> For example the "USB: cdc-acm: Prevent loss of data when filling tty buffer"
> patch may be changed to something like :
> 
>     /* throttle device if requested by tty */
>     spin_lock_irqsave(&acm->read_lock, flags);
>     acm->throttled = acm->throttle_req;
>     if (!acm->throttled && !acm->susp_count && !tty_is_throttled()) {
>         spin_unlock_irqrestore(&acm->read_lock, flags);
>         acm_submit_read_urb(acm, rb->index, GFP_ATOMIC);
>     } else {
>         spin_unlock_irqrestore(&acm->read_lock, flags);
>     }

Except this now races the handling in the throttle/unthrottle events. In
particular you could have an unthrottle queued to occur such that by the
time it occurs we've throttled again, plus the ldisc may be quite slack
in signalling it to the tty layer.

For that example a second approach would be to provide

static int tty_buffer_room(struct tty *tty)
{
	return 65536 - tty->buf.memory_used;
}

and you could then buffer against the queue size, which is easy to
monitor in IRQ state, but would mean that you'd need to be sure that you
always had some buffer posted or some way to recover from the no buffers
case (eg adding

	if (tty-ops->buffer_free)
		tty->ops->buffer_free(tty)

to tty_buffer_free())

At that point it is throttling against the queue that is handled in
interrupt space.

Care to prototype those bits in your tree and see if it sorts your use
case ?

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/