From: H. Peter Anvin on 19 Mar 2010 18:40 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. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: H. Peter Anvin on 20 Mar 2010 15:00 On 03/19/2010 09:55 PM, H. Peter Anvin wrote: > > Ah, guess it was even older than I first realized ... I should have > searched for the string "cache flush denied" instead. > > Sounds like we should do three things: > > a) update the comment to actually reflect what is going on; > b) compile it out for > 486; > c) report the error as trap 13 rather than 19. > Actually what we should do is recognize that this is nothing other than a misdirected #GP, and as a result send the fault down the #GP handler (do_general_protection)... there really isn't any need for a special routine at all. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|
Pages: 1 Prev: [PATCH -v3] x86: do not free zero sized per cpu areas Next: Intel SASMF8I |