mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Pranith Kumar <bobby.prani@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"maintainer:X86 ARCHITECTURE..." <x86@kernel.org>,
	Toshi Kani <toshi.kani@hp.com>,
	Igor Mammedov <imammedo@redhat.com>,
	David Rientjes <rientjes@google.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Lan Tianyu <tianyu.lan@intel.com>,
	"open list:X86 ARCHITECTURE..." <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH] smpboot: Check for successfull allocation of cpumask vars
Date: Tue, 9 Dec 2014 21:51:44 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.11.1412092150050.16275@nanos> (raw)
In-Reply-To: <CAJhHMCAORzK4Yc-DrEmFxwwyWwxWTCQzv1WKd1M6+YiEn9HKiA@mail.gmail.com>

On Tue, 9 Dec 2014, Pranith Kumar wrote:
> On Tue, Dec 9, 2014 at 3:10 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Tue, 9 Dec 2014, Pranith Kumar wrote:
> >> zalloc_cpumask_var() can return 0 on allocation failure when
> >> CONFIG_CPUMASK_OFFSTACK is set. Check for the return value and WARN() on failure
> >> of an allocation in such cases.
> >
> > And that warning helps in which way?
> >
> > It just prints a completely useless backtrace and breaks out of the
> > loop, but it does not prevent that later on code will trip over the
> > non allocated per cpu data.
> >
> 
> I agree. May be just a pr_warn() saying that an allocation failed perhaps?

Yep.
 
> To prevent further accesses, we can clear the cpu bit from the cpu
> masks(online/possible/present) for the failed cpu and continue trying
> to allocate for other cpus. We don't break out of the loop. Removing
> the cpu from the cpu masks will disable accesses of the non allocated
> per cpu data.
> 
> What do you suggest we do in such cases?

Pretty much what you said, but we should definitely break out of the
loop. There is no point to try more allocations if we failed the first
one.

Thanks,

	tglx

      reply	other threads:[~2014-12-09 20:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-09 16:03 Pranith Kumar
2014-12-09 20:10 ` Thomas Gleixner
2014-12-09 20:36   ` Pranith Kumar
2014-12-09 20:51     ` Thomas Gleixner [this message]

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=alpine.DEB.2.11.1412092150050.16275@nanos \
    --to=tglx@linutronix.de \
    --cc=bobby.prani@gmail.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=hpa@zytor.com \
    --cc=imammedo@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=rientjes@google.com \
    --cc=tianyu.lan@intel.com \
    --cc=toshi.kani@hp.com \
    --cc=x86@kernel.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

all inboxes | Powered by JetHome®