From:   "Fabio M. De Francesco" <fmdefrancesco@gmail.com>
To:     Marco Elver <elver@google.com>
Cc:     gregkh@linuxfoundation.org, jirislaby@kernel.org,
        linux-kernel@vger.kernel.org, syzkaller-bugs@googlegroups.com,
        syzbot <syzbot+5f47a8cea6a12b77a876@syzkaller.appspotmail.com>
Subject: Re: [syzbot] BUG: sleeping function called from invalid context in __might_resched
Date:   Fri, 12 Nov 2021 17:05:14 +0100
Message-ID: <1805242.PYQNYDVmnG@localhost.localdomain>
In-Reply-To: <CANpmjNMg62oXEQpuSccZdv-cx9txy2TH_4FQphaLEpSQTqZ1cQ@mail.gmail.com>
References: <000000000000f43bb905d06c8b7f@google.com> <8755565.Ff9ToCiNAG@localhost.localdomain> <CANpmjNMg62oXEQpuSccZdv-cx9txy2TH_4FQphaLEpSQTqZ1cQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Friday, November 12, 2021 2:58:14 PM CET Marco Elver wrote:
> On Fri, 12 Nov 2021 at 13:22, Fabio M. De Francesco
> <fmdefrancesco@gmail.com> wrote:
> [...]
> > I think that this "BUG" is a false positive.
> >
> > In do_con_write(), Just before the call of console_lock() there is an
> > in_interrupt() check that, if it evaluates to true, makes this function 
to
> > return "count" and prevents the SAC bug.
> 
> It's not complaining about being in an interrupt, but rather
> interrupts disabled, i.e. still an atomic context.

Yes, still in an atomic context. 

Actually, I've never talked about being "in an interrupt", but I've just said 
that the in_interrupt() macro prevents to fall into the code that might 
sleep. 

Now I suppose that this is the place for in_atomic(). Isn't it?

I wrongly thought that in_interrupt() returns non-zero from any kind of 
atomic context.

Thanks,

Fabio

> > >  do_con_write+0x10f/0x1e40 drivers/tty/vt/vt.c:2908
> > >  con_write+0x21/0x40 drivers/tty/vt/vt.c:3295
> > >  n_hdlc_send_frames+0x24b/0x490 drivers/tty/n_hdlc.c:290
> > >  tty_wakeup+0xe1/0x120 drivers/tty/tty_io.c:534
> > >  __start_tty drivers/tty/tty_io.c:806 [inline]
> > >  __start_tty+0xfb/0x130 drivers/tty/tty_io.c:799
> > >  n_tty_ioctl_helper+0x299/0x2d0 drivers/tty/tty_ioctl.c:880
> 
>        ^^ n_tty_ioctl_helper() disabled interrupts via
> spin_lock_irq(&tty->flow.lock)
>