From owner-svn-src-all@freebsd.org Sun Nov 20 08:31:39 2016 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B337C483F1; Sun, 20 Nov 2016 08:31:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EAD63285; Sun, 20 Nov 2016 08:31:38 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id uAK8VVPs041821 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 20 Nov 2016 10:31:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua uAK8VVPs041821 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id uAK8VV3J041820; Sun, 20 Nov 2016 10:31:31 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 20 Nov 2016 10:31:31 +0200 From: Konstantin Belousov To: John Baldwin Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r308821 - head/sys/i386/i386 Message-ID: <20161120083131.GP54029@kib.kiev.ua> References: <201611190136.uAJ1aiZb091275@repo.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201611190136.uAJ1aiZb091275@repo.freebsd.org> User-Agent: Mutt/1.7.1 (2016-10-04) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 08:31:39 -0000 On Sat, Nov 19, 2016 at 01:36:44AM +0000, John Baldwin wrote: > Author: jhb > Date: Sat Nov 19 01:36:44 2016 > New Revision: 308821 > URL: https://svnweb.freebsd.org/changeset/base/308821 > > Log: > MFamd64: Various fatal page fault fixes. > > - If a page fault is triggered due to reserved bits in a PTE, treat it > as a fatal fault and panic. > - If PG_NX is in use, report whether a fatal page fault is due to an > instruction fetch or a data access. > - If a fatal page fault is due to reserved bits in a PTE, report that as > the page fault type rather than a protection violation. > > MFC after: 1 month > > Modified: > head/sys/i386/i386/trap.c > > Modified: head/sys/i386/i386/trap.c > ============================================================================== > --- head/sys/i386/i386/trap.c Sat Nov 19 01:34:12 2016 (r308820) > +++ head/sys/i386/i386/trap.c Sat Nov 19 01:36:44 2016 (r308821) > @@ -857,6 +857,14 @@ trap_pfault(frame, usermode, eva) > } > > /* > + * If the trap was caused by errant bits in the PTE then panic. > + */ > + if (frame->tf_err & PGEX_RSV) { > + trap_fatal(frame, eva); > + return (-1); > + } > + > + /* > * PGEX_I is defined only if the execute disable bit capability is > * supported and enabled. > */ > @@ -926,9 +934,15 @@ trap_fatal(frame, eva) > #endif > if (type == T_PAGEFLT) { > printf("fault virtual address = 0x%x\n", eva); > - printf("fault code = %s %s, %s\n", > + printf("fault code = %s %s%s, %s\n", > code & PGEX_U ? "user" : "supervisor", > code & PGEX_W ? "write" : "read", > +#if defined(PAE) || defined(PAE_TABLES) > + pg_nx != 0 ? > + (code & PGEX_I ? " instruction" : " data") : > +#endif I suggest to remove #ifdef guards, and the pg_nx check there, as well. The page fault exception error code bits have constant meaning regardless of the kernel and CPU configuration, so if we get the I bit set in the error word, we know that it was due to executing on PAE table with bit 63 (nx) set. This is true even if kernel was not configured to create such tables. In other words, it would give more correct and useful information, which make it easier to track page tables corruption. > + "", > + code & PGEX_RSV ? "reserved bits in PTE" : > code & PGEX_P ? "protection violation" : "page not present"); > } > printf("instruction pointer = 0x%x:0x%x\n", I