Re: why do we need vmalloc_sync_all?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:

> On Sun, Jun 14, 2015 at 7:47 PM, Andi Kleen <andi@xxxxxxxxxxxxxx> wrote:
> > Oleg Nesterov <oleg@xxxxxxxxxx> writes:
> >>
> >> But again, the kernel no longer does this? do_page_fault() does 
> >> vmalloc_fault() without notify_die(). If it fails, I do not see how/why a 
> >> modular DIE_OOPS handler could try to resolve this problem and trigger 
> >> another fault.
> >
> > The same problem can happen from NMI handlers or machine check handlers. It's 
> > not necessarily tied to page faults only.
> 
> AIUI, the point of the one and only vmalloc_sync_all call is to prevent 
> infinitely recursive faults when we call a notify_die callback.  The only thing 
> that it could realistically protect is module text or static non-per-cpu module 
> data, since that's the only thing that's reliably already in the init pgd.  I'm 
> with Oleg: I don't see how that can happen, since do_page_fault fixes up vmalloc 
> faults before it calls notify_die.

Yes, but what I meant is that it can happen if due to an unrelated kernel bug and 
unlucky timing we have installed this new handler just when that other unrelated 
kernel bug triggers: say a #GPF crash in kernel code.

In any case it should all be mooted with the removal of lazy PGD instantiation.

Thanks,

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]