Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp987911imm; Mon, 21 May 2018 18:48:32 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoBCu//xVsVfpL+DAqrv5ypXqZkrsvzBw18oUTgaoY9Sjt19ldtLLXm0+VXoa7q5YPrumPp X-Received: by 2002:a62:d38f:: with SMTP id z15-v6mr22244233pfk.100.1526953712358; Mon, 21 May 2018 18:48:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1526953712; cv=none; d=google.com; s=arc-20160816; b=AEipGIQ38ybQuNdSD7e/V7ZC/TKDmih/qkJTQq9rhiMUubi1rwn13DZRupXZvxJqPT cvYaIjAYJpiRJonWkCGh91o01chwBLwl9DliSL4S7xq4bso61sW3ZxYgIEI3TBX4Gcey NAFVkDvwuR7DpOwr5V9cqd6r72DDJ4HP2c/ZMUv/Dn8uE53NrxVjpDHMZFkqWxP+QcR/ mKg0WIPrs54q8u8lY0GxGPwtj8wF77QP7A8jq+3Wt2UNV26rq/KS/bu58IpkCE5X/dxR fp09MAgnzs1aeAOjgpiGMCiuPFwU23IW51MwhMCa2ZalM0lG6EwHmKO7c0J/RStqKUyL 27Kw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=iRuf5PCKXJ8WWyy3pxr7eoAHvx/HJhFeuXE5QLLXhkE=; b=AJvQTbkvkAyioEV+SnR3B0Mu+9kovh35J4RebexZ1gXZUS05+NYTmgxz+4mUQ9s6cr QzXwpN27GHU2MDT0jDs8VDlbazTfLtv09DQEQ6T/hce6lVSUdVF7lOWnhXO9wF1+Ar05 LaMjg/+rluErb4H8cgLQvVKYCrdkPzSKuAuJfcVTA/zgX/65byhF458gVFFjyh3P3hf8 3WndCitVKRKcqwBAy3fnpo74jlXQVyuXWdgu3Ej6/8fMXDqvQ+Cm73MhUyO6Wl8wSAkR OTa3WjWFvq4JTBCiBzNqkR6a/wElDXAgadfAgjrvkv32ntvyUO2Wvx57/rIWGlU03Aoi LZHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m32-v6si15191198pld.438.2018.05.21.18.48.17; Mon, 21 May 2018 18:48:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752186AbeEVBrt (ORCPT + 99 others); Mon, 21 May 2018 21:47:49 -0400 Received: from mail.cn.fujitsu.com ([183.91.158.132]:33009 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751505AbeEVBrp (ORCPT ); Mon, 21 May 2018 21:47:45 -0400 X-IronPort-AV: E=Sophos;i="5.43,368,1503331200"; d="scan'208";a="40185578" Received: from localhost (HELO cn.fujitsu.com) ([10.167.33.5]) by heian.cn.fujitsu.com with ESMTP; 22 May 2018 09:47:43 +0800 Received: from G08CNEXCHPEKD03.g08.fujitsu.local (unknown [10.167.33.85]) by cn.fujitsu.com (Postfix) with ESMTP id 2137248AE92A; Tue, 22 May 2018 09:47:40 +0800 (CST) Received: from localhost.localdomain (10.167.226.106) by G08CNEXCHPEKD03.g08.fujitsu.local (10.167.33.89) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 22 May 2018 09:47:38 +0800 Subject: Re: [PATCH 4/5] acpi/processor: Fix the return value of acpi_processor_ids_walk() To: Thomas Gleixner CC: LKML , , , , Ingo Molnar , Jonathan Corbet , "Rafael J. Wysocki" , Len Brown , "H. Peter Anvin" , Peter Zijlstra References: <20180320110432.28127-1-douly.fnst@cn.fujitsu.com> <20180320110432.28127-5-douly.fnst@cn.fujitsu.com> From: Dou Liyang Message-ID: <7c33b3bd-7e9d-1583-737c-d2edd457bd1a@cn.fujitsu.com> Date: Tue, 22 May 2018 09:47:36 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.167.226.106] X-yoursite-MailScanner-ID: 2137248AE92A.AA514 X-yoursite-MailScanner: Found to be clean X-yoursite-MailScanner-From: douly.fnst@cn.fujitsu.com X-Spam-Status: No Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At 05/19/2018 11:06 PM, Thomas Gleixner wrote: > On Tue, 20 Mar 2018, Dou Liyang wrote: > >> ACPI driver should make sure all the processor IDs in their ACPI Namespace >> are unique for CPU hotplug. the driver performs a depth-first walk of the >> namespace tree and calls the acpi_processor_ids_walk(). >> >> But, the acpi_processor_ids_walk() will return true if one processor is >> checked, that cause the walk break after walking pass the first processor. >> >> Repace the value with AE_OK which is the standard acpi_status value. >> >> Fixes 8c8cb30f49b8 ("acpi/processor: Implement DEVICE operator for processor enumeration") >> >> Signed-off-by: Dou Liyang >> --- >> drivers/acpi/acpi_processor.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/acpi/acpi_processor.c b/drivers/acpi/acpi_processor.c >> index 449d86d39965..db5bdb59639c 100644 >> --- a/drivers/acpi/acpi_processor.c >> +++ b/drivers/acpi/acpi_processor.c >> @@ -663,11 +663,11 @@ static acpi_status __init (acpi_handle handle, >> } >> >> processor_validated_ids_update(uid); >> - return true; >> + return AE_OK; >> >> err: >> acpi_handle_info(handle, "Invalid processor object\n"); >> - return false; >> + return AE_OK; > > I'm not sure whether this is the right return value here. Rafael? > Hi, Thomas, Rafael, Yes, I used AE_OK to make sure it can skip the invalid objects and continue to do the following other objects, I'm also not sure. For this bug, recently, I sent another patch to remove this check code away.    https://lkml.org/lkml/2018/5/17/320 IMO, the duplicate IDs can be avoid by the other code if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) ---- 1) As the mapping of cpu_id(pr->id) and processor_id is fixed, when hot-plugging a physical CPU, if its processor_id is duplicated with the present, the above condition 1) will be 0, and Linux will do not add this CPU. And, when every time the system starts, this code will be executed, it will waste more time with the increase in the number of CPU. So I prefer to remove this code. Thanks, dou