[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65e403d5-552c-4c29-93ab-cb9913003be5@I-love.SAKURA.ne.jp>
Date: Sun, 21 Jan 2024 20:34:44 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: Hillf Danton <hdanton@...a.com>
Cc: syzbot <syzbot+06fa1063cca8163ea541@...kaller.appspotmail.com>,
syzkaller-bugs@...glegroups.com,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Jiri Slaby <jirislaby@...nel.org>,
Andrew Morton
<akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
linux-serial <linux-serial@...r.kernel.org>
Subject: Re: [PATCH] tty: vt: check for atomic context in con_write()
On 2024/01/21 12:48, Hillf Danton wrote:
> On Sat, 20 Jan 2024 19:34:02 +0900 Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
>> syzbot is reporting sleep in atomic context, for gsmld_write() is calling
>> con_write() with spinlock held and IRQs disabled.
>
> ...
>
>> --- a/drivers/tty/vt/vt.c
>> +++ b/drivers/tty/vt/vt.c
>> @@ -2856,7 +2856,7 @@ static int do_con_write(struct tty_struct *tty, const u8 *buf, int count)
>> struct vt_notifier_param param;
>> bool rescan;
>>
>> - if (in_interrupt())
>> + if (in_interrupt() || irqs_disabled())
>> return count;
>>
>> console_lock();
>
> Given console_lock(), no sense could be made by calling do_con_write()
> with spin lock held at the first place, regardless irq.
The question was how to detect it. Since in_atomic() is not a reliable method for
detecting that a spin lock is held, this patch instead chose irqs_disabled(), for
gsmld_write() is using spin_lock_irqsave(&gsm->tx_lock, flags).
Powered by blists - more mailing lists