Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756688AbYLaSZQ (ORCPT ); Wed, 31 Dec 2008 13:25:16 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756062AbYLaSZD (ORCPT ); Wed, 31 Dec 2008 13:25:03 -0500 Received: from accolon.hansenpartnership.com ([76.243.235.52]:51210 "EHLO accolon.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755921AbYLaSZB (ORCPT ); Wed, 31 Dec 2008 13:25:01 -0500 Subject: Re: [PATCH] parisc: fix module loading failure of large kernel modules (take 4) From: James Bottomley To: Linus Torvalds Cc: Helge Deller , Rusty Russell , linux-parisc , Linux Kernel Development , Kyle McMartin , Randolph Chung , Andrew Morton , Sam Ravnborg , John David Anglin In-Reply-To: References: <4959346E.7060600@gmx.de> <200812310915.41693.rusty@rustcorp.com.au> <495B5806.3080505@gmx.de> Content-Type: text/plain Date: Wed, 31 Dec 2008 12:24:56 -0600 Message-Id: <1230747896.3408.112.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 (2.22.3.1-1.fc9) Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1926 Lines: 44 On Wed, 2008-12-31 at 09:29 -0800, Linus Torvalds wrote: > > On Wed, 31 Dec 2008, Helge Deller wrote: > > > > [PATCH 1/2] module.c: fix module loading failure of large kernel modules > > > > When creating the final layout of a kernel module in memory, allow the > > module loader to reserve some additional memory in front of a given section. > > This is currently only needed for the parisc port which needs to put the > > stub entries there to fulfill the 17/22bit PCREL relocations with large > > kernel modules like xfs. > > > > Differences of this patch to previous versions: > > - added weak funtion arch_module_section_size() > > This doesn't work. > > We've had this bug several times now, and one of them just very recently. > > Some gcc versions will inline weak functions if they are in scope - even > if there is a non-weak function somewhere else. So you MUST NOT have the > weak definition in the same file (or indirectly called through some inline > functions in a header file) as the call. Because if you do, then any user > with the wrong version of gcc will get the weak function semantics, even > if it was meant to be overridden by something else. Um, but we got told to use all these weak functions instead of the ARCH_HAS... defines. They certainly litter the x86 boot code. The standard pattern was to put the weak function in the file where it was used, which is what you're now saying will miscompile. Which gcc versions are the problem? Because it's going to be a bit painful catching and killing all the problems ... it might be better just to patch the master kernel makefile to refuse to build with the offending gcc versions. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/