From: Paul Fulghum <paulkf@microgate.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Russell King <rmk+lkml@arm.linux.org.uk>,
Tim_T_Murphy@Dell.com,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UP kernel
Date: Sat, 30 Oct 2004 19:26:23 -0500 [thread overview]
Message-ID: <1099182383.6000.99.camel@at2.pipehead.org> (raw)
In-Reply-To: <1099176190.25178.7.camel@localhost.localdomain>
On Sat, 2004-10-30 at 17:43, Alan Cox wrote:
> On Sad, 2004-10-30 at 00:40, Paul Fulghum wrote:
> > Would it make sense to do something like (in tty_io.c) the following?
>
> Not really because it can legally occur if you flip the low latency
> flag while a transaction is queued. It might work if you waited for
> scheduled work to complete in the flag changing.
I don't see how having flush_to_ldisc() queued
or already running (on another processor) negates
the prohibition on calling tty_flip_buffer_push()
with low_latency set in interrupt context.
The comments for tty_flip_buffer_push() state the
function should not be called in interrupt context
if low_latency is set (no exceptions are listed).
Meaning flush_to_ldisc() should only be called
in process context.
If flush_to_ldisc() is queued or already executing,
there is no protection against calling
flush_to_ldisc() again, directly in interrupt context.
TTY_DONT_FLIP is no protection, that is only set
in read_chan() of n_tty.c
If I'm missing something, please point it out.
--
Paul Fulghum
paulkf@microgate.com
next prev parent reply other threads:[~2004-10-31 0:26 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-29 19:55 [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UP kernel Tim_T_Murphy
2004-10-29 20:20 ` Russell King
2004-10-29 22:18 ` Paul Fulghum
2004-10-29 23:40 ` Paul Fulghum
2004-10-30 22:43 ` Alan Cox
2004-10-31 0:26 ` Paul Fulghum [this message]
2004-11-01 7:14 ` [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UPkernel Stuart MacDonald
2004-11-01 14:10 ` Paul Fulghum
2004-11-01 15:12 ` Stuart MacDonald
2004-11-01 23:02 ` Alan Cox
2004-11-02 0:18 ` Paul Fulghum
2004-10-29 21:08 ` [BUG][2.6.8.1] serial driver hangs SMP kernel, but not the UP kernel Paul Fulghum
-- strict thread matches above, loose matches on Subject: below --
2004-10-29 21:04 Tim_T_Murphy
2004-10-29 21:14 ` Russell King
2004-10-29 23:30 Tim_T_Murphy
2004-10-30 16:02 ` Russell King
2004-10-29 23:33 Tim_T_Murphy
2004-11-01 14:28 Tim_T_Murphy
2004-11-01 14:35 ` Russell King
2004-11-01 16:06 Tim_T_Murphy
2005-01-06 14:55 Tim_T_Murphy
2005-01-06 22:47 Tim_T_Murphy
2005-01-06 23:11 ` Alan Cox
2005-01-07 0:43 ` Paul Fulghum
2005-01-07 1:54 ` Alan Cox
2005-01-07 14:04 ` Paul Fulghum
2005-01-06 23:50 Tim_T_Murphy
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=1099182383.6000.99.camel@at2.pipehead.org \
--to=paulkf@microgate.com \
--cc=Tim_T_Murphy@Dell.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=rmk+lkml@arm.linux.org.uk \
/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.