lkml.org 
[lkml]   [2021]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [syzbot] BUG: sleeping function called from invalid context in __might_resched
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

\
 
 \ /
  Last update: 2021-11-12 17:28    [W:0.053 / U:0.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site