On Sat, Jan 9, 2016 at 1:36 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Jan 8, 2016 8:31 PM, "Brian Gerst" <brgerst@xxxxxxxxx> wrote: >> >> On Fri, Jan 8, 2016 at 10:39 PM, Brian Gerst <brgerst@xxxxxxxxx> wrote: >> > On Fri, Jan 8, 2016 at 8:52 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> >> On Fri, Jan 8, 2016 at 12:49 PM, Tony Luck <tony.luck@xxxxxxxxx> wrote: >> >>> Huge amounts of help from Andy Lutomirski and Borislav Petkov to >> >>> produce this. Andy provided the inspiration to add classes to the >> >>> exception table with a clever bit-squeezing trick, Boris pointed >> >>> out how much cleaner it would all be if we just had a new field. >> >>> >> >>> Linus Torvalds blessed the expansion with: >> >>> I'd rather not be clever in order to save just a tiny amount of space >> >>> in the exception table, which isn't really criticial for anybody. >> >>> >> >>> The third field is a simple integer indexing into an array of handler >> >>> functions (I thought it couldn't be a relative pointer like the other >> >>> fields because a module may have its ex_table loaded more than 2GB away >> >>> from the handler function - but that may not be actually true. But the >> >>> integer is pretty flexible, we are only really using low two bits now). >> >>> >> >>> We start out with three handlers: >> >>> >> >>> 0: Legacy - just jumps the to fixup IP >> >>> 1: Fault - provide the trap number in %ax to the fixup code >> >>> 2: Cleaned up legacy for the uaccess error hack >> >> >> >> I think I preferred the relative function pointer approach. >> >> >> >> Also, I think it would be nicer if the machine check code would invoke >> >> the handler regardless of which handler (or class) is selected. Then >> >> the handlers that don't want to handle #MC can just reject them. >> >> >> >> Also, can you make the handlers return bool instead of int? >> > >> > I'm hashing up an idea that could eliminate alot of text in the .fixup >> > section, but it needs the integer handler method to work. We have >> > alot of fixup code that does "mov $-EFAULT, reg; jmp xxxx". If we >> > encode the register in the third word, the handler can be generic and >> > no fixup code for each user access would be needed. That would >> > recover alot of the memory used by expanding the exception table. >> >> On second thought, this could still be implemented with a relative >> function pointer. We'd just need a separate function for each >> register. >> > > If we could get gcc to play along (which, IIRC, it already can for > __put_user), we can do much better with jump labels -- the fixup > target would be a jump label. > > Even without that, how about using @cc? Do: > > clc > mov whatever, wherever > > The fixup sets the carry flag and skips the faulting instruction > (either by knowing the length or by decoding it), and the inline asm > causes gcc to emit jc to the error logic. > > --Andy I agree that for at least put_user() using asm goto would be an even better option. get_user() on the other hand, will be much messier to deal with, since asm goto statements can't have outputs, plus it zeroes the output register on fault. -- Brian Gerst -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>