Messages in this thread | | | Date | Mon, 14 Jul 2008 18:53:33 +0300 | From | Avi Kivity <> | Subject | Re: [git pull] core, x86: make LIST_POISON less deadly |
| |
Ingo Molnar wrote: > * Linus Torvalds <torvalds@linux-foundation.org> wrote: > > >> On Mon, 14 Jul 2008, Ingo Molnar wrote: >> >>> >>> +config ILLEGAL_POINTER_VALUE >>> + hex >>> + default 0 if X86_32 >>> + default 0xffffc10000000000 if X86_64 >>> >> This looks like a singularly bad pointer value on x86-64. >> >> Why not pick something that is *guaranteed* to fault? The above looks >> like any future setup that supports 41 bits of addressing and has >> extended the page tables (yes, it will happen eventually) will find >> that to be a perfectly valid address? >> >> It's also visually confusing, since it's visually very close to a real >> kernel pointer too. >> >> Grr. >> >> Why not use something sane like 0xdead000000000000, which has the high >> bit set but very fundamentally isn't a valid pointer, and never will >> be? And which is a *lot* more visually obvious too! >> > > initially i suggested that too - but such addresses raise a #GP instead > of a page fault so their decoding is a bit harder. > > We dont do any instruction decoding in #GP handlers to figure out what > happened, while in the pagefault case we know which address faulted, > etc. > > Perhaps we could try to make #GP handlers a bit more informative - > although decoding instructions will make things a bit more fragile > inevitably. > > Perhaps make it 0xffffcdead0000000 ? >
We could have the oops handler detect this address range, and point out the problem in plain English.
-- error compiling committee.c: too many arguments to function
| |