> Honestly, I can't decide whether to apply this. It really should never > happen in the kernel, since the kernel can guarantee it won't get the > access rights failure (highest privilege level, and can set %sr and > %protid to whatever it wants.) I believe this change should be applied because we enable P and the hardware can generate the exception. Yes, it should never happen, but the coding to prevent this occurring is very subtle. > It really genuinely is a bug that probably should panic the kernel. The > only precedent I can easily see is x86 fixing up a bad iret with a > general protection fault, which is more or less analogous to code 27 > here. I don't think we have enough information here. A panic doesn't tell us what we need to know... > On the other hand, taking the exception on a userspace access really > isn't all that critical, and there's fundamentally little reason for the > kernel not to SIGSEGV the process, and continue... Agreed, especially in a __put_user operation. > (btw, I've instrumented my do_sys_poll with a pile of assertions that > %cr8 << 1 == %sr3 == current->mm.context... let's see if where we're > getting corrupted is deterministic, though, I would guess that it won't > be.) Having looked at the code a bit, I have come to the conclusion that the problem is not with the sr3 value. We have a one-to-one mapping between space register values and protection IDs. TLB entries get inserted using the space register value for the protection ID (see entry.S). So, I think we have to have inconsistent values in cr8 and sr3. I think the bug may be in flush_user_cache_page_non_current. It hijacks sr3 temporarily and I don't think cr8 is updated when this is done. The switch may need to be atomic. 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