Received: by 2002:a05:6358:1087:b0:cb:c9d3:cd90 with SMTP id j7csp567650rwi; Mon, 10 Oct 2022 04:33:15 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5yHJVb865S6VvaszsBWujWRx+BewZVq8uuR4R8SRgm5tDfystBFvjOe0QSyV743ukunTiN X-Received: by 2002:a65:4303:0:b0:439:f026:ccee with SMTP id j3-20020a654303000000b00439f026cceemr16393290pgq.322.1665401594832; Mon, 10 Oct 2022 04:33:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1665401594; cv=none; d=google.com; s=arc-20160816; b=sJE7fHmgx2UY5t5uhhHR51U8ZgRl0B0wYCmS4XO42wMOwbq50QNxEnocNF3qD5v3ew MTdARb1VEMVlbepW35yvwxCi8uQQeCTD/bSjqcnllSq4krr7/oqdygfUXXSSjwDWZy44 NRXSyqXfIaI7rafkXuygh/L94ze+gIi6qiudbYmvhhp4sQ/zm+Ii6kqoCwdhXvo1mGXQ 1zXgz3eAyPeKZTt/ZoQYWKpME20olWJsp5yenscHvWS+gEt1aKk3cL2FMElBMa1djSzw ZA5MZu1QZ5rMmgF0th9GCPM/njoaHRGmXcHEMEPMvbfzea82fwreLP2thdKbkP3te7hO 8hjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:dkim-signature; bh=lMMl/KHosRqKoaG99tWgP95ZIQ9jboImJ5ERiTEIL78=; b=N6PmyVzzEoKNk95YDYqLH/6mdJyt5Z2MBeMTKaV8Mm0DGhw0Y83E9MCXUo5i637Xm1 xg7CO7gJvu1Ig6a4rwmGtQs+mzy9Mcp6WkW/8T8IJZKL3bMH6RmlpcihJ8YWvI7r9S55 mYhdk2cnd6FkLT+1YKuK4R0e5dqTHI8h1pzosfDZ13gZHUMbbOmA8k9lI6v6jjKyrcBc 2WNUzuEALuruihYrP9FcWYSII3pHM6qZdSIBML6gStOODlixBQbNK7ejIIqkPY/0ZALS 63VQXENUbQ17CuhSlpNuMUalwDm1W1dwzqCof/O5DmBBR8IWvbNWU6e6vX6fGI2Xw6Jt mPmg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=qlkVAQny; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j1-20020a635501000000b0045d4e861cc8si12592761pgb.276.2022.10.10.04.33.02; Mon, 10 Oct 2022 04:33:14 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@ellerman.id.au header.s=201909 header.b=qlkVAQny; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231660AbiJJLVi (ORCPT + 99 others); Mon, 10 Oct 2022 07:21:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48702 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231270AbiJJLVg (ORCPT ); Mon, 10 Oct 2022 07:21:36 -0400 Received: from gandalf.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4239549B7E; Mon, 10 Oct 2022 04:21:34 -0700 (PDT) Received: from authenticated.ozlabs.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.ozlabs.org (Postfix) with ESMTPSA id 4MmGh84X0tz4wgr; Mon, 10 Oct 2022 22:21:28 +1100 (AEDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ellerman.id.au; s=201909; t=1665400889; bh=lMMl/KHosRqKoaG99tWgP95ZIQ9jboImJ5ERiTEIL78=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=qlkVAQnyj1Lg0FWv1boZL3xZ32fpNKxBW9d8Ecbl7sj+Py6TKF8T8vEO5HA6DwBtP AWuSBcPvAqRevSpDvLGsh1n2XkMW6A3Zu25tSCE9A0NQOINGrfgNJh8gCfApvAsgLb g0w/IOIgxrmLB3SueVEzNXWYQovpweZolQuos++QCKFZ7tHrqeuoQTz9yEB9y4Rp5m Fh6BgnMAh0UyiqcsJsLsDQ6tTpOik/sNh7QMRd2GydwTXJFC8it3bHbT/mAZs+6th7 99LSGmFclfJn/EDkB7NIbt6J6VB/EtzQtjaRu80xh3h8wJfp/LMh+R4U4ON4amVUBv 3U9t0Y+zIYRng== From: Michael Ellerman To: Zhouyi Zhou , npiggin@gmail.com, christophe.leroy@csgroup.eu, atrajeev@linux.vnet.ibm.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, lance@osuosl.org, paulmck@kernel.org, rcu@vger.kernel.org Cc: Zhouyi Zhou Subject: Re: [PATCH linux-next][RFC] powerpc: fix HOTPLUG error in rcutorture In-Reply-To: <20221010023315.98396-1-zhouzhouyi@gmail.com> References: <20221010023315.98396-1-zhouzhouyi@gmail.com> Date: Mon, 10 Oct 2022 22:21:24 +1100 Message-ID: <87bkqjorez.fsf@mpe.ellerman.id.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Zhouyi Zhou writes: > I think we should avoid torture offline the cpu who do tick timer > when nohz full is running. Can you tell us what the bug you're fixing is? Did you see a crash/oops/hang etc? Or are you just proposing this as something that would be a good idea? > Tested on PPC VM of Open Source Lab of Oregon State University. > The test results show that after the fix, the success rate of > rcutorture is improved. > After: > Successes: 40 Failures: 9 > Before: > Successes: 38 Failures: 11 > > I examined the console.log and Make.out files one by one, no new > compile error or test error is introduced by above fix. > > Signed-off-by: Zhouyi Zhou > --- > Dear PPC developers > > I found this bug when trying to do rcutorture tests in ppc VM of > Open Source Lab of Oregon State University: > > ubuntu@ubuntu:~/linux-next/tools/testing/selftests/rcutorture/res/2022.09.30-01.06.22-torture$ find . -name "console.log.diags"|xargs grep HOTPLUG > ./results-scftorture/NOPREEMPT/console.log.diags:WARNING: HOTPLUG FAILURES NOPREEMPT > ./results-rcutorture/TASKS03/console.log.diags:WARNING: HOTPLUG FAILURES TASKS03 > ./results-rcutorture/TREE04/console.log.diags:WARNING: HOTPLUG FAILURES TREE04 > ./results-scftorture-kasan/NOPREEMPT/console.log.diags:WARNING: HOTPLUG FAILURES NOPREEMPT > ./results-rcutorture-kasan/TASKS03/console.log.diags:WARNING: HOTPLUG FAILURES TASKS03 > ./results-rcutorture-kasan/TREE04/console.log.diags:WARNING: HOTPLUG FAILURES TREE04 > > I tried to fix this bug. > > Thanks for your patience and guidance ;-) > > Thanks > Zhouyi > -- > arch/powerpc/kernel/sysfs.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c > index ef9a61718940..be9c0e45337e 100644 > --- a/arch/powerpc/kernel/sysfs.c > +++ b/arch/powerpc/kernel/sysfs.c > @@ -4,6 +4,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -21,6 +22,7 @@ > #include > #include > #include > +#include "../../../kernel/time/tick-internal.h" Needing to include this internal header is a sign that we are using the wrong API or otherwise using time keeping internals we shouldn't be. > #include "cacheinfo.h" > #include "setup.h" > @@ -1151,7 +1153,11 @@ static int __init topology_init(void) > * CPU. For instance, the boot cpu might never be valid > * for hotplugging. > */ > - if (smp_ops && smp_ops->cpu_offline_self) > + if (smp_ops && smp_ops->cpu_offline_self > +#ifdef CONFIG_NO_HZ_FULL > + && !(tick_nohz_full_running && tick_do_timer_cpu == cpu) > +#endif > + ) I can't see any other arches doing anything like this. I don't think it's the arches responsibility. If the time keeping core needs a CPU to stay online to run the timer then it needs to organise that itself IMHO :) cheers > c->hotpluggable = 1; > #endif > > -- > 2.25.1