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

Re: Refactor arm64/domctl.c 'subarch_do_domctl' to avoid unreachable break.


  • To: Julien Grall <julien@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Tue, 24 Oct 2023 07:57:08 +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=KKJta4hhz0jZnJh/RLsH7N+nISzocWcSGuVbzGVMbxg=; b=i4FdiKrnw/uY1SSLgz7CQecnHjGRaSb8IGqN9fRFmi1WvU5rdlbsfW74ZQqJu7mCrukssH0DCDTWnEIJR/x/ctBb7rKw3JjX0Pi4LUeNWpLHajYQxLFNN4/K+hdrAvFPoyBNEdbvgvtyc/Rt19lC3faUncD3eFQCz8xIhpRCkHJToqkg4C/MAb2dXa95jk7TGTngtCLoaqfdo0OKQzp28uWfVTZKkVScyh5B1TrwAvNbGy1ppls82z6U9KS00lwZlcb78CpsE/tGVfriis9pYWZnZSV5v96vBdA6ppVQWMf+eDFVcn6e+Ajx5u+iZDUjmvHB8Cdt6m6ZX0K89qZ/aQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y4hdG1udFDN1S1wsJCuGg0ckoHWjLU4jSubwKFIDBkLNk9PUAV5chMUx4hwScyO0lwGf9bCBKaAFaG+fephZ66Ghzp11HjWk0qSw4rjKayy7DfckOBOVkjUtbsBYXvTYhMDhuuYx7cKU53HmKTX+W4rTdfGqJ5DT8/pU18UjtogmR/ro7G4BxqR+R3IGQHps+t4u7iy88Hou7QurJSAcZiCr/VeZNI/YVuC8QZeruASlrYi8o6Rvtqqt9oSwOKvDKJfDcgtwiXYUsdS19jwCghrjFudbBgxycw7o/Mm4mHc4MKZrjZG/cglwYLBDORU40Ax3pMgVrT6uMXHDQuXFvw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, consulting@xxxxxxxxxxx, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • Delivery-date: Tue, 24 Oct 2023 05:57:33 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 23.10.2023 18:07, Julien Grall wrote:
> Hi Jan,
> 
> On 23/10/2023 16:15, Jan Beulich wrote:
>> On 23.10.2023 17:00, Julien Grall wrote:
>>>
>>>
>>> On 23/10/2023 15:51, Nicola Vetrini wrote:
>>>> Hi,
>>>
>>> Hi Nicola,
>>>
>>>> while taking care of some patches regarding MISRA C Rule 2.1 (code
>>>> shouldn't be unreachable), I
>>>> came across this function:
>>>>
>>>> long subarch_do_domctl(struct xen_domctl *domctl, struct domain *d,
>>>>                          XEN_GUEST_HANDLE_PARAM(xen_domctl_t) u_domctl)
>>>> {
>>>>       switch ( domctl->cmd )
>>>>       {
>>>>       case XEN_DOMCTL_set_address_size:
>>>>           switch ( domctl->u.address_size.size )
>>>>           {
>>>>           case 32:
>>>>               if ( !cpu_has_el1_32 )
>>>>                   return -EINVAL;
>>>>               /* SVE is not supported for 32 bit domain */
>>>>               if ( is_sve_domain(d) )
>>>>                   return -EINVAL;
>>>>               return switch_mode(d, DOMAIN_32BIT);
>>>>           case 64:
>>>>               return switch_mode(d, DOMAIN_64BIT);
>>>>           default:
>>>>               return -EINVAL;
>>>>           }
>>>>           break;
>>>>
>>>>       default:
>>>>           return -ENOSYS;
>>>>       }
>>>> }
>>>>
>>>> here the break after the innermost switch is clearly unreachable, but
>>>> it's also guarding a possible fallthrough.
>>>> I can see a couple of solutions to this:
>>>>
>>>> - mark the part after the switch unreachable;
>>>> - introduce a variable 'long rc' to store the return value, and
>>>> consequently rework the control flow of all the switches
>>>>     (e.g. rc = -EINVAL and similar);
>>>> - remove the break, but I consider this a risky move, unless -ENOSYS
>>>> would be an ok value to be returned if some case
>>>>     from the switch above does not have a return statement.
>>>
>>> - move the nested switch in a separate function, so the code in
>>> subarch_do_domctl() can be replaced with:
>>>
>>> return set_address_size(...);
>>
>> But that would help only if inside the new function you still re-
>> layout the switch() (or replace it by, say, if/else-if/else),
>> wouldn't it?
> 
> I am not sure why I would need to re-layout the switch. This should work 
> (untested):
> 
> diff --git a/xen/arch/arm/arm64/domctl.c b/xen/arch/arm/arm64/domctl.c
> index 14fc622e9956..8720d126c97d 100644
> --- a/xen/arch/arm/arm64/domctl.c
> +++ b/xen/arch/arm/arm64/domctl.c
> @@ -33,27 +33,31 @@ static long switch_mode(struct domain *d, enum 
> domain_type type)
>       return 0;
>   }
> 
> +static long set_address_size(struct domain *d, uint32_t address_size)
> +{
> +    switch ( address_size )
> +    {
> +    case 32:
> +        if ( !cpu_has_el1_32 )
> +            return -EINVAL;
> +        /* SVE is not supported for 32 bit domain */
> +        if ( is_sve_domain(d) )
> +            return -EINVAL;
> +        return switch_mode(d, DOMAIN_32BIT);
> +    case 64:
> +        return switch_mode(d, DOMAIN_64BIT);
> +    default:
> +        return -EINVAL;
> +    }
> +}

Well, yes, if you're happy to have a function returning a value without
a return statement at its end.

Jan



 


Rackspace

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