Received: by 2002:a05:6358:9392:b0:b2:7f6c:8e3b with SMTP id h18csp7176535rwb; Wed, 10 Aug 2022 03:57:56 -0700 (PDT) X-Google-Smtp-Source: AA6agR5Xi3++jsjNLMJUtA0uvj+t6Prsdpy+234lPGVwVx5DhkT4XywF34d6vmNeE0bPSk+VGkzw X-Received: by 2002:a17:907:980d:b0:732:f9ca:891c with SMTP id ji13-20020a170907980d00b00732f9ca891cmr4308957ejc.298.1660129076549; Wed, 10 Aug 2022 03:57:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1660129076; cv=none; d=google.com; s=arc-20160816; b=MXwsb1wn9TCxH+ClEDv+tE2HF0j1WpBdkH24EtzexNXOWKf/2QTu61ta8+Qmd2ajCI +c+PMI4QMSyUydlbFAP0JgHUR015zKcRxqiLzXE+570d3vANbYTYAj+tYl51bi1f266i 1teQ8T/s2cxCydi5x4ow+QTUFpX+bqJGrllyXAo9z1uzGJ8S3707gsDIApgCasc3+ka0 L1eeBKP8pL0x8q/alqzuo6XkS2Ksay2JYwJKFrEAOGBrsR0tmEQ8BZzClNjeCUBtR9l9 GAvsIWvzyuItH4ICMU6LPNax3PiPMR2NDuPAKiWpWQzwhCddJ2Uc4EK5pIcdFPzvhYYs +c5Q== 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=TwW6M6u5vKyxDnMqx9AQR/gg33wHCbXk3i4GrhHVUrQ=; b=AQJM/KGk4jLkLHWfy4liOzETmXiNkpygBXbhx5ynDM/Q9VIRfYgOv43BuFCgZP1Gpz UWsFMDapNYyf5UeDi1q1yXYdtLNzieBLMB8mIggvOjbYilMew0N0VsNYYzSYpdKsc7XM 0I6KF9xw7epzQNPvG7E2LkwHvpLwit34797FaiSIaizM2XE3zrnCIiSBQZjFVdcg66ep rNf2OEf6d9luGhTCsZcni5Gv/jfmJeIgjMyChcbr368I9K6lk9IFJ8ei+vJhEkjbIMAY DTwj+hhEs5Vgr9Ihyc8FeiBLOim77R+CWQIi7X1BprZ989nkHgVl3NXr6Jj7JfipJEPu 3YNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=g2wHHsvV; 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 m13-20020aa7c48d000000b0043dc97d184csi9802385edq.263.2022.08.10.03.57.31; Wed, 10 Aug 2022 03:57:56 -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=g2wHHsvV; 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 S231482AbiHJKm3 (ORCPT + 99 others); Wed, 10 Aug 2022 06:42:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39564 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231610AbiHJKmR (ORCPT ); Wed, 10 Aug 2022 06:42:17 -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 611226C768 for ; Wed, 10 Aug 2022 03:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660128133; 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=TwW6M6u5vKyxDnMqx9AQR/gg33wHCbXk3i4GrhHVUrQ=; b=g2wHHsvVTkMiXQDEhAO1EuLOYvJA4va0ihuWBBHsYqWobAg4sgxsVVPBiSlcB9RS3A/0// HkM1vsDirO3LjHGqKtyBQzG2KNoQnqFYToXT7Ic7OVWvDpCpVBiOyTd9otC0dbZwhw58XT MhsjsKQYUpMpA6nvd3lmPWvneJ+ueV4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-41-gw23tJ4HN0-JU_uY1ipUDA-1; Wed, 10 Aug 2022 06:42:08 -0400 X-MC-Unique: gw23tJ4HN0-JU_uY1ipUDA-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 23A693C2288C; Wed, 10 Aug 2022 10:42:08 +0000 (UTC) Received: from gshan.redhat.com (vpn2-54-77.bne.redhat.com [10.64.54.77]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 666C64050067; Wed, 10 Aug 2022 10:42:03 +0000 (UTC) From: Gavin Shan To: kvmarm@lists.cs.columbia.edu Cc: kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, fweimer@redhat.com, shan.gavin@gmail.com, maz@kernel.org, andrew.jones@linux.dev, mathieu.desnoyers@efficios.com, pbonzini@redhat.com, yihyu@redhat.com, seanjc@google.com, oliver.upton@linux.dev Subject: [PATCH v2 2/2] KVM: selftests: Use getcpu() instead of sched_getcpu() in rseq_test Date: Wed, 10 Aug 2022 18:41:14 +0800 Message-Id: <20220810104114.6838-3-gshan@redhat.com> In-Reply-To: <20220810104114.6838-1-gshan@redhat.com> References: <20220810104114.6838-1-gshan@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.11.54.2 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 by replacing "sched_getcpu()" with "getcpu()". Reported-by: Yihuang Yu Suggested-by: Florian Weimer Suggested-by: Mathieu Desnoyers Suggested-by: Sean Christopherson Signed-off-by: Gavin Shan --- tools/testing/selftests/kvm/rseq_test.c | 42 ++++++++++++++++--------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git a/tools/testing/selftests/kvm/rseq_test.c b/tools/testing/selftests/kvm/rseq_test.c index 2cd5fe49ac8b..84e8425edc2c 100644 --- a/tools/testing/selftests/kvm/rseq_test.c +++ b/tools/testing/selftests/kvm/rseq_test.c @@ -42,6 +42,18 @@ static void guest_code(void) GUEST_SYNC(0); } +/* + * We have to perform direct system call for getcpu() because it's + * not available until glic 2.29. + */ +static void sys_getcpu(unsigned *cpu) +{ + int r; + + r = syscall(__NR_getcpu, cpu, NULL, NULL); + TEST_ASSERT(!r, "getcpu failed, errno = %d (%s)", errno, strerror(errno)); +} + static int next_cpu(int cpu) { /* @@ -86,7 +98,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(); @@ -127,10 +139,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 @@ -226,9 +238,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 { /* @@ -238,12 +250,12 @@ 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(); + sys_getcpu(&cpu); rseq_cpu = READ_ONCE(__rseq->cpu_id); smp_rmb(); } while (snapshot != atomic_read(&seq_cnt)); @@ -255,9 +267,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