svn commit: r340109 - stable/12/sys/netinet

[Bjoern A. Zeeb]

Author: bz
Date: Sun Nov  4 06:25:07 2018
New Revision: 340109
URL: https://svnweb.freebsd.org/changeset/base/340109

Log:
  MFC r340009:
  
    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
  Approved by:	re (kib)

Modified:
  stable/12/sys/netinet/ip_carp.c
Directory Properties:
  stable/12/   (props changed)

Modified: stable/12/sys/netinet/ip_carp.c
==============================================================================
--- stable/12/sys/netinet/ip_carp.c	Sun Nov  4 06:24:27 2018	(r340108)
+++ stable/12/sys/netinet/ip_carp.c	Sun Nov  4 06:25:07 2018	(r340109)
@@ -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)
 {