linux-kernel - Re: linux-next: build failure

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]

Message-ID: <488F2A50.5060107@sgi.com>
Date:	Tue, 29 Jul 2008 07:33:52 -0700
From:	Mike Travis <travis@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	David Miller <davem@...emloft.net>, linux-next@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus <torvalds@...ux-foundation.org>
Subject: Re: linux-next: build failure

Mike Travis wrote:
> Ingo Molnar wrote:
>> * KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com> wrote:
>>
>>>> * Stephen Rothwell <sfr@...b.auug.org.au> wrote:
>>>>
>>>>> Hi Ingo,
>>>>>
>>>>> On Tue, 29 Jul 2008 10:00:55 +0200 Ingo Molnar <mingo@...e.hu> wrote:
>>>>>>> -#define cpumask_of_cpu(cpu) ({ *get_cpu_mask(cpu); })
>>>>>>> +#define cpumask_of_cpu(cpu) (*get_cpu_mask(cpu))
>>>>>> hm, i'm wondering - is this a compiler bug?
>>>>> Or maybe a deficiency in such an old compiler (v3.4.5) but the fix 
>>>>> makes sense anyway, right?
>>>> yeah, i was just wondering.
>>> in linux/README
>>>
>>> COMPILING the kernel:
>>>
>>>  - Make sure you have at least gcc 3.2 available.
>>>    For more information, refer to Documentation/Changes.
>>>
>>> So, if 3.4.5 is old, Should we change readme?
>> the fix is simple enough.
>>
>> but the question is, wont it generate huge artificial stackframes with 
>> CONFIG_MAXSMP and NR_CPUS=4096? Maybe it is unable to figure out and 
>> simplify the arithmetics there - or something like that.
>>
>> 	Ingo
> 
> I've looked at stack frames quite extensively and usually they are
> not generated unless you explicitly use a named cpumask variable,
> pass a cpumask by value, expect a cpumask function return, create
> an initializer that contains a cpumask field, and (probably a couple
> more I missed).
> 
> Almost all others are done efficiently via pointers or simple
> struct copies:
> 
> 	cpus_xxx(*cpumask_of_cpu(), ...
> 	struct->cpumask_var = *cpumask_of_cpu()
> 	global_cpumask_var = *cpumask_of_cpu()
> 	etc.
> 
> Thanks,
> Mike

Geez, I edited the above after I first used *cpumask_var and didn't
get the semantics right!

 	cpus_xxx(cpumask_of_cpu(), ...
 	struct->cpumask_var = cpumask_of_cpu()
 	global_cpumask_var = cpumask_of_cpu()

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