From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: [PATCH 1/2] memory: exit early from memory_exchange() upon write-back error Date: Tue, 04 Apr 2017 07:13:42 -0600 Message-ID: <58E3B826020000780014CA6A@prv-mh.provo.novell.com> References: <58E3B354020000780014CA30@prv-mh.provo.novell.com> <58E3B354020000780014CA30@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part5960EF16.5__=" Return-path: Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cvOHO-0006D0-Kb for xen-devel@lists.xenproject.org; Tue, 04 Apr 2017 13:13:50 +0000 In-Reply-To: <58E3B354020000780014CA30@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: xen-devel Cc: Stefano Stabellini , Wei Liu , Jann Horn , George Dunlap , Andrew Cooper , Ian Jackson , Tim Deegan , Julien Grall List-Id: xen-devel@lists.xenproject.org This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5960EF16.5__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline There's no point in continuing if in the end we'll return -EFAULT anyway. It also seems wrong to report a chunk for which at least one write-back failed as successfully exchanged (albeit the indication of an error is also not fully correct, as the exchange happened in that case at least partially - retrieving the GFN to assign the memory to and/or handing back the information on the replacement memory didn't work). In any case limiting the amount of damage done to the guest can't be all that bad an idea. Reported-by: Jann Horn Signed-off-by: Jan Beulich --- I'm additionally surprised we don't require input GFNs to be order aligned for both IN- and OUT-chunks (similarly for populate-physmap and decrease-reservation). --- a/xen/common/memory.c +++ b/xen/common/memory.c @@ -639,6 +639,9 @@ static long memory_exchange(XEN_GUEST_HA } } BUG_ON( !(d->is_dying) && (j !=3D (1UL << out_chunk_order)) ); + + if ( rc ) + goto fail; } =20 exch.nr_exchanged =3D exch.in.nr_extents; --=__Part5960EF16.5__= Content-Type: text/plain; name="memory-exchange-write-fail.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="memory-exchange-write-fail.patch" memory: exit early from memory_exchange() upon write-back error=0A=0AThere'= s no point in continuing if in the end we'll return -EFAULT=0Aanyway. It = also seems wrong to report a chunk for which at least one=0Awrite-back = failed as successfully exchanged (albeit the indication of=0Aan error is = also not fully correct, as the exchange happened in that=0Acase at least = partially - retrieving the GFN to assign the memory to=0Aand/or handing = back the information on the replacement memory didn't=0Awork). In any case = limiting the amount of damage done to the guest=0Acan't be all that bad an = idea.=0A=0AReported-by: Jann Horn =0ASigned-off-by: Jan = Beulich =0A---=0AI'm additionally surprised we don't = require input GFNs to be order=0Aaligned for both IN- and OUT-chunks = (similarly for populate-physmap=0Aand decrease-reservation).=0A=0A--- = a/xen/common/memory.c=0A+++ b/xen/common/memory.c=0A@@ -639,6 +639,9 @@ = static long memory_exchange(XEN_GUEST_HA=0A }=0A }=0A = BUG_ON( !(d->is_dying) && (j !=3D (1UL << out_chunk_order)) = );=0A+=0A+ if ( rc )=0A+ goto fail;=0A }=0A =0A = exch.nr_exchanged =3D exch.in.nr_extents;=0A --=__Part5960EF16.5__= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwczovL2xpc3RzLnhlbi5v cmcveGVuLWRldmVsCg== --=__Part5960EF16.5__=--