From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: [PATCH 2/4] x86emul: use (locally) consistent exit mechanisms Date: Mon, 20 Jun 2016 05:58:01 -0600 Message-ID: <5767F66902000078000F6ABF@prv-mh.provo.novell.com> References: <5767F35B02000078000F6A88@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__PartDBEDE659.1__=" Return-path: Received: from mail6.bemta6.messagelabs.com ([85.158.143.247]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bExqP-00019v-B0 for xen-devel@lists.xenproject.org; Mon, 20 Jun 2016 11:58:21 +0000 In-Reply-To: <5767F35B02000078000F6A88@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: Andrew Cooper 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. --=__PartDBEDE659.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Disposition: inline At least similar code should use similar exit mechanisms (return vs goto). Signed-off-by: Jan Beulich --- RFC reason: There are many more paths where we could return directly, avoiding the _put_fpu() and put_stub(). Otoh arguably the two existing return-s around the changes below could also be changed to "goto done" to restore consistency. Subsequently we may then want to consider to reduce the number of "goto done" by checking rc right after at least the main switch() statements. --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -2112,7 +2112,7 @@ x86_emulate( op_bytes =3D 8; if ( (rc =3D ops->write(x86_seg_ss, sp_pre_dec(op_bytes), ®.sel, op_bytes, ctxt)) !=3D 0 ) - goto done; + return rc; break; } =20 @@ -2125,9 +2125,8 @@ x86_emulate( if ( mode_64bit() && (op_bytes =3D=3D 4) ) op_bytes =3D 8; if ( (rc =3D read_ulong(x86_seg_ss, sp_post_inc(op_bytes), - &dst.val, op_bytes, ctxt, ops)) !=3D 0 ) - goto done; - if ( (rc =3D load_seg(src.val, dst.val, 0, NULL, ctxt, ops)) !=3D = 0 ) + &dst.val, op_bytes, ctxt, ops)) !=3D 0 || + (rc =3D load_seg(src.val, dst.val, 0, NULL, ctxt, ops)) !=3D = 0 ) return rc; break; =20 --=__PartDBEDE659.1__= Content-Type: text/plain; name="x86emul-consistently-bail.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="x86emul-consistently-bail.patch" x86emul: use (locally) consistent exit mechanisms=0A=0AAt least similar = code should use similar exit mechanisms (return vs=0Agoto).=0A=0ASigned-off= -by: Jan Beulich =0A---=0ARFC reason: There are many = more paths where we could return directly,=0A avoiding the = _put_fpu() and put_stub(). Otoh arguably the=0A two existing = return-s around the changes below could also=0A be changed to = "goto done" to restore consistency.=0A=0ASubsequently we may then want to = consider to reduce the number of=0A"goto done" by checking rc right after = at least the main switch()=0Astatements.=0A=0A--- a/xen/arch/x86/x86_emulat= e/x86_emulate.c=0A+++ b/xen/arch/x86/x86_emulate/x86_emulate.c=0A@@ = -2112,7 +2112,7 @@ x86_emulate(=0A op_bytes =3D 8;=0A = if ( (rc =3D ops->write(x86_seg_ss, sp_pre_dec(op_bytes),=0A = ®.sel, op_bytes, ctxt)) !=3D 0 )=0A- goto = done;=0A+ return rc;=0A break;=0A }=0A =0A@@ = -2125,9 +2125,8 @@ x86_emulate(=0A if ( mode_64bit() && (op_bytes = =3D=3D 4) )=0A op_bytes =3D 8;=0A if ( (rc =3D = read_ulong(x86_seg_ss, sp_post_inc(op_bytes),=0A- = &dst.val, op_bytes, ctxt, ops)) !=3D 0 )=0A- goto done;=0A- = if ( (rc =3D load_seg(src.val, dst.val, 0, NULL, ctxt, ops)) !=3D 0 = )=0A+ &dst.val, op_bytes, ctxt, ops)) !=3D 0 = ||=0A+ (rc =3D load_seg(src.val, dst.val, 0, NULL, ctxt, ops)) = !=3D 0 )=0A return rc;=0A break;=0A =0A --=__PartDBEDE659.1__= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --=__PartDBEDE659.1__=--