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>
index | next in thread | previous in thread | raw e-mail
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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161213121117.GV54029>