linux-kernel - Re: [PATCH -next] ia64/sn: fix percpu warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Oct 2009 15:43:26 +0100
From:	Tejun Heo <tj@...nel.org>
To:	"Luck, Tony" <tony.luck@...el.com>
CC:	Randy Dunlap <randy.dunlap@...cle.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
	"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
	LKML <linux-kernel@...r.kernel.org>,
	akpm <akpm@...ux-foundation.org>
Subject: Re: [PATCH -next] ia64/sn: fix percpu warnings

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.

Thanks.

-- 
tejun
--
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/