lkml.org 
[lkml]   [2008]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectDangerous code in cpumask_of_cpu?
Date
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?

I don't know what the right answer is, but we might need to go to a pool of
cpumask_ts, a get_cpumask_of_cpu() which can sleep and a put_cpumask_of_cpu?

Or maybe a gcc guru can refute this?
Rusty.


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