[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180703163948.GD391@tigerII.localdomain>
Date: Wed, 4 Jul 2018 01:39:48 +0900
From: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
To: Sergey Senozhatsky <sergey.senozhatsky@...il.com>
Cc: Tejun Heo <tj@...nel.org>,
Sergey Senozhatsky <sergey.senozhatsky.work@...il.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
Steven Rostedt <rostedt@...dmis.org>,
Petr Mladek <pmladek@...e.com>,
Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Dmitry Vyukov <dvyukov@...gle.com>,
linux-kernel@...r.kernel.org
Subject: Re: printk() from NMI backtrace can delay a lot
On (07/04/18 01:31), Sergey Senozhatsky wrote:
> it might be the case that we can do
>
> serial_driver_handle_irq()
> {
> spin_loc(uart_port->lock);
>
> .. TX / RX
>
> spin_unlock(uart_port->lock);
>
> tty_flip_buffer_push(uart_port->tty_port);
> }
>
> This should break this chain
>
> uart_port->lock -> pool->lock // -> sheduler/etc.
>
>
> Can we do it? What am I missing?
Hmm, and we actually have some serial drivers that do tty_filp_buffer_push()
outside of uart_port->lock. For instance, drivers/tty/serial/efm32-uart.c
irqreturn_t efm32_uart_rxirq().
-ss
Powered by blists - more mailing lists