[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <5301D7AA020000780011CBE9@nat28.tlf.novell.com>
Date: Mon, 17 Feb 2014 08:34:34 +0000
From: "Jan Beulich" <JBeulich@...e.com>
To: "Petr Tesarik" <ptesarik@...e.cz>
Cc: "Borislav Petkov" <bp@...en8.de>, <x86@...nel.org>,
"Thomas Gleixner" <tglx@...utronix.de>,
"Ingo Molnar" <mingo@...hat.com>, <linux-kernel@...r.kernel.org>,
"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH] x86: Issue a warning if number of present CPUs >
maxcpus and CONFIG_HOTPLUG=n
>>> On 15.02.14 at 15:02, Petr Tesarik <ptesarik@...e.cz> wrote:
> --- a/arch/x86/kernel/smpboot.c
> +++ b/arch/x86/kernel/smpboot.c
> @@ -1226,9 +1226,6 @@ __init void prefill_possible_map(void)
> #ifdef CONFIG_HOTPLUG_CPU
> if (setup_max_cpus)
> possible += disabled_cpus;
> -#else
> - if (possible > i)
> - possible = i;
> #endif
> } else
> possible = setup_possible_cpus;
In between here total_cpus is being set, which now will get a
larger value if !HOTPLUG_CPU. Did you check that this has no
unintended side effect? And even if you did, it would still feel
more safe if you moved that line down after the capping point
below.
Similarly (but perhaps less important, albeit possibly slightly
confusing) the NR_CPUS related warning could now get issued
along with the warning below (when possible > nr_cpu_ids > i).
Hence that may better be moved down too (or then in effect
the if() block you modify below would get moved up). I realize
that two warning instead of just one would also be possible
without any change, so you're not really introducing some
entirely new inconsistency here...
Jan
> @@ -1246,7 +1243,7 @@ __init void prefill_possible_map(void)
> if (!setup_max_cpus)
> #endif
> if (possible > i) {
> - pr_warn("%d Processors exceeds max_cpus limit of %u\n",
> + pr_warn("%d Processors exceeds maxcpus limit of %u\n",
> possible, setup_max_cpus);
> possible = i;
> }
> --
> 1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists