Re: [PATCH 1/4] cpumask: Migrate 'alloc_cpumask_var()' users to 'zalloc_cpumask_var()'

[Ingo Molnar]

* Ingo Molnar <mingo@xxxxxxxxxx> wrote:

> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Mon, Dec 7, 2015 at 12:49 AM, Ingo Molnar <mingo@xxxxxxxxxx> wrote:
> >
> > > Xunlei Pang reported a scheduler bug in init_rootdomain(), which is caused 
> > > by improper use of alloc_cpumask_var(), which results in uninitialized 
> > > cpumasks being allocated.
> > >
> > > No-one noticed this scheduler bug for a long time, probably because 
> > > alloc_cpumask_var() does result in initialized cpumasks in the 
> > > !CPUMASK_OFFSTACK case - which is the vast majority of systems out there.
> > >
> > > So migrate all alloc_cpumask_var() users over to zalloc_cpumask_var(), to be 
> > > on the safe side.
> > 
> > Ugh. I'd rather just see us say that "allocating a cpumask always returns a 
> > zeroed mask".
> > 
> > There really is no reason to ever not zero it (they aren't _that_ big even on 
> > huge machines), so I'd rather just get rid of the "zalloc" version that is the 
> > less common one anyway.
> 
> Sure - that was my original suggestion, will reshape the series to do it like 
> that.

One question: I'll remove all the non-zeroing variants, but would you be fine with 
keeping the 'zalloc' naming? That's consistent with other allocation API patterns 
across the kernel. There won't be any unsafe API left.

Thanks,

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/