From owner-svn-src-all@freebsd.org Mon Mar 7 16:32:37 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 3FBB4AC3426 for ; Mon, 7 Mar 2016 16:32:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (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 04130A87 for ; Mon, 7 Mar 2016 16:32:37 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x230.google.com with SMTP id ig19so28446044igb.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=CCiknk/klp+nRCzmB8W9L2JhNTE6oBr6yBB8Yk8H7WqP1KlUgUj/t/OvW1u1z7Obhv Oe0N5bZdb4hKm6fqnqVmKsz2BVPE4hz4l6hWu6MuWXqajUR2RAiLLGruLJZGzRwUTZ4V vuikf+MymcHTw1iQb1aCgSjOBM/ybAnjGYmVnd9fLS3gHaDhzW4GZbZpiHz+qgRfMe1i huAnTFSt3kTl3ZyuUkmXBLzKK6AQP/sp8oTArIFqeVHyA77biDlFiU6Rcx0dmZXSaShk 4hdBImXn54O8N0PgK7Rfv2F1TmLAgGO0Ldrv+W17kC/rPKEiy2e3jIVBvzjkyiMpucE+ Pgcw== X-Gm-Message-State: AD7BkJKfNRFl4rnElgCeGrIwOdRGql8DoGIukQ4HVyXM7+sM4QmzoprILZ0cAHVR1d/PJLWEFohcfLy0a5hniA== 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-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 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