From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753345AbcEDPgO (ORCPT ); Wed, 4 May 2016 11:36:14 -0400 Received: from smtp02.citrix.com ([66.165.176.63]:64257 "EHLO SMTP02.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751436AbcEDPgN (ORCPT ); Wed, 4 May 2016 11:36:13 -0400 X-IronPort-AV: E=Sophos;i="5.24,577,1454976000"; d="scan'208";a="358364158" Subject: Re: [Xen-devel] [PATCH] xen: fix ring resize of /dev/evtchn To: David Vrabel , Jan Beulich , Boris Ostrovsky , Juergen Gross References: <572A0F0C02000078000E88B6@prv-mh.provo.novell.com> <5729F984.4040807@citrix.com> CC: xen-devel , From: David Vrabel Message-ID: <572A1698.2010907@citrix.com> Date: Wed, 4 May 2016 16:34:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0 MIME-Version: 1.0 In-Reply-To: <5729F984.4040807@citrix.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-DLP: MIA1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/05/16 14:30, David Vrabel wrote: > On 04/05/16 14:02, Jan Beulich wrote: >> The copying of ring data was wrong for two cases: For a full ring >> nothing got copied at all (as in that case the canonicalized producer >> and consumer indexes are identical). And in case one or both of the >> canonicalized (after the resize) indexes would point into the second >> half of the buffer, the copied data ended up in the wrong (free) part >> of the new buffer. In both cases uninitialized data would get passed >> back to the caller. >> >> Fix this by simply copying the old ring contents twice: Once to the >> low half of the new buffer, and a second time to the high half. >> >> This addresses the inability to boot a HVM guest with 64 or more >> vCPU-s, which was reported by Konrad Rzeszutek Wilk >> . > [...] > > Can you include the commit that introduced this regression and which > kernel versions it affects as this is a stable candidate. > >> @@ -344,22 +343,13 @@ static int evtchn_resize_ring(struct per >> spin_lock_irq(&u->ring_prod_lock); >> >> /* >> - * Copy the old ring contents to the new ring. >> - * >> - * If the ring contents crosses the end of the current ring, >> - * it needs to be copied in two chunks. >> - * >> - * +---------+ +------------------+ >> - * |34567 12| -> | 1234567 | >> - * +-----p-c-+ +------------------+ >> + * Copy the old ring contents to the new ring. To take care of >> + * wrapping, a full ring, and the new canonicalized index pointing >> + * into the second half, simply copy the old contents twice. > > Could you keep the ascii art? > > e.g., > > * +---------+ +------------------+ > * |34567 12| -> |34567 1234567 12| > * +-----p-c-+ +-------c------p---+ > > So it is obvious that the double copy does the right thing. Never mind, I wanted to send a pull request so I've fixed this up myself. David