From: Linus Torvalds <torvalds@linux-foundation.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Dietmar Eggemann" <dietmar.eggemann@arm.com>,
"Michel Dänzer" <michel@daenzer.net>,
"Ingo Molnar" <mingo@redhat.com>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: Random panic in load_balance() with 3.16-rc
Date: Wed, 23 Jul 2014 11:07:40 -0700 [thread overview]
Message-ID: <CA+55aFz9z=58iEj3qx4Oip=iPYxzgSaPe945Xzd8Z60_v1EEzQ@mail.gmail.com> (raw)
In-Reply-To: <CA+55aFwQSmBAs=QH9jAZz5JY7YFrDeuPH1RjFH+YKVr2NQM38g@mail.gmail.com>
On Wed, Jul 23, 2014 at 10:12 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> A cpumask_var is TOTALLY DIFFERENT. It's *either* a cpumask _or_ just
> a pointer to an externally allocated cpumask.
>
> sched_init() definitely does _not_ allocate a cpumask_var.
I take that back. It does end up allocating it properly, it just
avoids all the correct abstractions.
In general, the rule of thumb should be:
- stack allocations should use "cpumask_var_t cpus" and they
absolutely *have* to be paired with an "alloc_cpumask_var(&cpus,
GFP_KERNEL)". Having a "struct cpumask" on stack is very wrong.
- random single nonstack allocations should probably just use a plain
"struct cpumask" (or cpumask_t, but we really shouldn't use typedef's
unless they actively abstract some per-config *changing* type).
- dynamic allocations that are size-conscious (because there's a lot
of them) should allocate a "struct cpumask *" by using
"cpumask_size()". They have a pointer anyway, they allocate things
dynamically anyway, extra indirection through a cpumask_var_t would
just be unnecessary.
- *static* per-cpu allocations might want to use "cpumask_var_t" (to
avoid having a full "struct cpumask_t") along with doing a
"zalloc_cpumask_var_node(..)" for each cpu.
sched_init() follows that last pattern, except it open-codes that
zalloc_cpumask_var_node() in an odd way that confused me.
So I take my patch back. It's wrong, because it only allocates that
cpumask_size() if CONFIG_CPUMASK_OFFSTACK is true.
Ugh, that code really is unreadable.
Linus
next prev parent reply other threads:[~2014-07-23 18:07 UTC|newest]
Thread overview: 83+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53C77BB8.6030804@daenzer.net>
2014-07-17 7:58 ` Random panic in load_balance() with 3.16-rc Peter Zijlstra
2014-07-18 9:29 ` Michel Dänzer
2014-07-22 6:13 ` Michel Dänzer
2014-07-23 3:53 ` Michel Dänzer
2014-07-23 4:21 ` Linus Torvalds
2014-07-23 6:49 ` Peter Zijlstra
2014-07-23 8:05 ` Michel Dänzer
2014-07-23 8:28 ` Peter Zijlstra
2014-07-23 9:25 ` Peter Zijlstra
2014-07-23 9:31 ` Michel Dänzer
2014-07-23 9:45 ` Dietmar Eggemann
2014-07-23 11:11 ` Peter Zijlstra
2014-07-23 11:30 ` Peter Zijlstra
2014-07-23 14:24 ` Peter Zijlstra
2014-07-23 14:38 ` Michel Dänzer
2014-07-23 15:51 ` Linus Torvalds
[not found] ` <20140723155526.GW3935@laptop>
2014-07-23 16:54 ` Linus Torvalds
2014-07-23 17:03 ` Peter Zijlstra
2014-07-23 17:12 ` Linus Torvalds
2014-07-23 17:26 ` Linus Torvalds
2014-07-23 18:25 ` Peter Zijlstra
2014-07-23 18:35 ` Linus Torvalds
2014-07-23 18:41 ` Peter Zijlstra
2014-07-23 18:55 ` Linus Torvalds
2014-07-23 19:02 ` Peter Zijlstra
2014-07-23 19:20 ` Linus Torvalds
2014-07-24 1:43 ` Michel Dänzer
2014-07-24 18:47 ` Linus Torvalds
2014-07-24 18:59 ` Peter Zijlstra
2014-07-25 1:25 ` Michel Dänzer
2014-07-25 2:33 ` Linus Torvalds
2014-07-25 2:50 ` Nick Krause
2014-07-25 2:36 ` Nick Krause
2014-07-25 3:55 ` Alexei Starovoitov
2014-07-25 4:00 ` Nick Krause
2014-07-25 14:02 ` Steven Rostedt
2014-07-25 18:29 ` Linus Torvalds
2014-07-25 19:10 ` Steven Rostedt
2014-07-25 20:01 ` Linus Torvalds
2014-07-25 20:13 ` Steven Rostedt
2014-07-25 21:25 ` Jakub Jelinek
2014-07-26 18:28 ` Linus Torvalds
2014-07-26 18:39 ` Linus Torvalds
2014-07-26 19:35 ` Markus Trippelsdorf
2014-07-26 19:55 ` Theodore Ts'o
2014-07-26 20:20 ` Markus Trippelsdorf
2014-07-26 22:08 ` Jakub Jelinek
2014-07-26 19:56 ` Linus Torvalds
2014-07-26 20:03 ` Linus Torvalds
2014-07-26 20:19 ` Markus Trippelsdorf
2014-07-26 20:39 ` Linus Torvalds
2014-07-28 12:26 ` Frank Ch. Eigler
2014-07-28 13:10 ` Theodore Ts'o
2014-07-28 14:11 ` Frank Ch. Eigler
2014-07-28 16:45 ` Linus Torvalds
2014-07-28 17:27 ` Alexei Starovoitov
2014-07-28 18:09 ` Markus Trippelsdorf
2014-07-28 18:28 ` Linus Torvalds
2014-07-28 18:41 ` Markus Trippelsdorf
2014-07-29 8:58 ` Jakub Jelinek
2014-07-28 19:50 ` Theodore Ts'o
2014-07-28 3:47 ` Michel Dänzer
2014-07-28 16:48 ` Linus Torvalds
2014-07-29 2:29 ` Michel Dänzer
2014-08-05 3:19 ` Steven Rostedt
2014-07-26 18:02 ` Steven Chamberlain
2014-07-29 9:20 ` Michel Dänzer
2014-07-25 6:48 ` Jakub Jelinek
2014-07-25 8:15 ` Linus Torvalds
2014-07-25 9:03 ` Michel Dänzer
2014-07-25 9:21 ` Markus Trippelsdorf
2014-07-25 9:42 ` Markus Trippelsdorf
2014-07-23 18:07 ` Linus Torvalds [this message]
2014-07-23 18:31 ` Peter Zijlstra
2014-07-23 18:24 ` Peter Zijlstra
2014-07-23 17:04 ` Peter Zijlstra
2014-07-23 17:15 ` Linus Torvalds
2014-07-23 18:25 ` Peter Zijlstra
2014-07-23 18:23 ` Peter Zijlstra
2014-07-23 10:52 ` Peter Zijlstra
2014-07-24 7:18 ` Michel Dänzer
2014-07-24 7:51 ` Peter Zijlstra
2014-07-24 9:55 ` Peter Zijlstra
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='CA+55aFz9z=58iEj3qx4Oip=iPYxzgSaPe945Xzd8Z60_v1EEzQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=dietmar.eggemann@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=michel@daenzer.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
/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).