svn commit: r309891 - head/sys/kern

[Konstantin Belousov]

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.