On Tue, Dec 13, 2016 at 10:20:30AM +1100, Bruce Evans wrote: > Hrmph. kib didn't like my patch to kill the spam from reentering ddb. > The spam messes up even cases where the ddb command handles errors. > Howver, in most cases the error handling is incomplete. There is always > the outer setjmp/longjmp back to the command loop. This gives null and > bad error handling for unexpected null pointer accesses like the one here. > Other cases set up inner setjump/longjmps which longjmp back to an inner > context which prints an error message (spammed by the reentry messages) > and should clean up. However, cleanup is rarely done. One case is > writing to inaccessible memory on at least x86. Then the page tables > are left in modified state. You have a variant of the patch which makes the behaviour adjustable. I already agreed with that modification, and with making the defaults to not print the backtrace.
> > Null pointer panics are also interesting. They seem to have been broken > on i386 by the double mapping of low memory (PTD[0] = PTD[KERNBASE >> 12] = > shared page table for low physical memory). So the null pointer is mapped > and points to physical memory 0 . There are other bugs from the shared > page table. When I fix the other bugs by changing PTD[0] to 0, this also > fixes null pointers. It breaks ACPI resume but not much else. See > locore.s for some details about the mapping -- it is documented as being > mainly for ACPI. But ACPI somehow works on amd64 with PTD[0] = 0. That page table is only active for the kernel processes, so most often, when userspace part is present, page at zero is not mapped. _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
