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

Re: [XEN PATCH 11/11] x86/mm: Add assertion to address MISRA C:2012 Rule 2.1


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 3 Aug 2023 17:41:43 +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=9P4uoyU/0qNGHpXBbsPek+ERlXRrnBGIV/T9hzgJSIM=; b=U/zauUSQK3hhYo33+yNNx1NNQnAIpf8uXNZao58aDcoqSea6FogIR7qZ6r+yIi10r2nKqHo8ih9dmfCZWscWiuahzNy4dgnzmbqg0naYaJzNKTiEphH84kV/4seLrGO42xezTSpdfhKmaY4L+sxymkFOmiNfPd/EB+tgEULhEEIzSTis6Yy1/BzTpMnK/dKSyeNRd9Sf4dl3SKB/9d2Fs8wxSBVh3Ar3JwQLcFiuiVkdq8GDsDmU/OMeIkmR07ukCRnrF9KiidA9ndQ8e//Jon3RyloVSKXlil0sIgoIKCcqdVcPQPESaUH6nWuRrZlpJgZaINWAG3PA6lDM/u8LxA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ObjJ59AJUxZJaWbPtVMFGIWc7DPSa+pywJfhFgzv+Xza+4HwQo1Viup5ATSWVrASDFa2V87zUfEpDuGE+lnrlZcj+lgofIeB2oavJayUf4MWd8lnDT8pXDuvatGPi/gMwloYMLGsrm8bUCXrk/dr8MuXC9kWYyYq0HddTiNP8sc3d3wq/9KkbKBd3XgBYeQt40s3cqB9+LISnh8vRLnLMN6Gz9mR5xlMYXHavIgrVCb8i5gvamyZ9fTDe9dM01xN/Pd+/cuaei+HX09VK1fxmTDvJ/kJZzft0PUr2mNEVD15caILu1XER0ic88EGpEYPCmq/Fz1BJ3XWEz4ivC3Dzw==
  • 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>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 03 Aug 2023 15:42:18 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 03.08.2023 11:30, Nicola Vetrini wrote:
> On 03/08/2023 11:20, Jan Beulich wrote:
>> On 02.08.2023 16:38, Nicola Vetrini wrote:
>>> --- a/xen/arch/x86/mm/p2m-pod.c
>>> +++ b/xen/arch/x86/mm/p2m-pod.c
>>> @@ -1045,6 +1045,7 @@ p2m_pod_zero_check(struct p2m_domain *p2m, const 
>>> gfn_t *gfns, unsigned int count
>>>      }
>>>
>>>      return;
>>> +    ASSERT_UNREACHABLE();
>>>
>>>  out_unmap:
>>>      /*
>>
>> In the description you say "before", but here you add something _after_
>> "return". What's the deal?
> 
> In this case the unreachable part is that after the label (looking at it 
> now, I should have
> put the assert after the label to make it clear), because earlier all 
> jumps to
> 'out_unmap' are like this:
> 
>    ASSERT_UNREACHABLE();
>    domain_crash(d);
>    goto out_unmap;
> 
> As I understood it, this is a defensive coding measure, preventing pages 
> to remain mapped if,
> for some reason the above code actually executes. Am I correct?

The comment there says "probably". So the label and following code might
be used for another error condition as well. Furthermore both paths
presently using "goto out_unmap" already have ASSERT_UNREACHABLE(), so
it's hard to see why we would need yet one more.

Jan



 


Rackspace

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