From owner-svn-src-all@freebsd.org Thu Nov 1 17:26:19 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3238710F93F9; Thu, 1 Nov 2018 17:26:19 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DCB9E80E7E; Thu, 1 Nov 2018 17:26:18 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id BADC91ED12; Thu, 1 Nov 2018 17:26:18 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id wA1HQIee077254; Thu, 1 Nov 2018 17:26:18 GMT (envelope-from bz@FreeBSD.org) Received: (from bz@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id wA1HQIIE077253; Thu, 1 Nov 2018 17:26:18 GMT (envelope-from bz@FreeBSD.org) Message-Id: <201811011726.wA1HQIIE077253@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bz set sender to bz@FreeBSD.org using -f From: "Bjoern A. Zeeb" Date: Thu, 1 Nov 2018 17:26:18 +0000 (UTC) To: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: svn commit: r340009 - head/sys/netinet X-SVN-Group: head X-SVN-Commit-Author: bz X-SVN-Commit-Paths: head/sys/netinet X-SVN-Commit-Revision: 340009 X-SVN-Commit-Repository: base MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 01 Nov 2018 17:26:19 -0000 Author: bz Date: Thu Nov 1 17:26:18 2018 New Revision: 340009 URL: https://svnweb.freebsd.org/changeset/base/340009 Log: carpstats are the last virtualised variable in the file and end up at the end of the vnet_set. The generated code uses an absolute relocation at one byte beyond the end of the carpstats array. This means the relocation for the vnet does not happen for carpstats initialisation and as a result the kernel panics on module load. This problem has only been observed with carp and only on i386. We considered various possible solutions including using linker scripts to add padding to all kernel modules for pcpu and vnet sections. While the symbols (by chance) stay in the order of appearance in the file adding an unused non-file-local variable at the end of the file will extend the size of set_vnet and hence make the absolute relocation for carpstats work (think of this as a single-module set_vnet padding). This is a (tmporary) hack. It is the least intrusive one as we need a timely solution for the upcoming release. We will revisit the problem in HEAD. For a lot more information and the possible alternate solutions please see the PR and the references therein. PR: 230857 MFC after: 3 days Modified: head/sys/netinet/ip_carp.c Modified: head/sys/netinet/ip_carp.c ============================================================================== --- head/sys/netinet/ip_carp.c Thu Nov 1 17:05:10 2018 (r340008) +++ head/sys/netinet/ip_carp.c Thu Nov 1 17:26:18 2018 (r340009) @@ -2176,6 +2176,21 @@ static struct protosw in6_carp_protosw = { }; #endif +#ifdef VIMAGE +#if defined(__i386__) +/* + * XXX This is a hack to work around an absolute relocation outside + * set_vnet by one (on the stop symbol) for carpstats. Add a dummy variable + * to the end of the file in the hope that the linker will just keep the + * order (as it seems to do at the moment). It is understood to be fragile. + * See PR 230857 for a longer discussion of the problem and the referenced + * review for possible alternate solutions. Each is a hack; we just need + * the least intrusive one for the next release. + */ +VNET_DEFINE(char, carp_zzz) = 0xde; +#endif +#endif + static void carp_mod_cleanup(void) {