mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Oliver Neukum <oneukum@suse.de>
Cc: Toby Gray <toby.gray@realvnc.com>,
	"Greg Kroah-Hartman" <gregkh@suse.de>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] USB: cdc-acm: Prevent data loss when filling tty buffer.
Date: Tue, 22 Mar 2011 11:07:08 +0000	[thread overview]
Message-ID: <20110322110708.642c568b@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <201103220907.42552.oneukum@suse.de>

On Tue, 22 Mar 2011 09:07:42 +0100
Oliver Neukum <oneukum@suse.de> wrote:

> Am Montag, 21. März 2011, 17:56:12 schrieb Alan Cox:
> > On Mon, 21 Mar 2011 15:52:25 +0000
> > Toby Gray <toby.gray@realvnc.com> wrote:
> > 
> > > When sending large quantities of data through a CDC ACM channel it is possible
> > > for data to be lost when attempting to copy the data to the tty buffer. This
> > > occurs due to the return value from tty_insert_flip_string not being checked.
> > 
> > For a tty that is normally the right thing to do - no flow control was
> > asserted and the internal 64K of buffering was overrun so discard.
> 
> But should we really randomly discard a part of a buffer?
> If this happens the better alternative approach would be to nuke all buffers
> we currently have.

If you have a stall on a PC eg a hard disk going through a fault sequence
and jamming up the CPU (as PATA can do so well) you don't want to discard
63K of perfectly good PPP frames just because you lost the following one.

It's also of course what the hardware itself does below us so the
behaviour isn't changing, we just provide a somewhat software extended
FIFO.

  reply	other threads:[~2011-03-22 11:06 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-21 15:52 Toby Gray
2011-03-21 16:56 ` Alan Cox
2011-03-21 17:58   ` Toby Gray
2011-03-22  8:07   ` Oliver Neukum
2011-03-22 11:07     ` Alan Cox [this message]
2011-03-21 18:04 ` [PATCH v2] " Toby Gray
2011-03-22 10:05   ` Johan Hovold
2011-03-22 10:35     ` Alan Cox
2011-03-22 11:34       ` Johan Hovold
2011-03-22 14:11     ` Toby Gray
2011-03-22 18:05       ` Alan Cox
2011-03-22  7:43 ` [PATCH] " Oliver Neukum
2011-03-23 12:15   ` Toby Gray

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110322110708.642c568b@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=oneukum@suse.de \
    --cc=toby.gray@realvnc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®