From owner-freebsd-toolchain@freebsd.org Fri Oct 5 19:57:08 2018 Return-Path: Delivered-To: freebsd-toolchain@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 EF36A10B50D7 for ; Fri, 5 Oct 2018 19:57:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 8C45A8E6E1 for ; Fri, 5 Oct 2018 19:57:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 4D6A610B50D4; Fri, 5 Oct 2018 19:57:07 +0000 (UTC) Delivered-To: toolchain@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 3BED410B50D3 for ; Fri, 5 Oct 2018 19:57:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D104A8E6DB for ; Fri, 5 Oct 2018 19:57:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 23A9A23D3C for ; Fri, 5 Oct 2018 19:57:06 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w95Jv6fp060666 for ; Fri, 5 Oct 2018 19:57:06 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w95Jv6w5060665 for toolchain@FreeBSD.org; Fri, 5 Oct 2018 19:57:06 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: toolchain@FreeBSD.org Subject: [Bug 230857] loading carp module panic i386 kernel (VIMAGE related) Date: Fri, 05 Oct 2018 19:57:06 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: panic, vimage X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: bz@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bz@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2018 19:57:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D230857 Bjoern A. Zeeb changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress --- Comment #4 from Bjoern A. Zeeb --- Ok, so the short explanation is that having a non-simple-type at the end of= the dpcpu or vnet linker sets and an intelligent compiler/linker combination can result in the last symbol not being relocated. In the case of i386/carp th= is was the PCPU stats glebius introduced which is an array of 16 pointers. I've spent a day to think of possible work around and the only one was to a= dd padding to the end of the section; with the help of arichardson managed to work my way around linker scripts and with an extra 8 hours I have a dual-s= tage linker-script solution which will only adjust the kernel modules which actu= ally do have a vnet_set or pcpu_set section and not create one in every module w= ith the size of 1 byte. I'll write the entire details up including sample code and the hacked up prototype solution and post it all here and in phab sometime the next days (possibly after the weekend). TODO: investigate which other architectures but i386 are possibly affected = by this as well. --=20 You are receiving this mail because: You are on the CC list for the bug.=