> Actually, it should bug more often. This function: > flush_user_cache_page_non_current() is very rarely called (which is > hopefully why you don't see an increase in bugs). However, this is a > kernel function ... if you call load_context() here, you'll get the user > protection IDs in the register and it will immediately fault when it > returns to the kernel. All it should be doing (which is what it > currently does) is to set up sr3 to allow the kernel to poke into a user > address space, which is the design of the function. As things stand, the call is fully inlined. Nothing can be poked into the user address space without the protection ID register being correctly set. The cache flushes can trigger a non-access tlb miss fault. At the moment, I can't see how this function could cause a protection ID fault. However, it still seems good practice to set cr8 consistently when the user context is changed. The kernel uses space register values of zero, so it shouldn't fault because of the change to sr3 and cr8 for non current. The values are restored before flush_user_cache_page_non_current() exits. Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
