From: Rusty Russell <rusty@rustcorp.com.au>
To: Mike Travis <travis@sgi.com>
Subject: Dangerous code in cpumask_of_cpu?
Date: Tue, 8 Jul 2008 18:16:40 +1000
User-Agent: KMail/1.9.9
Cc: linux-kernel@vger.kernel.org, "H. Anvin" <hpa@zytor.com>,
       Christoph Lameter <clameter@sgi.com>, Ingo Molnar <mingo@elte.hu>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200807081816.40623.rusty@rustcorp.com.au>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1279
Lines: 36

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