Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758958AbcK3UxP (ORCPT ); Wed, 30 Nov 2016 15:53:15 -0500 Received: from lb3-smtp-cloud6.xs4all.net ([194.109.24.31]:53444 "EHLO lb3-smtp-cloud6.xs4all.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755187AbcK3Uwe (ORCPT ); Wed, 30 Nov 2016 15:52:34 -0500 Message-ID: <1480539150.27962.11.camel@tiscali.nl> Subject: Re: Odd build breakage in 4.9-rc7 From: Paul Bolle To: Jarod Wilson Cc: Tony Luck , Linus Torvalds , Prarit Bhargava , linux-kernel@vger.kernel.org Date: Wed, 30 Nov 2016 21:52:30 +0100 In-Reply-To: <20161130172435.GG8563@redhat.com> References: <20161130172435.GG8563@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.20.5 (3.20.5-1.fc24) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1844 Lines: 43 On Wed, 2016-11-30 at 12:24 -0500, Jarod Wilson wrote: > Up second, once we're past the above, building modules goes splat: > > ----8<---- > $ make -s ARCH=x86_64 V=1 -j8 modules > ... > ERROR: "module_put" [virt/lib/irqbypass.ko] undefined! > ERROR: "mutex_unlock" [virt/lib/irqbypass.ko] undefined! > ERROR: "mutex_lock" [virt/lib/irqbypass.ko] undefined! > ... > ----8<---- > > There are similar ERROR lines to the tune of 145k lines of output, > basically for every single module and symbol in the build. This breakage > was bisected to commit cd3caefb4663e3811d37cc2afad3cce642d60061, which > looks fairly innocuous, but when reverted, builds work fine again. I ran into a modules build printing over 100K ERROR lines a month ago: https://lkml.kernel.org/r/<1478165881-9263-1-git-send-email-pebolle@tiscali.nl> That had to do with setting TRIM_UNUSED_KSYMS and so unsetting UNUSED_SYMBOLS, as far as I could tell. Did you perhaps also have UNUSED_SYMBOLS unset when your modules build when splat? And did your bzImage build by any chance print this (to stderr):     sed: can't read .tmp_versions/*.mod: No such file or directory If so I might have run into your second issue a month ago already, which makes your bisect to commit cd3caefb4663 ("Fix subtle CONFIG_MODVERSIONS problems") suspect. Or did that bisect not cover the second issue? > Multi-threaded make vs. single-threaded doesn't matter, setting > CONFIG_BROKEN=y or '# CONFIG_MODVERSIONS is not set' don't make a > difference, and interestingly, if instead of split 'make bzImage' and > 'make modules', I just do a single 'make', then things DO build > successfully, so I'm a wee bit baffled as to what's actually going on > here. Likewise (ie, both the modules splat going away if doing a single make and being baffled, but more that a wee bit). Paul Bolle