Received: by 2002:a05:6a10:f3d0:0:0:0:0 with SMTP id a16csp19134pxv; Tue, 13 Jul 2021 20:17:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwkJwFnlJiKqgB1LA7JWgcgjv3YJJ3p/eZj+9DJWtk8tx/Nf5B82zZjOdFjTuptmhlMWrMk X-Received: by 2002:a6b:5c07:: with SMTP id z7mr5698818ioh.26.1626232663437; Tue, 13 Jul 2021 20:17:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1626232663; cv=none; d=google.com; s=arc-20160816; b=saMH+qzafbI1mel+4f5LP5dl8rwCiLAEZY3LHiWmgkGhlTMXcU0v4o6+MzdrWi55oh wpafCBRCCxKyi57Qj/QkWt1Te5O0/wkdxLBPACbnOV/Xdait2I08uy/9aFL+ZEZtyKi8 0i72mTmuIMcsjyZyRPHTLCRin3pWiVN/9+azbOEzDssCCNdpQh48k4uFpgKz+oy6dlgR /5U0sFYYRYFzhuEbcvu5xXF6LF6swLpS3NGncxDgP1uBjqPcSE2CQ0h69CMKvZdi2V2N rNRPSb/rkwp875e2/eJsN+KTmCdHRs6nmwnj+3VGGTYMDsnAK+qh1DQpTEKDIzNRE9hi ZGeg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:date:from:dkim-signature; bh=eQln7Sxs1F1MvVvqEAYpR9G/TYLHEFaC/1K6W6mv5tY=; b=Bad+osMifQ7IIu2jCosDvMnfDGfVuH2G5/7tQ9UR2VycE0xh9lt05YTA+PAzAmoj44 AWA3UG6kWVliQhUlahcKxO3FxqRuB9yig6bC+wg4F0ECbCR4vm8ilwc8ReBthymANmWH SaBJft0+6cZ+u89Um4RZq8zrIj4v+fa21wCJQzTSPr2dvsgelM+WAHYNaCyPVACw5WO4 KVpsVn7b49a8ZVe0sUSZCTsGwZrmpa1dmEBHP6ldinGea+CbzLh8PbrrTGrASthk69v6 o9wcrBN94mNhVz9BUmfvDU5jTA+biBinTe6t1NU15bC5zguUHyKvjYHuU1NYTtXiyaZP zFUA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@anisinha-ca.20150623.gappssmtp.com header.s=20150623 header.b=A+fJDlQW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h5si1197814iol.44.2021.07.13.20.17.27; Tue, 13 Jul 2021 20:17:43 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@anisinha-ca.20150623.gappssmtp.com header.s=20150623 header.b=A+fJDlQW; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237513AbhGNDTr (ORCPT + 99 others); Tue, 13 Jul 2021 23:19:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49560 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237436AbhGNDTq (ORCPT ); Tue, 13 Jul 2021 23:19:46 -0400 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EB7A3C0613E9 for ; Tue, 13 Jul 2021 20:16:54 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id b8-20020a17090a4888b02901725eedd346so777519pjh.4 for ; Tue, 13 Jul 2021 20:16:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anisinha-ca.20150623.gappssmtp.com; s=20150623; h=from:date:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=eQln7Sxs1F1MvVvqEAYpR9G/TYLHEFaC/1K6W6mv5tY=; b=A+fJDlQWk4r/ME4C5NmsuE8jcnNfjSxEPC9wlFKZxNcxP/5mPvwKG/R+TOA9NN18wa 1aHt3pBiTQVA1q6D+ESsBqIU8O6Kz0zsiWO1NShGnYN8bVtA1JyjJXwjGxZ/Zdxiwpv8 b6fXsfwE00Zq0A/x6MPwVEV1hMj+rvcAFdruB+kRw5q77T/p1VJWFzSZIDdhgxANzt79 X6VmOLN/hMM4adDo9vEOI+R9e/qCyDtmj9VAXtmgn2FG9+QZkjw5qq5e6q/NRwbuarMH 3IXF+GNMTO00DtLBp45+6Z6JnTO2LKG7kuma5VP18SX/TJHkagUVuRMYAT7i0DgeHJ6p ueSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=eQln7Sxs1F1MvVvqEAYpR9G/TYLHEFaC/1K6W6mv5tY=; b=F52WSLl7/PWCPj7EJIB+RWl0eChtAUXVdgQM7PEz9Ks1O/tO3Isb3G5AZ3pfBgZIRv WBJL2MoSN3GuY02Kq64USZXszMXDMH3iuGm5euocCZZAj3p7yTlQibk4t2x/JofvduR4 auspeYc+K9FCHmpc64cDOmlUkqBggriYD77Ip76ilD89tNqfYfO2/FZs680Ru+KhmhRE BMHKhWk0tyopjEoJ+FIfhuGdYDWTKs0D57m/F/p3cwRZhrknIDvjasq7bQcxk13HSZHy AJJ3RH9J+mpF1Am/E3/etey524kR8Q2PihpLK9EIzOq9Yw2XalvlXgVCdgKVQdb/a74n EdXQ== X-Gm-Message-State: AOAM53330kDqq64tt8Prf8U2OukyQv3907YkyQZ2qH8YA3gZaM1FhxeR zfy1jl6/GBakfT49nxywJk+uPA== X-Received: by 2002:a17:902:a503:b029:12b:2429:385e with SMTP id s3-20020a170902a503b029012b2429385emr6089516plq.64.1626232614130; Tue, 13 Jul 2021 20:16:54 -0700 (PDT) Received: from anisinha-lenovo ([115.96.109.231]) by smtp.googlemail.com with ESMTPSA id a23sm585346pfn.117.2021.07.13.20.16.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jul 2021 20:16:53 -0700 (PDT) From: Ani Sinha X-Google-Original-From: Ani Sinha Date: Wed, 14 Jul 2021 08:46:36 +0530 (IST) X-X-Sender: anisinha@anisinha-lenovo To: Michael Kelley cc: Ani Sinha , "linux-kernel@vger.kernel.org" , "anirban.sinha@nokia.com" , KY Srinivasan , Haiyang Zhang , Stephen Hemminger , Wei Liu , Dexuan Cui , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "x86@kernel.org" , "H. Peter Anvin" , "linux-hyperv@vger.kernel.org" Subject: RE: [PATCH] Hyper-V: fix for unwanted manipulation of sched_clock when TSC marked unstable In-Reply-To: Message-ID: References: <20210713030522.1714803-1-ani@anisinha.ca> User-Agent: Alpine 2.22 (DEB 394 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 13 Jul 2021, Michael Kelley wrote: > From: Ani Sinha Sent: Tuesday, July 13, 2021 10:49 AM > > > > On Tue, 13 Jul 2021, Michael Kelley wrote: > > > > > From: Ani Sinha Sent: Monday, July 12, 2021 8:05 PM > > > > > > > > Marking TSC as unstable has a side effect of marking sched_clock as > > > > unstable when TSC is still being used as the sched_clock. This is not > > > > desirable. Hyper-V ultimately uses a paravirtualized clock source that > > > > provides a stable scheduler clock even on systems without TscInvariant > > > > CPU capability. Hence, mark_tsc_unstable() call should be called _after_ > > > > scheduler clock has been changed to the paravirtualized clocksource. This > > > > will prevent any unwanted manipulation of the sched_clock. Only TSC will > > > > be correctly marked as unstable. > > > > > > > > Signed-off-by: Ani Sinha > > > > --- > > > > arch/x86/kernel/cpu/mshyperv.c | 8 ++++++-- > > > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c > > > > index 22f13343b5da..715458b7729a 100644 > > > > --- a/arch/x86/kernel/cpu/mshyperv.c > > > > +++ b/arch/x86/kernel/cpu/mshyperv.c > > > > @@ -370,8 +370,6 @@ static void __init ms_hyperv_init_platform(void) > > > > if (ms_hyperv.features & HV_ACCESS_TSC_INVARIANT) { > > > > wrmsrl(HV_X64_MSR_TSC_INVARIANT_CONTROL, 0x1); > > > > setup_force_cpu_cap(X86_FEATURE_TSC_RELIABLE); > > > > - } else { > > > > - mark_tsc_unstable("running on Hyper-V"); > > > > } > > > > > > > > /* > > > > @@ -432,6 +430,12 @@ static void __init ms_hyperv_init_platform(void) > > > > /* Register Hyper-V specific clocksource */ > > > > hv_init_clocksource(); > > > > #endif > > > > + /* TSC should be marked as unstable only after Hyper-V > > > > + * clocksource has been initialized. This ensures that the > > > > + * stability of the sched_clock is not altered. > > > > + */ > > > > > > For multi-line comments like the above, the first comment line > > > should just be "/*". So: > > > > Hmm, checkpatch.pl in kernel tree did not complain : > > > > total: 0 errors, 0 warnings, 20 lines checked > > > > 0001-Hyper-V-fix-for-unwanted-manipulation-of-sched_clock.patch has no > > obvious style problems and is ready for submission. > > > > However, I do know from my experience of submitting Qemu patches last > > year that this is a requirement imposed by the Qemu community as > > checkpatch.pl in qemu tree would complain otherwise. I also took a peek at > > the Qemu git history. It seems they imported this check from the kernel's > > checkpatch.pl with this commit in Qemu tree: > > > > commit 8c06fbdf36bf4d4d486116200248730887a4d7d6 > > Author: Peter Maydell > > Date: Fri Dec 14 13:30:48 2018 +0000 > > > > scripts/checkpatch.pl: Enforce multiline comment syntax > > > > Which adds this rule: > > > > + # Block comments use /* on a line of its own > > + if ($rawline !~ m@^\+.*/\*.*\*/[ \t]*$@ && #inline /*...*/ > > + $rawline =~ m@^\+.*/\*\*?[ \t]*.+[ \t]*$@) { # /* or /** non-blank > > + WARN("Block comments use a leading /* on a separate line\n" . $herecurr); > > + } > > > > > > But in kernel there is no such rule. Hmm. strange! > > > > > > See section 8 of "Documentation/process/coding-style.rst" in a Linux kernel > source code tree. :-) > Yes that is fine. What I was confused about is that the commenting rule existed in Qemu and checkpatch.pl there enforced this. Upon digging, I found that the Qemu community themselves "imported" this formating rule from kernel. Yet, kernel's own checkpatch.pl did not enforce this although as you point above, the rule exists in written form. This diff will fix kernel's checkpatch.pl without breaking drivers/net or net/ . Enforcing rules through proper tooling saves everyone's time and also ensures consistency. Will send out this patch soon. diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 23697a6b1eaa..5f047b762aa1 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -3833,6 +3833,14 @@ sub process { "networking block comments don't use an empty /* line, use /* Comment...\n" . $hereprev); } +# Block comments use /* on a line of its own + if (!($realfile =~ m@^(drivers/net/|net/)@) && + $rawline !~ m@^\+.*/\*.*\*/[ \t)}]*$@ && #inline /*...*/ + $rawline =~ m@^\+.*/\*\*?+[ \t]*[^ \t]@) { # /* or /** non-blank + WARN("BLOCK_COMMENT_STYLE", + "Block comments use a leading /* on a separate line\n" . $herecurr); + } + # Block comments use * on subsequent lines if ($prevline =~ /$;[ \t]*$/ && #ends in comment $prevrawline =~ /^\+.*?\/\*/ && #starting /*