From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1427476AbcBSRz0 (ORCPT ); Fri, 19 Feb 2016 12:55:26 -0500 Received: from outbound.smtp.vt.edu ([198.82.183.121]:44292 "EHLO omr1.cc.vt.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1425137AbcBSRzZ (ORCPT ); Fri, 19 Feb 2016 12:55:25 -0500 X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.6+dev To: Aurelien Jarno Cc: Gleb Natapov , Paolo Bonzini , x86@kernel.org, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, Aruna Hewapathirane Subject: Re: Silence compiler warning in arch/x86/kvm/emulate.c From: Valdis.Kletnieks@vt.edu In-Reply-To: <20160219164548.GA28630@aurel32.net> References: <142668.1440884956@turing-police.cc.vt.edu> <20160219111139.GA22041@aurel32.net> <20160219164548.GA28630@aurel32.net> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1455904440_2343P"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Fri, 19 Feb 2016 12:54:00 -0500 Message-ID: <10537.1455904440@turing-police.cc.vt.edu> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --==_Exmh_1455904440_2343P Content-Type: text/plain; charset=us-ascii On Fri, 19 Feb 2016 17:45:48 +0100, Aurelien Jarno said: > On 2016-02-19 12:11, Aurelien Jarno wrote: > Actually the same patch with a bit more context shows the issue: > > > diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c > > index e7a4fde..b372a75 100644 > > --- a/arch/x86/kvm/emulate.c > > +++ b/arch/x86/kvm/emulate.c > > @@ -647,12 +647,13 @@ static __always_inline int __linearize(struct x86_emu late_ctxt *ctxt, > > bool usable; > > ulong la; > > u32 lim; > > u16 sel; > > > > la = seg_base(ctxt, addr.seg) + addr.ea; > > + *linear = la; > > The assignation is moved here... > > > *max_size = 0; > > switch (mode) { > > case X86EMUL_MODE_PROT64: > > if (is_noncanonical_address(la)) > > goto bad; > > > > @@ -690,13 +691,12 @@ static __always_inline int __linearize(struct x86_emulate_ctxt *ctxt, > > } > > la &= (u32)-1; > > ... while the value of la might be modified in between. (trying to reconstruct my thought process from 6 months ago. I remember staring at that, and I convinced myself it was still OK to move the assignment.) la can get changed here - but there's 2 cases to consider. If it's in a 32-bit kernel, anding with -1 is a no-op. Now if we're on a 64-bit kernel, the 'and' clears the high 32 bits. But under what conditions is 'la' a 64-bit quantity that has any bits set in the high 32 bits (meaning it's a pointer to something over the 4G line) - but it's still valid to smash those bits? --==_Exmh_1455904440_2343P Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Exmh version 2.5 07/13/2001 iQIVAwUBVsdWuAdmEQWDXROgAQILDA/+MU7SXmSv6ejYmbfyf3kQb13GhcXJeVSk NSDVRhEnSmtCHVEXaIJOinGMSk3rlbW4ffxP5a0Ds5GQtgNpmyIupWlGSCnvSd3+ Gzkpms+HTRfEBDAE3qKkBmbOPqoXQ95meH19LbMFPmn7SIKyu7+RDJ/o2oU+HWZ4 iDEJle9nOWfMAu1CMp/Y3vYdmw+Rm6+stSSzgMm6mmbSacic+2vUPWGpzCev0tX5 whyQ8SmOTG8hkRxM3gUdZdDGJRIOEdOkaMC5dsdCUVO/E1LrFmoDvGK4oMgzo0tU Afo4ik+8/XuKVmR/zKuZrz0pS6Bym3Uq3gUVeR+TnOyvqTLwDhJaGMhSQP94mh7Y fSfzRMNpbDyW9EMEvTzQKdMsKbJ4P1oWh3/aSQoT6BYwBXaEAvBeQx/DHQn4ysV1 2Ky4pNts/JoF6dz81E5oCwNEkvRvXqKqnUxtwCjWU++66Hb2yLDSBdqYIxbkR2sI WsJINGYaUUyS9UvjlZ/GFZ8mvnx2N4nNExNlvh2g4W+vf047BDc8gHP6eNty3oqI L7PmcDcmeYN9dZ9LyIhGEvXZHa003yxWc9gOCU+97SG8mliTBF8JOhIsam8IzGBC r+KpoQ8YS+SV21epC/rfmZ4dev/ArPMxPtSkkOreA92ycLWuNinnsyBju4+iFJLg sqvp90eyPvw= =Jxer -----END PGP SIGNATURE----- --==_Exmh_1455904440_2343P--