From owner-svn-src-head@freebsd.org Mon Mar 7 16:52:07 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 7E4B2AC3B54; Mon, 7 Mar 2016 16:52:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0CF0E637; Mon, 7 Mar 2016 16:52:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u27GpulC026095 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 7 Mar 2016 18:51:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u27GpulC026095 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u27GpunT026094; Mon, 7 Mar 2016 18:51:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 7 Mar 2016 18:51:56 +0200 From: Konstantin Belousov To: Warner Losh Cc: Ian Lepore , Dimitry Andric , src-committers , "svn-src-all@freebsd.org" , "svn-src-head@freebsd.org" Subject: Re: svn commit: r296428 - head/sys/boot/common Message-ID: <20160307165156.GK67250@kib.kiev.ua> References: <201603061557.u26FvhMi033982@repo.freebsd.org> <56DCD52F.4010709@freebsd.org> <1457365187.13785.174.camel@freebsd.org> <20160307155217.GJ67250@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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:52:07 -0000 On Mon, Mar 07, 2016 at 09:28:13AM -0700, Warner Losh wrote: > 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. This is absolute useless kernel bloat. Kernel should provide an execution environment for user programs, and not lecture users about proper system configuration. > > 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. Why should kernel ignore loaded .eh_frame ? I do not see any use for other part of the suggestion at all. To clarify, kernel paniced because some (required but currently not utilized) part of the binary module was not loaded. > > 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? Practically, we could ignore that relocations and still load the module, but this is only because we know what the scope of the relocations is. For some arbitrary situation with the same detected missed place for relocations, loader cannot know is it safe or not. The problem is fixed and does not deserve nuking of all computers in the world, which was an equivalent of some other suggestions how to handle that. Most of the suggestions come to extreme which is not deserved. What could be useful, as I noted already, is to demote the panics from kernel linker to warnings. I intended to work on this.