Received: by 2002:a05:6358:e9c4:b0:b2:91dc:71ab with SMTP id hc4csp5486657rwb; Mon, 8 Aug 2022 21:12:46 -0700 (PDT) X-Google-Smtp-Source: AA6agR7X0m+1iw1fPiM5ULfA7B0sNYEaij3++r6HvR3SD2BvMrwK9H9ds2YWo0MOAU1z5ftoXZE3 X-Received: by 2002:a05:6402:1f06:b0:43c:23c5:d879 with SMTP id b6-20020a0564021f0600b0043c23c5d879mr20475855edb.24.1660018365925; Mon, 08 Aug 2022 21:12:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660018365; cv=none; d=google.com; s=arc-20160816; b=pErjajvedKsdCgAaVC/eL9PJlxT8tRXtowqat8Rq2UjWuXHNCwZ4ZkAf5pGkdi7oCo nfrGTHACoNpiySKPWjJ+seR5M8pcvFWyvNPunTddDTLXhH7qK0ewVaHrourjko2ejg45 k3JMfO0/OhDT1wCAz9osmO3Qp1yPA1he3ManzI469ZOyVhzMAKDzYFyzliVmiCz0lxml NiFAOHBMPG3BrzNSZ2Fa4q3K+do9PurdGQS1PajUWBbkYPgF2T7D5IQLa51/+f58Hrqx YfX00TdpvD+XSbTS38F9p/ui94LtP8AExiwZhrsDb3FcQrkX77o39tDMY5oWFCdHrXs7 Va4Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=GpMqE31lls01IVsW/AFKiHmLzH6RkUJAa9i/teIiT1c=; b=zDctopvSVoUG8RCfSRpwCHPykec/9v258g4Bryxo3yDND1AFOYCzXoURQ+97wUCKCk tyYA3FQvLKYPh2XE60SyRx9EGHqKBlVWQ/YR1LAnYBm4k31yH24vInbSotQYaYfTSjlG e10oSZ5R0P8qkQlmkyHzYiF2NHkLxQDva5yckQs8LJB0oTXaSXKzrY+hx9y1kz8d1QuY gPB1X2tLkNLo0EBDKrvRi14bFArUWZ7WWB3FLI7zHj3/UHjIbkyveMGQChIfWVujTkCw q3feEFarJ/Xl3JdBvd0mH5Fjgbp6XNdTIl+rKoo2SHJ6bAOqOB8dMIMxlmeoVelVCLlK TIbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=BqZP3567; 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=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h24-20020a0564020e9800b00440d768eb42si2066478eda.89.2022.08.08.21.12.20; Mon, 08 Aug 2022 21:12:45 -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=@redhat.com header.s=mimecast20190719 header.b=BqZP3567; 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=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234509AbiHIEGk (ORCPT + 99 others); Tue, 9 Aug 2022 00:06:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58514 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232813AbiHIEGe (ORCPT ); Tue, 9 Aug 2022 00:06:34 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B108A186F2 for ; Mon, 8 Aug 2022 21:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660017985; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GpMqE31lls01IVsW/AFKiHmLzH6RkUJAa9i/teIiT1c=; b=BqZP3567C01JSpTFhWGoL6H0itSST4FSU2yXkY0Um/B3KCEqpLHEa+Bv4DThJp99CKytXH bA6u7mDM21RSsUOCs/7NGdbPj7I+7xdRJkruo1WGTfhmFcFg3rq6K5he3Gi1hFP7PB96PA V5oGAaIWgPPqE7mLC0rtcnJN5OKp3CU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-135-ahVzwH5mPJ6nYZb0VLyzfg-1; Tue, 09 Aug 2022 00:06:21 -0400 X-MC-Unique: ahVzwH5mPJ6nYZb0VLyzfg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BF4D8804191; Tue, 9 Aug 2022 04:06:20 +0000 (UTC) Received: from gshan.redhat.com (vpn2-54-20.bne.redhat.com [10.64.54.20]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 26FE72166B26; Tue, 9 Aug 2022 04:06:15 +0000 (UTC) From: Gavin Shan To: kvmarm@lists.cs.columbia.edu Cc: kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org, pbonzini@redhat.com, maz@kernel.org, oliver.upton@linux.dev, andrew.jones@linux.dev, seanjc@google.com, mathieu.desnoyers@efficios.com, fweimer@redhat.com, yihyu@redhat.com, shan.gavin@gmail.com Subject: [PATCH 2/2] KVM: selftests: Use getcpu() instead of sched_getcpu() in rseq_test Date: Tue, 9 Aug 2022 14:06:27 +0800 Message-Id: <20220809060627.115847-3-gshan@redhat.com> In-Reply-To: <20220809060627.115847-1-gshan@redhat.com> References: <20220809060627.115847-1-gshan@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable 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 sched_getcpu() is glibc dependent and it can simply return the CPU ID from the registered rseq information, as Florian Weimer pointed. In this case, it's pointless to compare the return value from sched_getcpu() and that fetched from the registered rseq information. Fix the issue by replacing sched_getcpu() with getcpu(), as Florian suggested. The comments are modified accordingly. Reported-by: Yihuang Yu Suggested-by: Florian Weimer Suggested-by: Mathieu Desnoyers Signed-off-by: Gavin Shan --- tools/testing/selftests/kvm/rseq_test.c | 32 ++++++++++++------------- 1 file changed, 16 insertions(+), 16 deletions(-) diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c index acb1bf1f06b3..621b9b15049b 100644 --- a/tools/testing/selftests/kvm/rseq_test.c +++ b/tools/testing/selftests/kvm/rseq_test.c @@ -126,7 +126,7 @@ static void *migration_worker(void *__rseq_tid) atomic_inc(&seq_cnt); /* - * Ensure the odd count is visible while sched_getcpu() isn't + * Ensure the odd count is visible while getcpu() isn't * stable, i.e. while changing affinity is in-progress. */ smp_wmb(); @@ -167,10 +167,10 @@ static void *migration_worker(void *__rseq_tid) * check completes. * * 3. To ensure the read-side makes efficient forward progress, - * e.g. if sched_getcpu() involves a syscall. Stalling the - * read-side means the test will spend more time waiting for - * sched_getcpu() to stabilize and less time trying to hit - * the timing-dependent bug. + * e.g. if getcpu() involves a syscall. Stalling the read-side + * means the test will spend more time waiting for getcpu() + * to stabilize and less time trying to hit the timing-dependent + * bug. * * Because any bug in this area is likely to be timing-dependent, * run with a range of delays at 1us intervals from 1us to 10us @@ -264,9 +264,9 @@ int main(int argc, char *argv[]) /* * Verify rseq's CPU matches sched's CPU. Ensure migration - * doesn't occur between sched_getcpu() and reading the rseq - * cpu_id by rereading both if the sequence count changes, or - * if the count is odd (migration in-progress). + * doesn't occur between getcpu() and reading the rseq cpu_id + * by rereading both if the sequence count changes, or if the + * count is odd (migration in-progress). */ do { /* @@ -276,15 +276,15 @@ int main(int argc, char *argv[]) snapshot = atomic_read(&seq_cnt) & ~1; /* - * Ensure reading sched_getcpu() and rseq.cpu_id - * complete in a single "no migration" window, i.e. are - * not reordered across the seq_cnt reads. + * Ensure reading getcpu() and rseq.cpu_id complete in + * a single "no migration" window, i.e. are not reordered + * across the seq_cnt reads. */ smp_rmb(); - cpu = sched_getcpu(); + r = getcpu(&cpu, NULL); rseq_cpu = READ_ONCE(__rseq_info->cpu_id); smp_rmb(); - } while (snapshot != atomic_read(&seq_cnt)); + } while (r || snapshot != atomic_read(&seq_cnt)); TEST_ASSERT(rseq_cpu == cpu, "rseq CPU = %d, sched CPU = %d\n", rseq_cpu, cpu); @@ -293,9 +293,9 @@ int main(int argc, char *argv[]) /* * Sanity check that the test was able to enter the guest a reasonable * number of times, e.g. didn't get stalled too often/long waiting for - * sched_getcpu() to stabilize. A 2:1 migration:KVM_RUN ratio is a - * fairly conservative ratio on x86-64, which can do _more_ KVM_RUNs - * than migrations given the 1us+ delay in the migration task. + * getcpu() to stabilize. A 2:1 migration:KVM_RUN ratio is a fairly + * conservative ratio on x86-64, which can do _more_ KVM_RUNs than + * migrations given the 1us+ delay in the migration task. */ TEST_ASSERT(i > (NR_TASK_MIGRATIONS / 2), "Only performed %d KVM_RUNs, task stalled too much?\n", i); -- 2.23.0