Messages in this thread | | | Date | Sat, 20 Mar 2010 00:08:36 -0400 | Subject | Re: [PATCH 1/5] x86-32: Split cache flush handler from simd handler | From | Brian Gerst <> |
| |
On Fri, Mar 19, 2010 at 6:33 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 03/18/2010 11:20 AM, Brian Gerst wrote: >> Make the cache flush handler a seperate function, and use >> an alternative to call the appropriate handler. >> >> +#ifdef CONFIG_X86_32 >> +dotraplinkage void >> +do_cache_flush_error(struct pt_regs *regs, long error_code) >> +{ >> + conditional_sti(regs); >> + >> + /* >> + * Handle strange cache flush from user space exception. >> + * This is undocumented behaviour. >> + */ >> + if (regs->flags & X86_VM_MASK) { >> + handle_vm86_fault((struct kernel_vm86_regs *)regs, error_code); >> + return; >> + } >> + current->thread.trap_no = 19; >> + current->thread.error_code = error_code; >> + die_if_kernel("cache flush denied", regs, error_code); >> + force_sig(SIGSEGV, current); >> +} >> +#endif > > Does anyone have *any idea* what processor this applies to? I've > tracked the code back all the way to the original inclusion in the > kernel, and there isn't even the slightest hint. > > The comment, of course, is a great example on how *not* to write > comments... it should have mentioned the CPU in question.
This thread appears to describe the problem: http://marc.info/?t=104960872800014&r=1&w=2
And the initial patch: http://marc.info/?l=linux-kernel&m=104960870106838&w=2
It looks like to me, that an AMD 486 clone has an erratum where the invd instruction from userspace generates exception 19 (13 hex) instead of #GP (13 dec).
-- Brian Gerst -- 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/
| |