On Sat, Dec 26, 2015 at 6:15 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > On Sat, Dec 26, 2015 at 6:08 PM, Tony Luck <tony.luck@xxxxxxxxx> wrote: >> On Sat, Dec 26, 2015 at 6:54 AM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >>> On Dec 26, 2015 6:33 PM, "Borislav Petkov" <bp@xxxxxxxxx> wrote: >>>> Andy, why is that? It makes the exception handling much simpler this way... >>>> >>> >>> I like the idea of moving more logic into C, but I don't like >>> splitting the logic across files and adding nasty special cases like >>> this. >>> >>> But what if we generalized it? An extable entry gives a fault IP and >>> a landing pad IP. Surely we can squeeze a flag bit in there. >> >> The clever squeezers have already been here. Instead of a pair >> of 64-bit values for fault_ip and fixup_ip they managed with a pair >> of 32-bit values that are each the relative offset of the desired address >> from the table location itself. >> >> We could make one of them 31-bits (since even an "allyesconfig" kernel >> is still much smaller than a gigabyte) to free a bit for a flag. But there >> are those external tools to pre-sort exception tables that would all >> need to be fixed too. Wait, why? The external tools sort by source address, and we'd squeeze the flag into the target address, no? --Andy -- 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>