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;
From:   Michael Kelley <mikelley@microsoft.com>
To:     Vineeth Pillai <viremana@linux.microsoft.com>,
        Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>
CC:     KY Srinivasan <kys@microsoft.com>,
        "linux-hyperv@vger.kernel.org" <linux-hyperv@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] hv_utils: drain the timesync packets on onchannelcallback
Thread-Topic: [PATCH] hv_utils: drain the timesync packets on
 onchannelcallback
Thread-Index: AQHWdlDtdkV2ehbVvUOPVvrqU48qR6lBUMDQ
Date:   Thu, 20 Aug 2020 18:31:12 +0000
Message-ID: <MW2PR2101MB1052254C5ED7C587E548DB3AD75A0@MW2PR2101MB1052.namprd21.prod.outlook.com>
References: <20200819174740.47291-1-viremana@linux.microsoft.com>
In-Reply-To: <20200819174740.47291-1-viremana@linux.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-08-20T18:31:10Z;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=47ec43f2-3b04-4a47-bb93-e11bee28bb1e;
 MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
authentication-results: linux.microsoft.com; dkim=none (message not signed)
 header.d=none;linux.microsoft.com; dmarc=none action=none
 header.from=microsoft.com;
x-originating-ip: [24.22.167.197]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 2e765de7-0e8c-4d02-02c0-08d84537376e
x-ms-traffictypediagnostic: MW2PR2101MB1050:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <MW2PR2101MB105061C41E80000D0910398AD75A0@MW2PR2101MB1050.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:397;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: eeFS0iPeRXL1guyrpuAG9HgEQYzzXAo8q12vpzyeByz67nqKFtb+kP5lPjHaE2abqtyZXanc3h9mpz7a3q8gmIBEWuCBA8tt/t+U4kQymLLEvveRQnyCqu6MZGXWhf89d5VPaVhOOa6ngh1J6xqgbLKpDUzlblicJR531pV4Oc7OKrg9blsnx1yVeOyNYiPj8FA5hGlR2UgbctelpdvXRSPaH++Vi+b6onUfxdSknbD5ybWSOjgr0P1T1kyAgc/8oZddDu/wrj0/45xZgoOxBbDsSIWP1O3lGbTcSZpT3akMwOrii2nRr1xe0Xbk8rX09Kx/8otTNav6NRV+a+FJhg==
x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:MW2PR2101MB1052.namprd21.prod.outlook.com;PTR:;CAT:NONE;SFS:(4636009)(136003)(39860400002)(396003)(376002)(366004)(346002)(82960400001)(66446008)(54906003)(82950400001)(10290500003)(316002)(64756008)(83380400001)(8990500004)(66476007)(33656002)(66946007)(66556008)(110136005)(26005)(478600001)(186003)(2906002)(5660300002)(52536014)(86362001)(8676002)(55016002)(9686003)(76116006)(4326008)(6506007)(71200400001)(8936002)(7696005);DIR:OUT;SFP:1102;
x-ms-exchange-antispam-messagedata: +1eZo3WOoGBJnazdTLAM+PXSh/s4c3UEdU9L5xlZGrO6/enouAAc4cRBgjm4Wb01VmB81LWXj8qZZzKMVrC6pLSOtaXgYR5UgGyabicwK8O6vpIaQVQL5J+d8Ibyx4LbnSrMbYMZg0LbpqAReMyaT2jpu19zch6kVtSEUSzpLMsyu/zxh6y0EzT37KkP4UuwElqVno3kJTEgUQ3N+rUQaz8Za3teeEjCbM8EkppdHtB9kixoLYc+64Nn0aW2Cxc2Dcamyd5aaq5/DxFMo8h4mAFOW/7HmJQEFHZPoMd/a/ru3QKBRAc2DYv1wGfCq6EnkpgFOVimMalZTfG4MbSpSD39tiK5mBF4h9RfiZgmtYJ5n/PUyPhIULPMTKIBFKLI93DxXdVhyo5rdBxKEuKFeJuvW4eu2yh1ybOhXOT88VfFBYgthTeYCiGYsFAdvKVAMsY1WKFu3yn1Ay3juQ2/SO+miNffeStILuaD9oroHRI/mdnus8j2+AYZjiDANONwGpg9B/P/cZXBulvZ2BwqDh9r9yd4WBNVnSeVIjRal9tsu0tHxE6jYTwmlfxyHbdtTypcTn3WLrp5qd79xTLHP4D/iSeB5uMIAPFLda3PESOK2VKFSyuGguEyAPNow2Pdpa5bDHfemIyMXyy8ojuHyQ==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW2PR2101MB1052.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2e765de7-0e8c-4d02-02c0-08d84537376e
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Aug 2020 18:31:12.6820
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KIkOwL8hcbgOiPsHAdtbKZp9sq07k9iL1v3NehT0EpnjGGIUkYOgWj6o9UiMybZGWaGn6osDfTrdR/M3H6JKDlABLQ/1DCmjp4PoCMccfIg=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW2PR2101MB1050
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

From: Vineeth Pillai <viremana@linux.microsoft.com> Sent: Wednesday, August=
 19, 2020 10:48 AM
>=20
> There could be instances where a system stall prevents the timesync
> packaets to be consumed. And this might lead to more than one packet
> pending in the ring buffer. Current code empties one packet per callback
> and it might be a stale one. So drain all the packets from ring buffer
> on each callback.
>=20
> Signed-off-by: Vineeth Pillai <viremana@linux.microsoft.com>
> ---
>  drivers/hv/hv_util.c | 19 ++++++++++++++++---
>  1 file changed, 16 insertions(+), 3 deletions(-)
>=20
> diff --git a/drivers/hv/hv_util.c b/drivers/hv/hv_util.c
> index 1357861fd8ae..c0491b727fd5 100644
> --- a/drivers/hv/hv_util.c
> +++ b/drivers/hv/hv_util.c
> @@ -387,10 +387,23 @@ static void timesync_onchannelcallback(void *contex=
t)
>  	struct ictimesync_ref_data *refdata;
>  	u8 *time_txf_buf =3D util_timesynch.recv_buffer;
>=20
> -	vmbus_recvpacket(channel, time_txf_buf,
> -			 HV_HYP_PAGE_SIZE, &recvlen, &requestid);
> +	/*
> +	 * Drain the ring buffer and use the last packet to update
> +	 * host_ts
> +	 */
> +	while (1) {
> +		int ret =3D vmbus_recvpacket(channel, time_txf_buf,
> +					   HV_HYP_PAGE_SIZE, &recvlen,
> +					   &requestid);
> +		if (ret) {
> +			pr_warn("TimeSync IC pkt recv failed (Err: %d)\n",
> +				ret);

Let's use pr_warn_once().

If there's a packet at the head of the ring buffer that specifies a bogus l=
ength,
we could take the error path.  But the bad packet stays at the head of the =
ring buffer,
so if we end up back here again, we'll spit out the same error message.  We
actually should not end up here again because Hyper-V shouldn't interrupt
when adding a packet to a non-empty ring buffer, but who knows what might
happen.

> +			break;
> +		}
> +
> +		if (!recvlen)
> +			break;
>=20
> -	if (recvlen > 0) {
>  		icmsghdrp =3D (struct icmsg_hdr *)&time_txf_buf[
>  				sizeof(struct vmbuspipe_hdr)];
>=20
> --
> 2.17.1