From: Grant Edwards <grant.b.edwards@gmail.com>
To: linux-serial@vger.kernel.org
Subject: Re: tty_flip_buffer() from atomic context when low_latency==1
Date: Fri, 19 Aug 2011 21:24:48 +0000 (UTC) [thread overview]
Message-ID: <j2mkav$bat$1@dough.gmane.org> (raw)
In-Reply-To: 20110819220644.3166083d@lxorguk.ukuu.org.uk
On 2011-08-19, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Fri, 19 Aug 2011 20:44:26 +0000 (UTC)
> Grant Edwards <grant.b.edwards@gmail.com> wrote:
>
>> On 2011-08-19, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>>
>> >> But, many drivers appear to call tty_flip_buffer_push() from an atomic
>> >> context. If that is done with tty->low_latency==1 it turns into a call
>> >> to flush_to_ldisc(), which then calls disc->ops->receive_buf(), which
>> >> must not be called from an atomic context.
>> >
>> > It's covered under "So don't do that then".
>>
>> I don't do that, and wasn't asking if I should.
>>
>> My point was that most of the drivers in the linux kernels sources
>> _do_ appear to do that, and I don't see how they avoid problems.
>>
>> For exaple, 8250.c calls tty_flip_buffer_push() from receive_chars(),
>> calld from serial8250_handle_port(), called from
>> serial8250_interrupt().
>>
>> How are problems avoided when tty->low_latency is set?
>>
>> Is tty->low_latency never allowed to be set for the 8250 driver?
>
> Several drivers certainly allow someone with superuser privileges to
> misconfigure them.
You don't need to be root to set the low_latency flag on a tty device.
Normal users are allowed to do that:
./linux/serial_core.h:361
#define UPF_USR_MASK ((__force upf_t) (UPF_SPD_MASK|UPF_LOW_LATENCY))
> I've never worried about chasing all those down.
To me, it looks like anybody with permission for the serial port can
set the low latency flag and potentially cause a "scheduling while
atomic" crash.
I've gotten it to happen with other drivers that call
tty_flip_buffer_push() with tty->low_latency==1, but haven't been able
to make it happen with the 8250 driver -- I don't know why. I've
verified that a normal user doing "setserial /dev/ttyS0 low_latency"
sets the low_latency flag, and it's 1 immediately before and after the
call to tty_flip_buffer_push(). Maybe I just haven't run it long
enough...
> It might actually be worth supporting a tty->low_latency mode which
> uses a tty layer private workqueue that is set to real time priority
> rather than the system work queue.
I don't understand why the low_latency flag even exists when setting
it apparently breaks most all of the serial drivers.
--
Grant Edwards grant.b.edwards Yow! You should all JUMP
at UP AND DOWN for TWO HOURS
gmail.com while I decide on a NEW
CAREER!!
next prev parent reply other threads:[~2011-08-19 21:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-19 19:43 tty_flip_buffer() from atomic context when low_latency==1 Grant Edwards
2011-08-19 20:24 ` Alan Cox
2011-08-19 20:44 ` Grant Edwards
2011-08-19 21:06 ` Alan Cox
2011-08-19 21:24 ` Grant Edwards [this message]
2011-08-19 21:31 ` Alan Cox
2011-08-19 21:52 ` Grant Edwards
2011-08-19 22:53 ` 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='j2mkav$bat$1@dough.gmane.org' \
--to=grant.b.edwards@gmail.com \
--cc=linux-serial@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).