Messages in this thread | | | Subject | Re: possible deadlock in console_unlock | From | Tetsuo Handa <> | Date | Thu, 7 Jun 2018 20:40:54 +0900 |
| |
On 2018/06/07 20:00, Petr Mladek wrote: >> --- >> >> drivers/tty/tty_buffer.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> 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)?
By the way, this reproducer is tricky. It needs to run like ./a.out followed by "while :; do fg; done" because it always stops by a signal.
| |