Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp2109156imm; Mon, 28 May 2018 01:40:56 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpjmuERwpKjxzuKTRL1uB8w9rWOYZA03iAjL4tju6wf1TbK9JgxW/kZvIquaJfuqgqTuOZM X-Received: by 2002:a17:902:5c6:: with SMTP id f64-v6mr12679588plf.50.1527496856529; Mon, 28 May 2018 01:40:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527496856; cv=none; d=google.com; s=arc-20160816; b=jCDO4QKuuSdf7GQzxNKkILpwuGpkVLyrDrXLz6+4FGHrWUGsFKcQKgv1OpNb5H/wN7 tSWbWjyVSZuhkFj7OMHQODUY5qJGpfOQB5OUACrKoOXFGmE6PoCn36NJlRBHGyab/UzS WRZ61GHvmEOJdNTlmAT0fQgTZb3dClQQ7YuWOJqyeZzCRboD/jK3nTzNR0vtFjNnWWjO SMJ7Lbk27WQ+D9tKcBjYkbnUy31OjYgOQ1kcLJKeK2uva4U3APW6gpJjViN0maNsR62O lydo0jZhY7qbemNCo7dg09Hk4z70330UdvISHOqJPY36SZFJ8yYWFJWAK1qx48pLJ0qU SrTA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=aHMua3aF/MEndJB24Q28Tz2WmAHJpb9cbdgcSK3FkeM=; b=kFVWLVtTAJ1N0cNHARvJkaDNQ8rYZ77BVEdAGc6scjxv+2UZGssOg12oGVEx/AZKBH nNL2EhQeQE/pjy0dKfuAJ5+WugX7f+R1wMTh5IscOM1p5dQTxkAaRNxZb3foPJVzqnWh 33yl6k01csmFWb2dg6HDXpKY/aqWGzBzPBrl6gQUkhPsbAEM82pqE+d6Ulmaj8Z1spWA KlhSJS08NTdZdCbD9y1Ssr4OBJ4OKyshZak2Yo3dNRSZitrbi/FMsHGuWe7i9ZJ8TTy6 kRnXQKuShb1BLPH9x7GARKro2jyg3BdgfDLr9mTW6VLiLwmxqkaA4OqK1oRVQ4+REGaE 4pTQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=qNRBTeQc; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 97-v6si29130207plm.495.2018.05.28.01.40.41; Mon, 28 May 2018 01:40:56 -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; dkim=fail header.i=@gmail.com header.s=20161025 header.b=qNRBTeQc; 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754061AbeE1Ika (ORCPT + 99 others); Mon, 28 May 2018 04:40:30 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:41360 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753986AbeE1Ik1 (ORCPT ); Mon, 28 May 2018 04:40:27 -0400 Received: by mail-oi0-f65.google.com with SMTP id 11-v6so9735770ois.8; Mon, 28 May 2018 01:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aHMua3aF/MEndJB24Q28Tz2WmAHJpb9cbdgcSK3FkeM=; b=qNRBTeQcGh/J9JXoIs7LiorY1N45QMYpx26CVdLtnkzyg8vFIAM1q4dYmEIuye4A5E DjkffpCHICgaOtbeUHEAVVJb7QA418ef3CdMajvQXn/4lX1wswISDyhxBKmvnGtVQCtu 9fOHytt7PzQNB9+Sqt12CPdMJuB7LPxZP+JFKktz4bDsvpfMFuLWrwrmFKHDMGLAAZEc X7LNzOXToEtauYb93GgUcx70LRYyNIiKWaO1tbkUZpqXR7/P2xr2zjTAxAChZoPL1w8h Gqa4nHl59atAOGtTkP/NWxAoRjW8Z6uJbKrd2NJISvgA3GeHFq3u6xMvVB7H9vd2p3WG d8Ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aHMua3aF/MEndJB24Q28Tz2WmAHJpb9cbdgcSK3FkeM=; b=C9/1PSp7+0/+HRKh4xgC8DRhfKKLzzj7htDdoDTAj8szaRfoDKvK22xe9Q259uPur6 mXgLIaoR/8bwjs6wL/6E6l8p0qAeKTpmPparD+UrYGaY9JRGIS0fiC2glQ6iubnRhADI ow3bw1eT3JTUIYBql1do4NEdLIcv6SwgjoMAde6hCskbvCQmUASWS6ZdhxKnf5XAuQKJ lJ3OpSTJzenAlC/cgSOyHbTV63iEe7pOakDtqIeWRz/sHY1fQJ0VYL80kSezOtkmBV+p EpUZk7cMCZwZ/79iwH6SBngK9fdnSZNVvq0cGf9ClGCbjPuziiA++A1UOaFAHfHvAMSF 8kvw== X-Gm-Message-State: ALKqPwcp+WoN0QiWm/qUKIUag0GF9yM5WcmbvUGIx7FTyHrcyxX8DhFp 1TLv1drQFwWw0Lx66HbFRCwAKWeslxROJgmqJfk= X-Received: by 2002:aca:1c3:: with SMTP id 186-v6mr2265773oib.174.1527496826974; Mon, 28 May 2018 01:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:1468:0:0:0:0:0 with HTTP; Mon, 28 May 2018 01:40:26 -0700 (PDT) In-Reply-To: <20180517094658.18707-1-douly.fnst@cn.fujitsu.com> References: <20180517094658.18707-1-douly.fnst@cn.fujitsu.com> From: "Rafael J. Wysocki" Date: Mon, 28 May 2018 10:40:26 +0200 X-Google-Sender-Auth: NiOJyOJ7vIJfEMD0WYo0FHgdB4U Message-ID: Subject: Re: [PATCH 0/1] Remove the check of duplicate processors To: Dou Liyang Cc: Linux Kernel Mailing List , "the arch/x86 maintainers" , ACPI Devel Maling List , Thomas Gleixner , Ingo Molnar , "Rafael J. Wysocki" , Len Brown , "H. Peter Anvin" , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 17, 2018 at 11:46 AM, Dou Liyang wrote: > There is a bug in CPU hotplug code, I have two simple fix method, but I can't > ensure which one is better. So sent it out, seek help. > > We found some processors which have the same processor ID but in different > PXM in ACPI namespace. such as this: > > proc_id | pxm > -------------------- > 0 <-> 0 > 1 <-> 0 > 2 <-> 1 > 3 <-> 1 > ...... > 89 <-> 0 > 89 <-> 1 > 89 <-> 2 > 89 <-> 3 > ...... > > So we create a mechanism to validate them. make the processor(ID=89) > as invalid. And once a processor be hotplugged physically, we check its > processor id. > > Commit 8e089eaa1999 ("acpi: Provide mechanism to validate processors in the ACPI tables") > Commit a77d6cd96849 ("acpi/processor: Check for duplicate processor ids at hotplug time") > > Recently, I found the check mechanism has a bug, it didn't use the > acpi_processor_ids_walk() right and always gave us a wrong result. > First, I fixed it by modifying the value with AE_OK which is the > standard acpi_status value. > > https://lkml.org/lkml/2018/3/20/273 > > But, now, I even think this check is useless. my reasons are following: > > 1). Based on the practical effect, It works well, and no bug be reported > 2). Based on the code, the duplicate cases can be dealed with by > > if (invalid_logical_cpuid(pr->id) || !cpu_present(pr->id)) > > That seems more reasonable, let's see the following case: > > Before the patch, After the patch > > the first processor(ID=89) > hot-add failed success > > the others processor(ID=89) > hot-add failed failed > > > So, What's your idea about it. > > Dou Liyang (1): > acpi/processor: Remove the check of duplicates processor ids Can you please resend the patch with the above information in the changelog of it? That would make it easier to review and discuss it. Also I think that we need some sort of a check against duplicate IDs.