All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Steven Rostedt <rostedt@goodmis.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: Ingo Molnar <mingo@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Xunlei Pang <xlpang@redhat.com>
Subject: Re: [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero
Date: Fri, 04 Dec 2015 12:05:12 +1030	[thread overview]
Message-ID: <87lh9b573j.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20151203172428.600f380a@gandalf.local.home>

Steven Rostedt <rostedt@goodmis.org> writes:
> Xunlei Pang reported a bug in the scheduler code when
> CONFIG_CPUMASK_OFFSTACK is set, several of the cpumasks used by the
> root domains can contain garbage. The code does the following:
>
>         memset(rd, 0, sizeof(*rd));
>
>         if (!alloc_cpumask_var(&rd->span, GFP_KERNEL))
>                 goto out;
>         if (!alloc_cpumask_var(&rd->online, GFP_KERNEL))
>                 goto free_span;
>         if (!alloc_cpumask_var(&rd->dlo_mask, GFP_KERNEL))
>                 goto free_online;
>         if (!alloc_cpumask_var(&rd->rto_mask, GFP_KERNEL))
>                 goto free_dlo_mask;
>
> When CONFIG_CPUMASK_OFFSTACK is not defined, the four cpumasks are part
> of the 'rd' structure, and the memset() will zero them all out. But
> when CONFIG_CPUMASK_OFFSTACK is enabled, those cpumasks are no longer
> set by the memset() but are allocated independently. That allocation
> may contain garbage.
>
> In order to make alloc_cpumask_var() and friends behave the same with
> respect to being zero or not whether or not CONFIG_CPUMASK_OFFSTACK is
> defined, a check is made to the contents of the mask pointer. If the
> contents of the mask pointer is zero, it is assumed that the value was
> zeroed out before and __GFP_ZERO is added to the flags for allocation
> to make the returned cpumasks already zeroed.
>
> Calls to alloc_cpumask_var() are not done in performance critical
> paths, and even if they are, zeroing them out shouldn't add much
> overhead to it. The up side to this change is that we remove subtle
> bugs when enabling CONFIG_CPUMASK_OFFSTACK with cpumask logic that
> worked fined when that config was not enabled.

This is clever, but I would advise against such subtle code.  We will
never be able to remove this code once it is in.

Would suggest making the non-CPUMASK_OFFSTACK stubs write garbage into
the cpumasks instead, iff !(flags & __GFP_ZERO).

Cheers,
Rusty.




>
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> diff --git a/lib/cpumask.c b/lib/cpumask.c
> index 5a70f6196f57..c0d68752a8b9 100644
> --- a/lib/cpumask.c
> +++ b/lib/cpumask.c
> @@ -60,6 +60,19 @@ int cpumask_any_but(const struct cpumask *mask, unsigned int cpu)
>   */
>  bool alloc_cpumask_var_node(cpumask_var_t *mask, gfp_t flags, int node)
>  {
> +	/*
> +	 * When CONFIG_CPUMASK_OFFSTACK is not set, the cpumask may
> +	 * be zeroed by a memset of the structure that contains the
> +	 * mask. But if CONFIG_CPUMASK_OFFSTACK is then enabled,
> +	 * the mask may end up containing garbage. By checking
> +	 * if the pointer of the mask is already zero, we can assume
> +	 * that the mask itself should be allocated to contain all
> +	 * zeros as well. This will prevent subtle bugs by the
> +	 * inconsistency of the config being set or not.
> +	 */
> +	if ((long)*mask == 0)
> +		flags |= __GFP_ZERO;
> +
>  	*mask = kmalloc_node(cpumask_size(), flags, node);
>  
>  #ifdef CONFIG_DEBUG_PER_CPU_MAPS

  reply	other threads:[~2015-12-04  1:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-03 22:24 [RFC][PATCH] Add __GFP_ZERO to alloc_cpumask_var_node() if ptr is zero Steven Rostedt
2015-12-04  1:35 ` Rusty Russell [this message]
2015-12-04  2:37   ` Steven Rostedt
2015-12-04  7:34     ` Ingo Molnar
2015-12-04 20:30       ` Rusty Russell
2015-12-06 17:29         ` Ingo Molnar
2015-12-07  1:56           ` Rusty Russell
2015-12-07  8:23             ` 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=87lh9b573j.fsf@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.