Re: [XEN PATCH v2 3/4] xen/vpci: address violations of MISRA C Rule 16.3

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Mon, 7 Oct 2024, Federico Serafini wrote:
> Address violations of MISRA C:2012 Rule 16.3:
> "An unconditional `break' statement shall terminate every
> switch-clause".
> 
> No functional change.
> 
> Signed-off-by: Federico Serafini <federico.serafini@xxxxxxxxxxx>
> ---
> Changes from v2:
> - simply break without returning X86EMUL_UNHANDLEABLE.
> 
> As pointed out by Jan, these functions only return X86EMUL_OKAY but:
> https://lists.xenproject.org/archives/html/xen-devel/2024-09/msg00727.html
> 
> Do you have any comments?
> ---
>  xen/drivers/vpci/msix.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/xen/drivers/vpci/msix.c b/xen/drivers/vpci/msix.c
> index fbe710ab92..5bb4444ce2 100644
> --- a/xen/drivers/vpci/msix.c
> +++ b/xen/drivers/vpci/msix.c
> @@ -364,6 +364,7 @@ static int adjacent_read(const struct domain *d, const 
> struct vpci_msix *msix,
>  
>      default:
>          ASSERT_UNREACHABLE();
> +        break;
>      }
>      spin_unlock(&vpci->lock);
>  
> @@ -512,6 +513,7 @@ static int adjacent_write(const struct domain *d, const 
> struct vpci_msix *msix,
>  
>      default:
>          ASSERT_UNREACHABLE();
> +        break;
>      }
>      spin_unlock(&vpci->lock);

I think in both cases it should be:

spin_unlock(&vpci->lock);
return X86EMUL_UNHANDLEABLE;

In general, it seems to be that we want to return X86EMUL_UNHANDLEABLE
in these situations and either we returning it from the default label,
or we need to do rc = X86EMUL_UNHANDLEABLE; and later on return rc;