From owner-svn-src-head@freebsd.org Mon Mar 7 16:32:37 2016 Return-Path: Delivered-To: svn-src-head@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 2BF83AC3425 for ; Mon, 7 Mar 2016 16:32:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4574A85 for ; Mon, 7 Mar 2016 16:32:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x22f.google.com with SMTP id hb3so44632550igb.0 for ; Mon, 07 Mar 2016 08:32:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=xiEmsom9udTZ6EJvV5Uwygwumr57qtvt7egcT3Wsiwo=; b=A5FVBVpdfdMlz20zI+ujQVMXXkqdFEUM0H9Jzk6JqpVIOy+7S49L1/itB/XjgEw+qO k3H9dh5OpdOZCFSN5RNL/tI1x3igqMQPwVyb7heIJ6lpFgmU8mvoZk9+zSY4cC+k+nhv d682Cs/QKXxnTVEKONMumZzll3YqlxwVbiYA6aXNaXFesE2vPPi04TiMpMm7mafKDvhv JSkVQf53Ttdu3CjTylx+rEsK9Nl6ka54QeE/CdpQXSRaEIsh0hVWOpkDddybaCmI2meq q/ZXb4vC/FKYBX5jMzXmRkeSG5LuXRG2pYR8g/8GB5QqggHDHUTM9k/vCMDPuU/enIzU HeNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=xiEmsom9udTZ6EJvV5Uwygwumr57qtvt7egcT3Wsiwo=; b=JDL+KuPWUfpKryeVr0PB0tjUC70qoj6SQQgXXsJlW0dZMWaD3JB7a3xtb/QRlk/8bN bODsAhPW52bq4uNHb1clB6f17Q288BMGZpsUVDwDoT7r4lzlfCKi1QJiQVVrD4jPOhF3 64qHkE0rseWFeDwsyulCV7nVseGW2PxTUR4Ic/COTEmGGedk5wmEkVPH6BpnuSZoBwC0 Q/6wuLOTigoe/93VtJReYWPgUAPEGChJGAVMsPshsBAw1kpNEoHH6gfAXLW1MkU65t1k B5lSgKZFVShhVDWPjNsJpHOih4OvmCBMY9dz6JrtMDi/+o3Qdk6xIaHmPWFoDbK+9V2j byMA== X-Gm-Message-State: AD7BkJLZoR5u84Ayt+rHmN3YNcyAWkLlkiI0R9EJZHK0TbIWSpAQ7uAj9P5X5Meo/0ojLBiG4R4ASWAzerEFEw== MIME-Version: 1.0 X-Received: by 10.50.112.101 with SMTP id ip5mr12368617igb.52.1457368356325; Mon, 07 Mar 2016 08:32:36 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.36.65.167 with HTTP; Mon, 7 Mar 2016 08:32:36 -0800 (PST) X-Originating-IP: [69.53.245.36] In-Reply-To: <20160307155217.GJ67250@kib.kiev.ua> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <56DCD52F.4010709@freebsd.org> <1457365187.13785.174.camel@freebsd.org> <20160307155217.GJ67250@kib.kiev.ua> Date: Mon, 7 Mar 2016 09:32:36 -0700 X-Google-Sender-Auth: a9A0QJtOUZyL4xOgb8e-4Kh1Fl0 Message-ID: Subject: Re: svn commit: r296428 - head/sys/boot/common From: Warner Losh To: Konstantin Belousov Cc: Ian Lepore , Dimitry Andric , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.21 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: Mon, 07 Mar 2016 16:32:37 -0000 On Mon, Mar 7, 2016 at 8:52 AM, Konstantin Belousov wrote: > On Mon, Mar 07, 2016 at 08:39:47AM -0700, Ian Lepore wrote: > > 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. > > It is practically impossible to recover from partially-loaded object file' > module. The loader workaround currently only affects HEAD and since the > MFC was done, 10.3 should be safe. We always required lastest stable > for the jump to next major branch. > Require is a strong word here. That's the only guarantee the project makes. However, our boot loader has been stable enough that even very old /boot/loaders can load -current until this change. It goes a bit against POLA given what has traditionally worked. If the effort isn't large, we should do something and only fall back to being this strict if there's really no other way possible forward. > What could be done is demoting the panics (there are several, besides > the one which was triggered) to a message and refusing to load the > affected module. OTOH, if the reaction would be a message and not panic, > it definitely go ignored for quite some time. > But a message would tell the user what's up and give them a working kernel with which to fix the problem. It would also allow the traditional upgrade path, burned into many people's fingers, to just work unless they needed one of the rare .eh_frame modules to affect that upgrade. Warner