Re: possible deadlock in console_unlock

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux PPP]     [Linux FS]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Linmodem]     [Device Mapper]     [Linux Kernel for ARM]

  Powered by Linux