Date: Tue, 13 Dec 2016 14:11:17 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Bruce Evans <brde@optusnet.com.au> Cc: Edward Tomasz Napierala <trasz@freebsd.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r309891 - head/sys/kern Message-ID: <20161213121117.GV54029@kib.kiev.ua> In-Reply-To: <20161213091945.V1082@besplex.bde.org> References: <201612121522.uBCFMMmm088698@repo.freebsd.org> <20161212163331.GH54029@kib.kiev.ua> <20161212191257.GA11238@brick> <20161213091945.V1082@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161213121117.GV54029>