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
next prev parent 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).