From: Tejun Heo <tj@kernel.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
akpm <akpm@linux-foundation.org>, Sam Ravnborg <sam@ravnborg.org>,
Andreas Gruenbacher <agruen@suse.de>,
Jan Beulich <JBeulich@novell.com>
Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings
Date: Thu, 29 Oct 2009 15:43:14 +0000 [thread overview]
Message-ID: <4AE9B812.2080307@kernel.org> (raw)
In-Reply-To: <4AE9AA0E.5070104@kernel.org>
Yiee... lexer/parser problem in genksyms. cc'ing Andreas, Sam and Jan
for help and quoting whole body.
Hello,
Tejun Heo wrote:
> Hello,
>
> Luck, Tony wrote:
>> Ok. x86 doesn't see this because the defconfig has
>> CONFIG_MODVERSIONS is not set
>>
>> If I turn MODVERSION off, then the problem disappears for me.
>>
>> If I turn MODVERSIONS on for x86 (and fudge a driver to make use of
>> softirq_work_list), then x86 gets the CRC warning too.
>
> Right, I can reproduce it here too.
>
>> So this isn't a tool chain problem. Neither x86 nor ia64
>> can handle exported per-cpu array objects when CONFIG_MODVERSIONS
>> is set.
>>
>> Looking at the __crc symbols in the vmlinux for x86 with
>> CONFIG_MODVERSIONS=y I see:
>>
>> 000000006dcaeb88 A __crc_per_cpu__kernel_stack
>> 00000000b3994c7a A __crc_per_cpu__kstat
>> 00000000d917c158 A __crc_per_cpu__node_number
>> w __crc_per_cpu__softirq_work_list
>> 0000000036a1f502 A __crc_per_cpu__softnet_data
>> 0000000057adf756 A __crc_per_cpu__this_cpu_off
>>
>> which explains why "modpost" is unable to find a CRC.
>>
>> Maybe the comments in <linux/module.h> are supposed to be a
>> clue? :
>>
>> #ifdef CONFIG_MODVERSIONS
>> /* Mark the CRC weak since genksyms apparently decides not to
>> * generate a checksums for some symbols */
>> #define __CRC_SYMBOL(sym, sec) \
>> extern void *__crc_##sym __attribute__((weak)); \
>> static const unsigned long __kcrctab_##sym \
>> __used \
>> __attribute__((section("__kcrctab" sec), unused)) \
>> = (unsigned long) &__crc_##sym;
>>
>> But not enough of a clue for me :-(
>
> I have no idea either. I'll dig a bit and try to find out what's
> going on.
So, the problem is that genksyms can't understand the following.
__typeof__(int [10]) my_ar;
EXPORT_SYMBOL(my_ar);
Would it be difficult to teach it how to parse it?
Thanks.
--
tejun
WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
"linux-ia64@vger.kernel.org" <linux-ia64@vger.kernel.org>,
"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
akpm <akpm@linux-foundation.org>, Sam Ravnborg <sam@ravnborg.org>,
Andreas Gruenbacher <agruen@suse.de>,
Jan Beulich <JBeulich@novell.com>
Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings
Date: Thu, 29 Oct 2009 16:43:14 +0100 [thread overview]
Message-ID: <4AE9B812.2080307@kernel.org> (raw)
In-Reply-To: <4AE9AA0E.5070104@kernel.org>
Yiee... lexer/parser problem in genksyms. cc'ing Andreas, Sam and Jan
for help and quoting whole body.
Hello,
Tejun Heo wrote:
> Hello,
>
> Luck, Tony wrote:
>> Ok. x86 doesn't see this because the defconfig has
>> CONFIG_MODVERSIONS is not set
>>
>> If I turn MODVERSION off, then the problem disappears for me.
>>
>> If I turn MODVERSIONS on for x86 (and fudge a driver to make use of
>> softirq_work_list), then x86 gets the CRC warning too.
>
> Right, I can reproduce it here too.
>
>> So this isn't a tool chain problem. Neither x86 nor ia64
>> can handle exported per-cpu array objects when CONFIG_MODVERSIONS
>> is set.
>>
>> Looking at the __crc symbols in the vmlinux for x86 with
>> CONFIG_MODVERSIONS=y I see:
>>
>> 000000006dcaeb88 A __crc_per_cpu__kernel_stack
>> 00000000b3994c7a A __crc_per_cpu__kstat
>> 00000000d917c158 A __crc_per_cpu__node_number
>> w __crc_per_cpu__softirq_work_list
>> 0000000036a1f502 A __crc_per_cpu__softnet_data
>> 0000000057adf756 A __crc_per_cpu__this_cpu_off
>>
>> which explains why "modpost" is unable to find a CRC.
>>
>> Maybe the comments in <linux/module.h> are supposed to be a
>> clue? :
>>
>> #ifdef CONFIG_MODVERSIONS
>> /* Mark the CRC weak since genksyms apparently decides not to
>> * generate a checksums for some symbols */
>> #define __CRC_SYMBOL(sym, sec) \
>> extern void *__crc_##sym __attribute__((weak)); \
>> static const unsigned long __kcrctab_##sym \
>> __used \
>> __attribute__((section("__kcrctab" sec), unused)) \
>> = (unsigned long) &__crc_##sym;
>>
>> But not enough of a clue for me :-(
>
> I have no idea either. I'll dig a bit and try to find out what's
> going on.
So, the problem is that genksyms can't understand the following.
__typeof__(int [10]) my_ar;
EXPORT_SYMBOL(my_ar);
Would it be difficult to teach it how to parse it?
Thanks.
--
tejun
next prev parent reply other threads:[~2009-10-29 15:43 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-14 5:34 linux-next: Tree for October 14 Stephen Rothwell
2009-10-14 15:55 ` Randy Dunlap
2009-10-14 21:12 ` Stephen Rothwell
2009-10-14 22:10 ` [PATCH -next] ia64/sn: fix percpu warnings Randy Dunlap
2009-10-14 22:10 ` Randy Dunlap
2009-10-15 1:33 ` Tejun Heo
2009-10-15 1:33 ` Tejun Heo
2009-10-26 18:24 ` Tony Luck
2009-10-26 18:24 ` Tony Luck
2009-10-26 23:35 ` Luck, Tony
2009-10-26 23:35 ` Luck, Tony
2009-10-28 15:03 ` Tejun Heo
2009-10-28 15:03 ` Tejun Heo
2009-10-28 16:24 ` Luck, Tony
2009-10-28 16:24 ` Luck, Tony
2009-10-28 16:37 ` Tejun Heo
2009-10-28 16:37 ` Tejun Heo
2009-10-28 16:58 ` Luck, Tony
2009-10-28 16:58 ` Luck, Tony
2009-10-28 22:23 ` Luck, Tony
2009-10-28 22:23 ` Luck, Tony
2009-10-29 14:43 ` Tejun Heo
2009-10-29 14:43 ` Tejun Heo
2009-10-29 15:43 ` Tejun Heo [this message]
2009-10-29 15:43 ` Tejun Heo
2009-10-30 16:05 ` Jan Beulich
2009-10-15 1:17 ` [PATCH -next] vmxnet: fix 2 build problems Randy Dunlap
2009-10-15 1:17 ` Randy Dunlap
2009-10-15 2:00 ` [Pv-drivers] " Bhavesh Davda
2009-10-15 2:00 ` Bhavesh Davda
2009-10-15 3:39 ` David Miller
-- strict thread matches above, loose matches on Subject: below --
2009-10-14 22:10 [PATCH -next] kvm: fix ia64 printk formats Randy Dunlap
2009-10-14 22:10 ` Randy Dunlap
2009-10-15 2:32 ` Zhang, Xiantao
2009-10-15 2:32 ` Zhang, Xiantao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AE9B812.2080307@kernel.org \
--to=tj@kernel.org \
--cc=JBeulich@novell.com \
--cc=agruen@suse.de \
--cc=akpm@linux-foundation.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=sam@ravnborg.org \
--cc=sfr@canb.auug.org.au \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.