Messages in this thread | | | Date | Thu, 19 Apr 2012 10:54:12 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [PATCH 3/3] x86, extable: Handle early exceptions |
| |
On 04/19/2012 10:02 AM, H. Peter Anvin wrote: > On 04/19/2012 02:26 AM, Borislav Petkov wrote: >> >> Also, move the sorting of the main exception table earlier in the boot >> process now that we handle exceptions in the early IDT handler too. >> > > I would much rather use David Daney's patchset to sort the exception > table at compile time: > > https://lkml.org/lkml/2011/11/18/427 > > ... and I would be *even happier* with an O(1) hash (which pretty much > *have* to be constructed at compile time.) >
The sorting is easier infrastructure-wise, since it can be done in-place. The O(1) hash needs additional space for the hash table itself (the actual table can still be stashed where the compiler generates it.)
The hash table generator I have posted at:
http://www.zytor.com/~hpa/phash/
Generally needs ~3.2 bytes per hash table entry, rounded up to a power of two. The rounding up is for performance. The easiest way to do this is probably to let the linker create a zero-filled section of the proper size (since the linker knows the final size of the __ex_table section, and the linker script can do at least a modicum of arithmetic) and then use a tool to patch in the hash table auxilliary data.
-hpa
P.S. Another modification which was talked about in the past and there even were patches for was to make the exception table entries relative to the start of the kernel, so we don't need two relocations per entry for x86-32 and twice the amount of data that we can actually use for x86-64. As I recall we tried those patches and there was some bug that never got resolved.
This is obviously a precondition for doing the O(1) hash, since the O(1) hash can't be relocated once generated.
| |