Messages in this thread | | | Date | Fri, 12 Nov 2021 17:27:51 +0100 | From | Marco Elver <> | Subject | Re: [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
| |