lkml.org 
[lkml]   [2008]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Dangerous code in cpumask_of_cpu?
Date
Johannes Weiner <hannes@saeurebad.de> writes:

> Hi,
>
> Rusty Russell <rusty@rustcorp.com.au> writes:
>
>> Hi Christoph/Mike,
>>
>> Looked at cpumask_of_cpu as introduced in
>> 9f0e8d0400d925c3acd5f4e01dbeb736e4011882 (x86: convert cpumask_of_cpu macro
>> to allocated array), and I don't think it's safe:
>>
>> #define cpumask_of_cpu(cpu) \
>> (*({ \
>> typeof(_unused_cpumask_arg_) m; \
>> if (sizeof(m) == sizeof(unsigned long)) { \
>> m.bits[0] = 1UL<<(cpu); \
>> } else { \
>> cpus_clear(m); \
>> cpu_set((cpu), m); \
>> } \
>> &m; \
>> }))
>>
>> Referring to &m once out of scope is invalid, and I can't find any evidence
>> that it's legal here. In particular, the change
>> b53e921ba1cff8453dc9a87a84052fa12d5b30bd (generic: reduce stack pressure in
>> sched_affinity) which passes &m to other functions seems highly risky.
>>
>> I'm surprised this hasn't already hit us, but perhaps gcc isn't as clever as
>> it could be?
>
> You don't refer to &m outside scope. Look at the character below the
> first e of #define :)

The scope of m ends with the outmost braces, and the dereference is done
outside of it.

Andreas.

--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2008-07-08 12:27    [W:0.054 / U:3.156 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site