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;
Date:   Thu, 20 Aug 2020 21:48:17 +0000
From:   Vineeth Pillai <viremana@linux.microsoft.com>
To:     Michael Kelley <mikelley@microsoft.com>
Cc:     Haiyang Zhang <haiyangz@microsoft.com>,
        Stephen Hemminger <sthemmin@microsoft.com>,
        Wei Liu <wei.liu@kernel.org>,
        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
Message-ID: <20200820214817.ndjmzanwmdm5qfvf@viremana-dev.fwjladdvyuiujdukmejncen4mf.xx.internal.cloudapp.net>
References: <20200819174740.47291-1-viremana@linux.microsoft.com>
 <MW2PR2101MB1052254C5ED7C587E548DB3AD75A0@MW2PR2101MB1052.namprd21.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <MW2PR2101MB1052254C5ED7C587E548DB3AD75A0@MW2PR2101MB1052.namprd21.prod.outlook.com>
User-Agent: NeoMutt/20171215
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


Hi Michael,

> > +			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 length,
> 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.
> 
Valid point, will fix this in the next iteration.

Thanks,
Vineeth