lkml.org 
[lkml]   [2018]   [Jun]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: possible deadlock in console_unlock
On (06/07/18 20:40), Tetsuo Handa wrote:
> >> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
> >> index c996b6859c5e..71958ef6a831 100644
> >> --- a/drivers/tty/tty_buffer.c
> >> +++ b/drivers/tty/tty_buffer.c
> >> @@ -167,7 +167,8 @@ static struct tty_buffer *tty_buffer_alloc(struct tty_port *port, size_t size)
> >> have queued and recycle that ? */
> >> if (atomic_read(&port->buf.mem_used) > port->buf.mem_limit)
> >> return NULL;
> >> - p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
> >> + p = kmalloc(sizeof(struct tty_buffer) + 2 * size,
> >> + GFP_ATOMIC | __GFP_NOWARN);
> >> if (p == NULL)
> >> return NULL;
> >>
> >> ---
> >
> > This looks like the most simple solution for this particular problem.
> > I am just afraid that there are many other locations like this.
> >
> I haven't tried the reproducer with that change. But isn't __GFP_NOWARN
> ignored by fail_dump() (and thus printk() from fault injection still occurs)?

Thanks for the info. Need to check it [I didn't know that GFP_NOWARN
meant GFP_WARN_ME_SOMETIMES]. If this is the case then we have just one
option left - printk_safe contexts for TTY/UART locks.

-ss

\
 
 \ /
  Last update: 2018-06-07 16:03    [W:0.120 / U:0.248 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site