All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: zijun_hu <zijun_hu@zoho.com>
Cc: <linux-kernel@vger.kernel.org>, <zijun_hu@htc.com>,
	<tglx@linutronix.de>, <jason@lakedaemon.net>,
	<james.morse@arm.com>, <sudeep.holla@arm.com>
Subject: Re: [PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu()
Date: Fri, 15 Sep 2017 15:42:27 +0100	[thread overview]
Message-ID: <86bmmcqazw.fsf@arm.com> (raw)
In-Reply-To: <59BB4375.1030007@zoho.com> (zijun hu's message of "Fri, 15 Sep 2017 11:05:25 +0800")

On Fri, Sep 15 2017 at 11:05:25 am BST, zijun_hu <zijun_hu@zoho.com> wrote:
> On 09/15/2017 03:20 AM, Marc Zyngier wrote:
>> On Thu, Sep 14 2017 at  1:15:14 pm BST, zijun_hu <zijun_hu@zoho.com> wrote:
>>> From: zijun_hu <zijun_hu@htc.com>
>>>
>>> get_cpu_number() doesn't use existing helper to iterate over possible
>>> CPUs, so error happens in case of discontinuous @cpu_possible_mask
>>> such as 0b11110001.
>> 
>> Do you have an example of such a situation? Your patch is definitely an
>> improvement, but I'd like to understand how you get there...
>> 
>> Thanks,
>> 
>> 	M.
>> 
> a few conditions which maybe result in discontiguous @cpu_possible_mask
> are noticed and considered of by ARM64 init code as indicated by bellow code
> segments:
> in arch/arm64/kernel/smp.c :
> void __init smp_init_cpus(void) {
> ......
> 	/*
> 	 * We need to set the cpu_logical_map entries before enabling
> 	 * the cpus so that cpu processor description entries (DT cpu nodes
> 	 * and ACPI MADT entries) can be retrieved by matching the cpu hwid
> 	 * with entries in cpu_logical_map while initializing the cpus.
> 	 * If the cpu set-up fails, invalidate the cpu_logical_map entry.
> 	 */
> 	for (i = 1; i < nr_cpu_ids; i++) {
> 		if (cpu_logical_map(i) != INVALID_HWID) {
> 			if (smp_cpu_setup(i))
> 				cpu_logical_map(i) = INVALID_HWID;
> 		}
> 	}

Right. It is not so much that the CPU doesn't exist as I initially
thought (and couldn't really believe that it could happen), but rather
that the CPU may have failed to come up (which is slightly more likely).

Well spotted. Would you mind respinning it with a commit message that
outlines the condition under which this can happen? I'll the take it as
a fix post -rc1.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

      reply	other threads:[~2017-09-15 14:42 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-14  5:15 [PATCH 1/1] irqchip/gicv3: iterate over possible CPUs by for_each_possible_cpu() zijun_hu
2017-09-14 19:20 ` Marc Zyngier
2017-09-15  3:05   ` zijun_hu
2017-09-15 14:42     ` Marc Zyngier [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=86bmmcqazw.fsf@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=james.morse@arm.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sudeep.holla@arm.com \
    --cc=tglx@linutronix.de \
    --cc=zijun_hu@htc.com \
    --cc=zijun_hu@zoho.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.