Messages in this thread | | | Date | Wed, 1 Oct 2003 08:55:51 +0100 | From | Jamie Lokier <> | Subject | Re: [PATCH] Mutilated form of Andi Kleen's AMD prefetch errata patch |
| |
Andi Kleen wrote: > Jamie Lokier <jamie@shareable.org> writes: > > It is easy enough to fix by making the fault handler not take > > mmap_sem if the fault's in the kernel address range. (With apologies > > to the folk running kernel mode userspace...) > > It won't work because kernel can cause user space faults > (think get_user). And handling these must be protected.
Are we mis-communicating? By "fault in the kernel address range", I mean that the faulting address is in that range, not where the instruction is located.
get_user faults are obviously not in the kernel address range (except when set_fs has been used, which is rare and not a problem here).
When __get_user faults in __is_prefetch, while decoding an instruction in kernel space, it is good for do_page_fault to take the short-cut I suggested, skip locks, and reach the exception table fixup. It will turn out to be a bad address, __is_prefetch will report that it isn't a prefetch, and carry on to bust_spinlocks(), oops etc.
When __get_user faults in __is_prefetch, while decoding a userspace instruction, then it won't take that short-cut because the (inner) faulting address won't be in the kernel address range. The normal vma lookup will take place, install a user page, and the userspace instruction is decoded just fine.
What have I missed?
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |