linux-kernel - Re: [PATCH 1/4] cpumask: Migrate 'alloc_cpumask_var()' users to 'zalloc_cpumask

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20151208041335.GA13474@gmail.com>
Date:	Tue, 8 Dec 2015 05:13:35 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Peter Zijlstra <peterz@...radead.org>,
	Sergey Senozhatsky <sergey.senozhatsky@...il.com>,
	Xunlei Pang <xlpang@...hat.com>,
	Rik van Riel <riel@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH 1/4] cpumask: Migrate 'alloc_cpumask_var()' users to
 'zalloc_cpumask_var()'


* Ingo Molnar <mingo@...nel.org> wrote:

> * Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > On Mon, Dec 7, 2015 at 12:49 AM, Ingo Molnar <mingo@...nel.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/