From owner-freebsd-current@FreeBSD.ORG  Sat Dec 22 11:44:55 2012
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
 by hub.freebsd.org (Postfix) with ESMTP id 1031A91A;
 Sat, 22 Dec 2012 11:44:55 +0000 (UTC) (envelope-from avg@FreeBSD.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
 by mx1.freebsd.org (Postfix) with ESMTP id 1E1C88FC12;
 Sat, 22 Dec 2012 11:44:53 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
 [212.40.38.100])
 by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA18206;
 Sat, 22 Dec 2012 13:44:51 +0200 (EET) (envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
 by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
 id 1TmNVa-000E2o-Un; Sat, 22 Dec 2012 13:44:50 +0200
Message-ID: <50D59D31.6010302@FreeBSD.org>
Date: Sat, 22 Dec 2012 13:44:49 +0200
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Konstantin Belousov <kostikbel@gmail.com>
Subject: Re: Fatal trap 1
References: <CAGH67wQKUDLQmL8cnWwgzQpWAN2OhKLu0AemPNuy7EOC-i1p9g@mail.gmail.com>
 <CAJ-Vmo=MsSV3DhAVEP36d+FccHDdQz7+y7v5xTjYKyBP0PfQoQ@mail.gmail.com>
 <CAMBSHm96ZEiF4mOhUyk-aDS+Gs+hDsh_dMsd-WFcmZ+Sm6Zk+A@mail.gmail.com>
 <CAGH67wQ8L5R8H7G7s+6b+iKaAz54es8scnASUQ8Env10x1iqzg@mail.gmail.com>
 <50D5949A.1060505@FreeBSD.org> <20121222112124.GN53644@kib.kiev.ua>
In-Reply-To: <20121222112124.GN53644@kib.kiev.ua>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: Garrett Cooper <yanegomi@gmail.com>, freebsd-net@FreeBSD.org,
 FreeBSD Current <freebsd-current@FreeBSD.org>
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.14
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
 <freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-current>, 
 <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
 <mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Dec 2012 11:44:55 -0000

on 22/12/2012 13:21 Konstantin Belousov said the following:
> This is due to the vtoslab() returning NULL. Since slabref is dereferenced
> later, clang tries to be helpful as usual and converts the !(p->flags &
> PG_SLAB) case from vtoslab() into the jump to un2 instruction if vtoslab()
> result is NULL.
> 
> So instead of KASSERT triggering the next line, you see this improvement.

Interesting.  Thank you for the explanation.

But looking at the code I think that slabref->us_keg access _before_ KASSERT
is the culprit?  I.e. even with GCC we could get a page fault before the
KASSERT is reached (modulo reordering)?

-- 
Andriy Gapon