From owner-svn-src-all@freebsd.org Mon Mar 7 15:39:55 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 EC63FAC2619 for ; Mon, 7 Mar 2016 15:39:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CD4A4F16 for ; Mon, 7 Mar 2016 15:39:55 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 126b9f51-e47b-11e5-8de6-958346fd02ba X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 7 Mar 2016 15:41:34 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u27Fdlgq001184; Mon, 7 Mar 2016 08:39:47 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1457365187.13785.174.camel@freebsd.org> Subject: Re: svn commit: r296428 - head/sys/boot/common From: Ian Lepore To: Dimitry Andric , Julian Elischer Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Date: Mon, 07 Mar 2016 08:39:47 -0700 In-Reply-To: References: <201603061557.u26FvhMi033982@repo.freebsd.org> <56DCD52F.4010709@freebsd.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.21 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: Mon, 07 Mar 2016 15:39:56 -0000 On Mon, 2016-03-07 at 08:41 +0100, Dimitry Andric wrote: > On 07 Mar 2016, at 02:11, Julian Elischer wrote: > > > > On 6/03/2016 7:57 AM, Dimitry Andric wrote: > > > Author: dim > > > Date: Sun Mar 6 15:57:43 2016 > > > New Revision: 296428 > > > URL: https://svnweb.freebsd.org/changeset/base/296428 > > > > > > Log: > > > Since kernel modules can now contain sections of type > > > SHT_AMD64_UNWIND, > > > the boot loader should not skip over these anymore while > > > loading images. > > > Otherwise the kernel can still panic when it doesn't find the > > > .eh_frame > > > section belonging to the .rela.eh_frame section. > > > Unfortunately this will require installing boot loaders from > > > sys/boot > > > before attempting to boot with a new kernel. > > > > what happens to someone who doesn't replace their bootblocks? > > Or is this just the loader? > > This just about the loaders, e.g. loader, loader.efi and zfsloader. > > > > The general way we have handled this sort of thing in the past is > > that we do something > > that produces a nagging message for a decent time before it becomes > > mandatory. > > > > I don't like the idea of people being caught unaware by this.. > > > > Can you please give a more detailed description of what happens? > > If you preload modules with .eh_frame sections in them (such as > aesni.ko) from your loader.conf, your kernel will panic very early in > the boot. > > If you don't preload any modules, or load only modules without > .eh_frame > sections (most of of them), there is no issue at all. > > -Dimitry > Is there no way to prevent the panic other than making the unwind data be present? Why can't the kernel be fixed to cope with the missing data in some gentler way during a transition period? Perhaps valid-but -fake data could be generated if necessary? Being unable to get a stack traceback through a loaded module would be a small price to pay for trouble-free updgrades. -- Ian