From: Paul Fulghum <paulkf@microgate.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: "Russell King" <rmk+lkml@arm.linux.org.uk>,
"Roland Caßebohm" <roland.cassebohm@VisionSystems.de>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: Serial driver hangs
Date: Thu, 30 Sep 2004 19:47:56 -0500 [thread overview]
Message-ID: <1096591676.6000.25.camel@at2.pipehead.org> (raw)
In-Reply-To: <1096579503.1938.166.camel@deimos.microgate.com>
On Thu, 2004-09-30 at 16:25, Paul Fulghum wrote:
> > flush_to_ldisc was ok, then someone added the low latency
> > flag. In the current 2.6.9rc3 patch flush_to_ldisc honours
> > TTY_DONT_FLIP also
>
> In the cases I described the low latency flag
> does not come into play because flush_to_ldisc()
> is called directly instead of
> through tty_flip_buffer_push().
>
> TTY_DONT_FLIP is only set in read_chan().
> If read_chan() is not running, TTY_DONT_FLIP is not
> set and does not prevent buffers from flipping
> if the ISR calls flush_to_ldisc() directly
> while ldisc->receive_buf() is running.
>
> The answer seems to be: don't call
> flush_to_ldisc directly like the current
> serial driver does.
I've looked at this more on 2.6
If a driver only calls tty_flip_buffer_push(),
with low_latency cleared, it is still possible for
flush_to_ldisc() to run concurrently on SMP machines.
* IRQ on proc 0, flush_to_ldisc work queued for events/0
* events/0 processes work item:
1) work->pending cleared (work can now be queued again)
2) work function runs on proc 0
While work function is running on proc 0:
* IRQ on proc 1, flush_to_ldisc work queued for events/1
* events/1 processes work item:
1) work->pending cleared (work can now be queued again)
2) work function runs on proc 1
flush_to_ldisc/ldisc->receive_buf do not set TTY_DONT_FLIP
and I see no other mechanism to serialize flush_to_ldisc
That means the buffers can flip while running in
ldisc->receive_buf() which reads from the buffers.
This is contrived, and timing may prevent
this from actually occurring in practice, but it
seems to indicate a hole that needs to be plugged.
I wrong in my reading of the code?
--
Paul Fulghum
paulkf@microgate.com
next prev parent reply other threads:[~2004-10-01 0:50 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-28 15:34 Serial driver hangs Roland Caßebohm
2004-09-28 21:10 ` Paul Fulghum
2004-09-28 21:16 ` Russell King
2004-09-28 23:03 ` Paul Fulghum
2004-09-28 22:12 ` Alan Cox
2004-09-29 1:12 ` Paul Fulghum
2004-09-29 13:09 ` Roland Caßebohm
2004-09-29 13:17 ` Paul Fulghum
2004-09-29 14:07 ` Roland Caßebohm
2004-09-29 14:25 ` Paul Fulghum
2004-09-30 16:16 ` Roland Caßebohm
2004-09-30 19:09 ` Paul Fulghum
2004-09-30 18:34 ` Alan Cox
2004-09-30 19:51 ` Paul Fulghum
2004-09-30 19:59 ` Russell King
2004-09-30 20:05 ` Paul Fulghum
2004-09-30 20:30 ` Paul Fulghum
2004-09-30 20:10 ` Alan Cox
2004-09-30 21:25 ` Paul Fulghum
2004-10-01 0:47 ` Paul Fulghum [this message]
2004-10-01 15:22 ` Roland Caßebohm
2004-10-01 16:06 ` Paul Fulghum
2004-10-01 20:13 ` Stuart MacDonald
2004-10-01 20:36 ` Paul Fulghum
2004-09-29 14:13 ` Paul Fulghum
2004-10-01 15:25 ` Roland Caßebohm
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=1096591676.6000.25.camel@at2.pipehead.org \
--to=paulkf@microgate.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@arm.linux.org.uk \
--cc=roland.cassebohm@VisionSystems.de \
/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.