Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp13376186rwb; Sun, 27 Nov 2022 04:57:35 -0800 (PST) X-Google-Smtp-Source: AA0mqf6vk6g3y0PCm0lQS76pbc7HydS3hUSKDAqrlD+qp7FiInmir2wRS96Eqakim6/+DwmU+9CL X-Received: by 2002:a17:90a:4e41:b0:218:a971:d847 with SMTP id t1-20020a17090a4e4100b00218a971d847mr35027092pjl.91.1669553855589; Sun, 27 Nov 2022 04:57:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669553855; cv=none; d=google.com; s=arc-20160816; b=LYWQbv63Ht7+DlFAlyinQVLD1wdyNksbN5eONwqWpfv/koH5o9bKTnVbmdCSQZ3ara r8NERVij72Hb+httxyK20d3quLI5CdMFPvsoorToUyVMDN7Yv6SP+L0i0ihgSC5qX+uQ xAJTrCcBAOQVcS7Q8GrbD/n7R1Z/xt3165JFyY586pXb9uaXXE5O1dCRPcmGwYZfqFdT dYeubvHqjOMTas5mWOaxt/oboVms3p/bm/uV8VcODz1zEi/JGdjwWl2+K1uVXiiDFqxw vo7dGg+oZfYCDCaStETPyx2JF8aQNVNUvsgUfSVLIq3D4FEKnNhm2nMv9XXjO5/50N7E cXgw== 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:dkim-signature:dkim-signature:from; bh=EB/53VcoNSyoAbWn3SJg3+Ux/MQhVRpr/mqLNU0o7js=; b=ArZUplA4VTDJT9Je03yNzbzCd0XqZqKtUh4Ew43UGVdXTgsU8ESiBBFVJLIW2ATuX1 GUb6eOi+sTuY2d/ZBqnP91L8CrZYPBjHQmlVhc2ghdmGSUv0i+WeMnM5I/XmZnTejDw4 lIh/nAOQaI4eCdmn4pyygcRU/HiRKVSqcFJj9lJvNMm7mBwj0i95zIprTIeZn+FDCfcc rlKXeKGRtcCGTP3dj4cVQ4XHWNc4zaZVYj28Z2hPk3A8xpr4niXZSdyeOPzcZdvT1zK7 9a+FWFL1Ckzw/TklL2llE3hUVTuSyT8iMmj85zUhTKYi9s/0b9YA6/QdoYpp+yN88IDc yecw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=tG6JfF9G; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b="/rsDEyIP"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id q10-20020a056a00084a00b0056f0d233a56si10653896pfk.235.2022.11.27.04.57.25; Sun, 27 Nov 2022 04:57:35 -0800 (PST) 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=@linutronix.de header.s=2020 header.b=tG6JfF9G; dkim=neutral (no key) header.i=@linutronix.de header.s=2020e header.b="/rsDEyIP"; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229615AbiK0Mkd (ORCPT + 84 others); Sun, 27 Nov 2022 07:40:33 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36816 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229496AbiK0Mkc (ORCPT ); Sun, 27 Nov 2022 07:40:32 -0500 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5C95B263B for ; Sun, 27 Nov 2022 04:40:31 -0800 (PST) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669552828; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EB/53VcoNSyoAbWn3SJg3+Ux/MQhVRpr/mqLNU0o7js=; b=tG6JfF9GryBdY5R1ayDhFW5nVcj8BNhfdr0APEKiJba1hQz6qIiOe5efb58RfrjIUOwt5+ RugHbJd3u8HkXb/ai/VxhC6/hCxeh3ST002BnKf/61ZC1YlVr+luurAddWDJpKonqY08u5 G6wDSaoK8gzLbH05rJK7EnLlO4ZPF1zQrBKPTpnJRVnmy5BInef7LZ89XaXIae7ktv+2GN 9gK9TF4uM5I+E3SgXO0k5zWyqsAOu+ZeTn2arHQiEEUtqXSz9QY6QgQf68GZuEJanLslt2 zYmML/fl0TgfyLMdkAslGLznJWKaAl50FVGekChjqc6HJ/3z1yOLZQdy/OaK0A== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669552828; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=EB/53VcoNSyoAbWn3SJg3+Ux/MQhVRpr/mqLNU0o7js=; b=/rsDEyIP1zkZFV+paA9RKRugWWLeuR7RpzdUbBmFNIrfaI1E7mu2cmLePwxTvbwFW0vLz8 cV9QL3HaPKBt0RDA== To: Zhouyi Zhou Cc: fweisbec@gmail.com, mingo@kernel.org, dave@stgolabs.net, paulmck@kernel.org, josh@joshtriplett.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu In-Reply-To: References: <20221121035140.118651-1-zhouzhouyi@gmail.com> <87y1rxwsse.ffs@tglx> Date: Sun, 27 Nov 2022 13:40:28 +0100 Message-ID: <87v8n0woxv.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, 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, On Sun, Nov 27 2022 at 10:45, Zhouyi Zhou wrote: > On Sun, Nov 27, 2022 at 1:05 AM Thomas Gleixner wrote: > > So, I should construct my patch as: > We avoid ... by ... Not "We avoid". Avoid this behaviour by .... >> No. We are not exporting this just to make a bogus test case happy. >> >> Fix the torture code to handle -EBUSY correctly. > I am going to do a study on this, for now, I do a grep in the kernel tree: > find . -name "*.c"|xargs grep cpuhp_setup_state|wc -l > The result of the grep command shows that there are 268 > cpuhp_setup_state* cases. > which may make our task more complicated. Why? The whole point of this torture thing is to stress the infrastructure. There are quite some reasons why a CPU-hotplug or a hot-unplug operation can fail, which is not a fatal problem, really. So if a CPU hotplug operation fails, then why can't the torture test just move on and validate that the system still behaves correctly? That gives us more coverage than just testing the good case and giving up when something unexpected happens. I even argue that the torture test should inject random failures into the hotplug state machine to achieve extended code coverage. Thanks, tglx