linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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()'
Date: Tue, 8 Dec 2015 05:13:35 +0100	[thread overview]
Message-ID: <20151208041335.GA13474@gmail.com> (raw)
In-Reply-To: <20151208040903.GA31689@gmail.com>


* 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

  reply	other threads:[~2015-12-08  4:13 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-07  8:49 [PATCH 0/4] [RFC] cpumask: Robustify the var-cpumask allocation APIs Ingo Molnar
2015-12-07  8:49 ` [PATCH 1/4] cpumask: Migrate 'alloc_cpumask_var()' users to 'zalloc_cpumask_var()' Ingo Molnar
2015-12-08  1:28   ` Linus Torvalds
2015-12-08  4:09     ` Ingo Molnar
2015-12-08  4:13       ` Ingo Molnar [this message]
     [not found]         ` <CA+55aFyOXsv6uY3Dyc=i3SmwFD8XQYZeqzPXz36qzvdOD=gZSg@mail.gmail.com>
2015-12-16  0:26           ` Rusty Russell
2015-12-07  8:49 ` [PATCH 2/4] cpumask: Remove 'alloc_cpumask_var()' Ingo Molnar
2015-12-07  8:49 ` [PATCH 3/4] cpumask: Rename 'alloc_bootmem_cpumask_var()' to 'zalloc_bootmem_cpumask_var()' Ingo Molnar
2015-12-07  8:49 ` [PATCH 4/4] cpumask: Rename 'alloc_cpumask_var_node()' to '__alloc_cpumask_var_node()' Ingo Molnar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151208041335.GA13474@gmail.com \
    --to=mingo@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=xlpang@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).