From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932537AbbLHENl (ORCPT <rfc822;w@1wt.eu>);
	Mon, 7 Dec 2015 23:13:41 -0500
Received: from mail-wm0-f49.google.com ([74.125.82.49]:36112 "EHLO
	mail-wm0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1755811AbbLHENj (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Mon, 7 Dec 2015 23:13:39 -0500
Date: Tue, 8 Dec 2015 05:13:35 +0100
From: Ingo Molnar <mingo@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Rusty Russell <rusty@rustcorp.com.au>,
        Peter Zijlstra <peterz@infradead.org>,
        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
        Xunlei Pang <xlpang@redhat.com>, Rik van Riel <riel@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH 1/4] cpumask: Migrate 'alloc_cpumask_var()' users to
 'zalloc_cpumask_var()'
Message-ID: <20151208041335.GA13474@gmail.com>
References: <1449478184-27168-1-git-send-email-mingo@kernel.org>
 <1449478184-27168-2-git-send-email-mingo@kernel.org>
 <CA+55aFydR-Tzp4KAQsZ5-19E8dFO_QoOmAZ3FzGF=Vo+8mJCNg@mail.gmail.com>
 <20151208040903.GA31689@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20151208040903.GA31689@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


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

> * Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> > On Mon, Dec 7, 2015 at 12:49 AM, Ingo Molnar <mingo@kernel.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