891cffbd6b
Arjan reported a spike in the following bug pattern in v2.6.27: http://www.kerneloops.org/searchweek.php?search=lock_page which happens because hwclock started triggering warnings due to a (correct) might_sleep() check in the MM code. The warning occurs because hwclock uses this dubious sequence of code to run "atomic" code: static unsigned long atomic(const char *name, unsigned long (*op)(unsigned long), unsigned long arg) { unsigned long v; __asm__ volatile ("cli"); v = (*op)(arg); __asm__ volatile ("sti"); return v; } Then it pagefaults in that "atomic" section, triggering the warning. There is no way the kernel could provide "atomicity" in this path, a page fault is a cannot-continue machine event so the kernel has to wait for the page to be filled in. Even if it was just a minor fault we'd have to take locks and might have to spend quite a bit of time with interrupts disabled - not nice to irq latencies in general. So instead just enable interrupts in the pagefault path unconditionally if we come from user-space, and handle the fault. Also, while touching this code, unify some trivial parts of the x86 VM paths at the same time. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Arjan van de Ven <arjan@infradead.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> |
||
|---|---|---|
| .. | ||
| alpha | ||
| arm | ||
| avr32 | ||
| blackfin | ||
| cris | ||
| frv | ||
| h8300 | ||
| ia64 | ||
| m32r | ||
| m68k | ||
| m68knommu | ||
| mips | ||
| mn10300 | ||
| parisc | ||
| powerpc | ||
| s390 | ||
| sh | ||
| sparc | ||
| sparc64 | ||
| um | ||
| x86 | ||
| xtensa | ||
| .gitignore | ||
| Kconfig | ||