[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081227095019.GA8248@elte.hu>
Date: Sat, 27 Dec 2008 10:50:19 +0100
From: Ingo Molnar <mingo@...e.hu>
To: David Howells <dhowells@...hat.com>
Cc: Sam Ravnborg <sam@...nborg.org>, Yinghai Lu <yinghai@...nel.org>,
Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
linux-next@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
mel@....ul.ie
Subject: Re: [BUG] next-20081216 - WARNING: at kernel/smp.c:333
smp_call_function_mask
* David Howells <dhowells@...hat.com> wrote:
> Sam Ravnborg <sam@...nborg.org> wrote:
>
> > I recall David Howells had a similar issue with the bootparamter patch set.
> > The workaround he used was to add a barrier(); call in the weak function
> > to avoid the inline.
>
> Yes I did. Rusty's solution was just to move the default weak functions into
> different files.
>
> Attempting to use the noinline attribute does not work.
>
> Of course, you could just stick the functions into lib/ in separate .c
> files and dispense with the weak attribute altogether.
the weak functions should be close to where the code that uses them is -
not somewhere separate (where no-one will really be aware of their
existence). So either we find a way to avoid such repeat bugs in the
future, or we do away with weak functions altogether and go back to
stone-age #ifdefs ;-)
I think we should get a Sparse check that detects empty void __weak
functions?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists