Date:   Fri, 12 Nov 2021 17:27:51 +0100
From:   Marco Elver <elver@google.com>
To:     "Fabio M. De Francesco" <fmdefrancesco@gmail.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
Message-ID: <YY6WB9wMx/0VaqDx@elver.google.com>
References: <000000000000f43bb905d06c8b7f@google.com>
 <8755565.Ff9ToCiNAG@localhost.localdomain>
 <CANpmjNMg62oXEQpuSccZdv-cx9txy2TH_4FQphaLEpSQTqZ1cQ@mail.gmail.com>
 <1805242.PYQNYDVmnG@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1805242.PYQNYDVmnG@localhost.localdomain>
User-Agent: Mutt/2.0.5 (2021-01-21)
Precedence: bulk

On Fri, Nov 12, 2021 at 05:05PM +0100, Fabio M. De Francesco wrote:
> 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?

in_atomic() probably won't do:

	/*
	 * Are we running in atomic context?  WARNING: this macro cannot
	 * always detect atomic context; in particular, it cannot know about
	 * held spinlocks in non-preemptible kernels.  Thus it should not be
	 * used in the general case to determine whether sleeping is possible.
	 * Do not use in_atomic() in driver code.
	 */
	#define in_atomic()	(preempt_count() != 0)

In particular, it doesn't detect if interrupts are disabled.

My guess is that in this case '!preemptible()' could work:

	#define preemptible()	(preempt_count() == 0 && !irqs_disabled())

But still am not entirely sure.

Thanks,
-- Marco