From owner-svn-src-head@freebsd.org Wed Jan 31 02:02:01 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A05DFED165B; Wed, 31 Jan 2018 02:02:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::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 50D186D2B9; Wed, 31 Jan 2018 02:02:01 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (ralph.baldwin.cx [66.234.199.215]) by mail.baldwin.cx (Postfix) with ESMTPSA id 672C110A7DB; Tue, 30 Jan 2018 21:02:00 -0500 (EST) From: John Baldwin To: src-committers@freebsd.org Cc: svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r328610 - head/sys/amd64/amd64 Date: Tue, 30 Jan 2018 18:01:42 -0800 Message-ID: <3195814.6PcFLP86qD@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.1-STABLE; KDE/4.14.30; amd64; ; ) In-Reply-To: <201801302329.w0UNTRHn080138@repo.freebsd.org> References: <201801302329.w0UNTRHn080138@repo.freebsd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Tue, 30 Jan 2018 21:02:00 -0500 (EST) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 02:02:01 -0000 On Tuesday, January 30, 2018 11:29:27 PM John Baldwin wrote: > Author: jhb > Date: Tue Jan 30 23:29:27 2018 > New Revision: 328610 > URL: https://svnweb.freebsd.org/changeset/base/328610 > > Log: > Ensure 'name' is not NULL before passing to strcmp(). > > This avoids a nested page fault when obtaining a stack trace in DDB if > the address from the first frame does not resolve to a known symbol. > > MFC after: 1 week > Sponsored by: Chelsio Communications This appears to be fallout from lld? After fixing this, the stack trace for my next panic shows no symbols for functions in the kernel, only functions in kernel modules: KDB: stack backtrace: ??() at 0xffffffff803c372b/frame 0xfffffe0093632750 ??() at 0xffffffff80a07539/frame 0xfffffe0093632800 ??() at 0xffffffff809cc14c/frame 0xfffffe0093632860 ??() at 0xffffffff809cc203/frame 0xfffffe00936328c0 do_rx_tls_cmp() at do_rx_tls_cmp+0x1d3/frame 0xfffffe0093632910 service_iq() at service_iq+0x380/frame 0xfffffe00936329b0 t4_intr() at t4_intr+0x2e/frame 0xfffffe00936329d0 ??() at 0xffffffff80993f1f/frame 0xfffffe0093632a10 ??() at 0xffffffff80994716/frame 0xfffffe0093632a30 ??() at 0xffffffff809945cb/frame 0xfffffe0093632a70 ??() at 0xffffffff809912f3/frame 0xfffffe0093632ab0 ??() at 0xffffffff80e1de8e KDB: enter: panic I don't spot anything obvious comparing readelf of an older kernel with the LLD kernel, but I also haven't tried debugging this further. -- John Baldwin