Date: Mon, 7 Mar 2016 09:32:36 -0700 From: Warner Losh <imp@bsdimp.com> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Ian Lepore <ian@freebsd.org>, Dimitry Andric <dim@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r296428 - head/sys/boot/common Message-ID: <CANCZdfpf-YUpx6zQtj=eK=qPwu4dLw9ph%2BGi82Przjs2c3QNow@mail.gmail.com> In-Reply-To: <20160307155217.GJ67250@kib.kiev.ua> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <56DCD52F.4010709@freebsd.org> <AC0A9708-B618-4D05-8532-BD451AB94A60@FreeBSD.org> <1457365187.13785.174.camel@freebsd.org> <20160307155217.GJ67250@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 7, 2016 at 8:52 AM, Konstantin Belousov <kostikbel@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfpf-YUpx6zQtj=eK=qPwu4dLw9ph%2BGi82Przjs2c3QNow>