From owner-svn-src-all@freebsd.org Mon Mar 7 16:28:14 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 67C69AC31CF for ; Mon, 7 Mar 2016 16:28:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001:c05::22a]) (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 3E6C963E for ; Mon, 7 Mar 2016 16:28:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x22a.google.com with SMTP id hb3so44535839igb.0 for ; Mon, 07 Mar 2016 08:28:14 -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=G4LRhL+z5Nuc5BqU8mHuNGZjN8KPVOvS66eNNxEZaTE=; b=X6gAkEdrz0aWvkFl53ldj8jcQX0kuy++QkWcVF3znqTmVBhzRmZ9zDRkyNgCqUxY5b bKJnaXoTra2iWTJdAFMZR/dGifX42EV0bjn9KiM0RuVufigwIX5WC11+cfP0HST4hhWd KZTXDWF1d5PVfObJ1HGR7dD7923eHX8fxaZR47Oa6K7H5ARdkYsSeyNIV3mFU41+w6ZP /wWQQ+2REBwkPs5IOx32+qxuFGMQjTCP8ynYxYKjcbsbEIMQZH2uDkO9LeIM50DMrpOn G6IdwPebdzyCvvFyBwY56WHAKljQzx7nhLaZNRjEz6ZUmXxYLIYbVkc9phkvXwxkJVrz 445A== 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=G4LRhL+z5Nuc5BqU8mHuNGZjN8KPVOvS66eNNxEZaTE=; b=UBEwhSlHH95S8F3FWsDq9qqYVN1ySmIx9KMecwz+9gJtqRS24Em78ulK8AEJYH7COH ZsCqq+mJRm1XMyQy7FsmjtoBs/tvUc5bZkLosE5/22JDgC42nwCBjJ2BMYfSF4DmY9tU Ntt9wtImCgNN2FXeIWY46tNbZAEzl1Rvh1WMj89OZVEVVqmz6i2hMyWffils4/ghOc2s WFTmjWBIIWTtt5iTPW9LQ/iOWWvPUHbRnslSYcxEjs8JHYaH3hI6D0Y/ho3pj8Aq/33+ pprRVOw8xIYldpCgsJgFFY8dKxHwjPW0UyNmHxq8IfQe37TF0GD8ZzSBbU/pZO2WNyNk 5O9g== X-Gm-Message-State: AD7BkJLv8+RJa6cq5elADMzWim18MPscbRR64VE5XysOWZnxX/KLJwHzfllXJAtTTCcY+wBTda7kQl5SyT4F6w== MIME-Version: 1.0 X-Received: by 10.50.30.134 with SMTP id s6mr12086838igh.36.1457368093564; Mon, 07 Mar 2016 08:28:13 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.36.65.167 with HTTP; Mon, 7 Mar 2016 08:28:13 -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:28:13 -0700 X-Google-Sender-Auth: a0r7BiG7DTZJzPL7r1JILjYwrso 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:28:14 -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. > > 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. > The new loader could also pass in some version or cookie in the metadata that says it is the new one. The kernel could examine this and issue a warning, on amd64 / i386, that module linking may be incomplete and you'll need to upgrade your /boot/loader if you encounter a crash. Could the kernel detect that a .eh_frame module was loaded and ignore it in "safe mode"? Perhaps combined with the new boot-loader cookie, this would be an automatic way to not mysteriously crash. Alternatively, is there a switch to clang 3.8 that says 'Don't generate the new relocation, use the old one instead" which would also be safe and allow a less-bumpy transition? Finally, would the partially loaded module stop at the first bad relocation, or would it do them all and just skip the bad ones? Is the data from this relocation used all the time, or just when we're doing a stack unwind for an exception or a backtrace? Warner