linux-kernel - Re: [PATCH v5 0/5] x86: Cleanup and simplify cpu-specific data

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-next>] [day] [month] [year] [list]

Date:	Thu, 26 Apr 2012 14:21:40 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Kevin Winchester <kjwinchester@...il.com>
CC:	Nick Bowler <nbowler@...iptictech.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org,
	Randy Dunlap <rdunlap@...otime.net>,
	Borislav Petkov <bp@...en8.de>
Subject: Re: [PATCH v5 0/5] x86: Cleanup and simplify cpu-specific data

Against mainline would be better, unless it actively conflicts with something in tip.

Kevin Winchester <kjwinchester@...il.com> wrote:

>On Apr 26, 2012 4:49 PM, "H. Peter Anvin" <hpa@...or.com> wrote:
>>
>> On 03/28/2012 03:43 PM, Kevin Winchester wrote:
>> > Various per-cpu fields are define in arch/x86/kernel/smpboot.c that
>are
>> > basically equivalent to the cpu-specific data in struct
>cpuinfo_x86.
>> > By moving these fields into the structure, a number of codepaths
>can be
>> > simplified since they no longer need to care about those fields not
>> > existing on !SMP builds.
>> >
>> > The size effects on allno (UP) and allyes (MAX_SMP) kernels are as
>> > follows:
>> >
>> > text      data      bss             dec        hex      filename
>> >  1369227    181536   1399180    2949943   2d0337 
>vmlinux.i386.allno
>> >  1370216    181600   1399012    2950828         2d06ac
> vmlinux.i386.allno.after
>> >  1608231    310968    505088    2424287   24fddf 
>vmlinux.x86_64.allno
>> >  1609232    311032    504896    2425160   250148
> vmlinux.x86_64.allno.after
>> > 97643748   6891747  34668544  139204039  84c15c7 
>vmlinux.i386.allyes
>> > 97643582   6892011  34668544  139204137  84c1629
> vmlinux.i386.allyes.after
>> > 85869519  13567071  44511232  143947822  894782e 
>vmlinux.x86_64.allyes
>> > 85869134  13568607  44511232  143948973  8947cad
> vmlinux.x86_64.allyes.after
>> >
>> > As can be seen, the kernels get slighly larger, but the code
>reduction/
>> > simplification should be enough to compensate for it.
>> >
>> > Changes in v5:
>> > - Reduced the number of files affected in the patchset by keeping
>helper
>> > functions in arch/x86/include/asm/smp.h
>> > - Rebased to latest tip/master
>> >
>> > Kevin Winchester (5):
>> >   x86: Move per cpu cpu_llc_shared_map to a field in struct
>cpuinfo_x86
>> >   x86: Move per cpu cpu_llc_id to a field in struct cpuinfo_x86
>> >   x86: Move per cpu cpu_sibling_map to a field in struct
>cpuinfo_x86
>> >   x86: Move per cpu cpu_core_map to a field in struct cpuinfo_x86
>> >   x86: Remove #ifdef CONFIG_SMP sections by moving smp_num_siblings
>> >     into common.c
>> >
>>
>> I applied this patchset on top of v3.4-rc4 (to get a clean topic
>branch)
>> and ran into the following build problems:
>>
>> i386 "allnoconfig":
>>
>> /home/hpa/kernel/tip.x86-cpu/arch/x86/kernel/process.c: In function
>> ‘select_idle_routine’:
>> /home/hpa/kernel/tip.x86-cpu/arch/x86/kernel/process.c:679:30: error:
>> ‘smp_num_siblings’ undeclared (first use in this function)
>> /home/hpa/kernel/tip.x86-cpu/arch/x86/kernel/process.c:679:30: note:
>> each undeclared identifier is reported only once for each function it
>> appears in
>>
>> i386 "allyesconfig" and "allmodconfig":
>>
>> /home/hpa/kernel/tip.x86-cpu/drivers/cpufreq/speedstep-ich.c: In
>> function ‘speedstep_cpu_init’:
>> /home/hpa/kernel/tip.x86-cpu/drivers/cpufreq/speedstep-ich.c:337:2:
>> error: incompatible type for argument 2 of ‘cpumask_copy’
>> /home/hpa/kernel/tip.x86-cpu/include/linux/cpumask.h:483:20: note:
>> expected ‘const struct cpumask *’ but argument is of type ‘cpumask_t’
>>
>> I will try it again against tip:master, but it looks to have the same
>> problems.
>>
>
>I'm pretty sure I tested at least some of those configurations, so
>maybe
>something has changed since I last tried it against tip/master. I'll
>rebase
>and fix up - would you prefer the series against mainline or tip?
>
>Kevin

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.
--
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/