On 2022/11/15 8:54, Andrew Morton wrote: > On Sat, 12 Nov 2022 20:15:37 +0800 Zhen Lei <thunder.leizhen@xxxxxxxxxx> wrote: > >> The function mem_dump_obj() can sometimes provide valuable debugging >> information, but it cannot be called in an interrupt context because >> spinlock vmap_area_lock has not been protected against IRQs. If the >> current task has held the lock before hard/soft interrupt handler calls >> mem_dump_obj(), simply abandoning the dump operation can avoid deadlock. >> That is, no deadlock occurs in extreme cases, and dump succeeds in most >> cases. >> >> ... >> >> --- a/mm/vmalloc.c >> +++ b/mm/vmalloc.c >> @@ -4034,6 +4034,9 @@ bool vmalloc_dump_obj(void *object) >> struct vm_struct *vm; >> void *objp = (void *)PAGE_ALIGN((unsigned long)object); >> >> + if (unlikely(spin_is_locked(&vmap_area_lock))) >> + return false; >> + >> vm = find_vm_area(objp); >> if (!vm) >> return false; > > Yes, but this will worsen the current uses of this function. Consider > the case where task A wants to call vmalloc_dump_obj() but task B holds > vmap_area_lock. No problem, task A will simply spin until task B is > done. > > But after this patch, task A's call to vmalloc_dump_obj() will return > without having done anything. Oh, right, this problem occurs when task A and task B run on two different cores. > > . > -- Regards, Zhen Lei
