[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [XEN PATCH v2 1/3] xen/common: address MISRA C:2012 Rule 5.3


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 1 Aug 2023 15:33:25 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=X6jcdQMXOD+ZH52n5pvz4Gz3DBFJrho+rSxakIkbNSo=; b=U15iLV6otr9Jd3kvqjuRK/p+KPxWVqxLyvfF3VL9GF0eKvvnSCL2HnMuaenm8ijAwZLLibSd+k7ivqY79eRJMHGOJBh89Xppaz1nra9Jeu5H7xJhdkSYf9KUM6Xke5NpAVlx1EyZW29BcGEvDNlKS2M9W8NVrQN8R8M3jlJWXAozDQMv/FKGCCXRVY0RJ/uErbbIEK1q/3nhLTpmpbQTS2B75Wlv9rq37YvP+wFTibexHacJQQJA2dR9FHWek13tp/eD4n0KgPi37bd9edpf5MWteHKKOP6JHvFwO4T92QszjKWCFqi/gcuffZzxDduhDszc5CNyhDJkISzJeNmg8w==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UM/lJX48GUWKCW8Y2aWAcRG3fkp4/taLadsBo9C1g6QVOJDY18MzEdu6Mkr9s2NO72/P5M8lpFOaJjs0lMA5GRax8AOzcp7b7m+RIl2IiPmpFtB0pgJRHJ178veJJlzv0qAJ3XRmxG3oJOqiVnK09XJwmlH8c3hyVkkp7sCVyST1Su53tXrZ/I3yUxWvAvUzfde0XiN8Tj0irxxuBfA4N1uGIGxNBqwpMQzEXgmUo9FEYvrDEcDwnmeIKVAMa5LmcniF82ceeXPerGgY4Gi+plLqL2NCAROj4Qubln6PG6lNbXv++SfH1OWzVxOJwuDxMZVc2cgXh4W6eA7J+HXOgw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 01 Aug 2023 13:33:41 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 01.08.2023 14:47, Nicola Vetrini wrote:
> --- a/xen/common/compat/memory.c
> +++ b/xen/common/compat/memory.c
> @@ -81,6 +81,7 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>              struct compat_memory_exchange xchg;
>              struct compat_add_to_physmap atp;
>              struct compat_add_to_physmap_batch atpb;
> +            struct compat_remove_from_physmap rmfp;
>              struct compat_vnuma_topology_info vnuma;
>              struct compat_mem_access_op mao;
>              struct compat_mem_acquire_resource mar;
> @@ -321,12 +322,10 @@ int compat_memory_op(unsigned int cmd, 
> XEN_GUEST_HANDLE_PARAM(void) compat)
>  
>          case XENMEM_remove_from_physmap:
>          {
> -            struct compat_remove_from_physmap cmp;
> -
> -            if ( copy_from_guest(&cmp, compat, 1) )
> +            if ( copy_from_guest(&cmp.rmfp, compat, 1) )
>                  return -EFAULT;
>  
> -            XLAT_remove_from_physmap(nat.xrfp, &cmp);
> +            XLAT_remove_from_physmap(nat.xrfp, &cmp.rmfp);

Is there a reason not to use the same name in the compat union as is
used in the native one, like all other members do?

Preferably with consistent naming (which I'd be okay switching to
while committing)
Acked-by: Jan Beulich <jbeulich@xxxxxxxx>

Jan



 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.