Messages in this thread | | | Subject | Re: Question on KASAN calltrace record in RT | From | Mike Galbraith <> | Date | Wed, 14 Apr 2021 08:15:53 +0200 |
| |
On Wed, 2021-04-14 at 07:26 +0200, Dmitry Vyukov wrote: > On Wed, Apr 14, 2021 at 6:00 AM Mike Galbraith <efault@gmx.de> wrote: > > > [ 0.692437] BUG: sleeping function called from invalid context at kernel/locking/rtmutex.c:943 > > [ 0.692439] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0 > > [ 0.692442] Preemption disabled at: > > [ 0.692443] [<ffffffff811a1510>] on_each_cpu_cond_mask+0x30/0xb0 > > [ 0.692451] CPU: 5 PID: 1 Comm: swapper/0 Not tainted 5.12.0.g2afefec-tip-rt #5 > > [ 0.692454] Hardware name: MEDION MS-7848/MS-7848, BIOS M7848W08.20C 09/23/2013 > > [ 0.692456] Call Trace: > > [ 0.692458] ? on_each_cpu_cond_mask+0x30/0xb0 > > [ 0.692462] dump_stack+0x8a/0xb5 > > [ 0.692467] ___might_sleep.cold+0xfe/0x112 > > [ 0.692471] rt_spin_lock+0x1c/0x60 > > HI Mike, > > If freeing pages from smp_call_function is not OK, then perhaps we > need just to collect the objects to be freed to the task/CPU that > executes kasan_quarantine_remove_cache and it will free them (we know > it can free objects).
Yeah, RT will have to shove freeing into preemptible context.
> > > > [ 15.428008] ================================================================== > > [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0 > > This looks like a genuine kernel bug on first glance. I think it needs > to be fixed rather than ignored.
I figured KASAN probably knew what it was talking about, I just wanted it to either go find something shiny or leave lockdep the heck alone.
-Mike
| |