All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Timur Tabi <timur@freescale.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: How important is it that tty_write_room doesn't lie?
Date: Wed, 23 Feb 2011 12:29:15 -0800	[thread overview]
Message-ID: <20110223202915.GB9081@suse.de> (raw)
In-Reply-To: <4D656679.90907@freescale.com>

On Wed, Feb 23, 2011 at 01:56:41PM -0600, Timur Tabi wrote:
> Greg,
> 
> As you may remember, I have a combination console/tty driver that talks to a
> serial-like FIFO provided by our hypervisor.  Both tty_operations.write() and
> console.write() talk to the same FIFO for character output.
> 
> I've implemented a tty_operations.write_room() function that queries the
> hypervisor for amount of free space in the FIFO.  I've noticed a subtle bug in
> this function, and I was hoping for some advice on how to fix it.
> 
> I believe I might have a problem when the following events happen in this order:
> 
> 1) The TTY layer calls write_room() to determine the amount of free space in the
> FIFO.
> 
> 2) The *console* layer calls console.write() to write some data (e.g. the kernel
> interrupted the TTY layer and executed a printk)
> 
> 3) Control returns to the TTY layer, which calls tty_operations.write(),
> assuming that the number returned by the previous call to write_room() is still
> correct.
> 
> Because of the interjected console write, the FIFO no longer has a much room as
> write_room() said it does.  When the TTY layer calls tty_operations.write(), my
> driver returns a number smaller than the size of the buffer passed to (i.e. not
> all characters were written).  The TTY layer, not expecting this, loses data.

Um, the tty layer should not loose data, but it is hard, if not
impossible, to re-write from within the tty layer due to lots of
different issues (if the data came from within it's hard, if it came
from userspace, it should be fine.)

> Is my assessment of the situation correct?  If so, is there any way around this
> problem that doesn't require implementing *two* software FIFOs in the driver:
> one for the console interface, and one for the TTY interface?  If every driver
> needs a FIFO like this, wouldn't it be simpler for the TTY and console layers to
> provide their own FIFOs?  I feel like I'm missing something obvious.

I think that people don't normally hit this as the console code isn't
used as a tty and a console at the same time, right?

How big is your buffer in your FIFO?  Can you always just say you have a
smaller ammount in order to try to work around the tty layer trying to
send you a few extra bytes at times?

thanks,

greg k-h

  reply	other threads:[~2011-02-23 20:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-23 19:56 How important is it that tty_write_room doesn't lie? Timur Tabi
2011-02-23 20:29 ` Greg KH [this message]
2011-02-23 20:48   ` Timur Tabi
2011-02-23 22:57     ` Ted Ts'o
2011-02-24 12:34       ` Theodore Tso
2011-02-23 23:17     ` Greg KH
2011-02-24 11:29   ` Alan Cox

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=20110223202915.GB9081@suse.de \
    --to=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=timur@freescale.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.