Date: Sat, 22 Dec 2012 13:44:49 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Garrett Cooper <yanegomi@gmail.com>, freebsd-net@FreeBSD.org, FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: Fatal trap 1 Message-ID: <50D59D31.6010302@FreeBSD.org> In-Reply-To: <20121222112124.GN53644@kib.kiev.ua> References: <CAGH67wQKUDLQmL8cnWwgzQpWAN2OhKLu0AemPNuy7EOC-i1p9g@mail.gmail.com> <CAJ-Vmo=MsSV3DhAVEP36d%2BFccHDdQz7%2By7v5xTjYKyBP0PfQoQ@mail.gmail.com> <CAMBSHm96ZEiF4mOhUyk-aDS%2BGs%2BhDsh_dMsd-WFcmZ%2BSm6Zk%2BA@mail.gmail.com> <CAGH67wQ8L5R8H7G7s%2B6b%2BiKaAz54es8scnASUQ8Env10x1iqzg@mail.gmail.com> <50D5949A.1060505@FreeBSD.org> <20121222112124.GN53644@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50D59D31.6010302>