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
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 :)

But then, this code should probably just evaluate to m without this
obscure *(&m) construct.

Hannes


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