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

[PATCH 4/4] automation/eclair: deviate MISRA C Rule 11.8 for xfree() and vfree()


  • To: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
  • Date: Tue, 3 Nov 2026 10:29:21 +0000
  • Accept-language: en-US, uk-UA, ru-RU
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=GmyJV2z2i0zx/4g7jYycmEWq4+mTFreYVSl+ZBWxbtk=; b=vVfK3vXSBiZk2KUU+tHNahalpyVP9t/GiDA2yezxkv/0JLs6Gg5fri23uRq6mCL6GrEq7PLdv1G6Jmu7P+eJRjMTVp78BOu2KONVgPrXsAhwDz1oAH9PiFGhuPspe0RA3LJOWLguW+Eapt+mwT/H0lg7iVK4g/GU3Ov3eCfXofrtEBf2bKGVjVuGzP3EJh2EQDZPNxlngABZYLuZEqGfPy0enFzErHv4rsJU6JritYmqw0Hbq7pNr+0p+vIvTmSzPDOGjCwGEArRtvHmQSo3EzN3JN8anc44BhUuW0XpRzUR+ljeFs0zjIVg7oAUr9OFbiCrgYVzgsPl9mfiAo95Ow==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=GtEAFNoww+Z+BgFz+PeUyQDbtE5moWgXwqw9Wdqs21SMAWkfymIKr9/2oKq3sHC11HZVEaiu0Zt0jgvH79nb64Xl/xLhK4UDIWHURhh0bbpFRxGhVPFsH9CDR4hey4rYlZneQRwMKaMO2PcSiRJUckeYbrhKBJK1TgKmDlQNkqna8ERP9ClFvZUp7FT2xIGq0zru30CqPh9JTz+gBy5E0LcoVaLcrnqW0wki3VJn2pE9cUPCmHggQABMeshh1QNLi+ac3RYtSu5VrvR1ToPJiXBoBbsr7hj55jqIaz8jNHfOwLdRt3CSAK9EYv/UtjFB5RBcYJmEMBHlGya5YDXXKQ==
  • Authentication-results: eu.smtp.expurgate.cloud; dkim=pass header.s=selector1 header.d=epam.com header.i="@epam.com" header.h="From:Date:Subject:Message-ID:Content-Type:MIME-Version:x-ms-exchange-senderadcheck"
  • Authentication-results: mx.microsoft.com 1; dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger@xxxxxxxxxxxxxx>
  • Delivery-date: Tue, 03 Nov 2026 10:29:27 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHda34w0w1h9rHZXkauKb0cj6wBhQ==
  • Thread-topic: [PATCH 4/4] automation/eclair: deviate MISRA C Rule 11.8 for xfree() and vfree()

Livepatch passes const-qualified pointers from struct payload to xfree()
and vfree(), which take a 'void *' argument. The cast that removes the
const qualifier is a violation of MISRA C Rule 11.8.

Such casts are safe. The deallocation functions neither read nor write
the content of the object being freed, and the object is not accessed
after it has been freed. Deviate the rule for casts that are direct
arguments of calls to xfree() and vfree().

No functional changes.

Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@xxxxxxxx>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 7 +++++++
 docs/misra/deviations.rst                        | 7 +++++++
 docs/misra/rules.rst                             | 3 ++-
 3 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index c7a800c62f..2fce0d0f68 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -451,6 +451,13 @@ write or not"
 
-config=MC3A2.R11.8,reports+={safe,"any_area(any_loc(file(hvm_guestcopy)&&text(^.*__hvm_copy.*HVMCOPY_to_guest
 doesn't modify.*$)))"}
 -doc_end
 
+-doc_begin="Casting away the const qualifier from the argument of the memory
+deallocation functions xfree() and vfree() is safe. These functions neither
+read nor write the content of the object being freed, and the object is not
+accessed after it has been freed."
+-config=MC3A2.R11.8,casts+={safe, 
"context(skip_to(__expr_non_syntactic_or_paren_contexts, 
call_child(name(xfree||vfree), arg)))"}
+-doc_end
+
 -doc_begin="This construct is used to check if the type is scalar, and for 
this purpose the use of 0 as a null pointer constant is deliberate."
 -config=MC3A2.R11.9,reports+={deliberate, 
"any_area(any_loc(any_exp(macro(^__ACCESS_ONCE$))))"
 }
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 76be6b3251..d8d074ae1a 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -440,6 +440,13 @@ Deviations related to MISRA C:2012 Rules:
        readability.
      - Tagged as `safe` for ECLAIR.
 
+   * - R11.8
+     - Casting away the const qualifier from the argument of the memory
+       deallocation functions xfree() and vfree() is safe. These functions
+       neither read nor write the content of the object being freed, and the
+       object is not accessed after it has been freed.
+     - Tagged as `safe` for ECLAIR.
+
    * - R11.9
      - __ACCESS_ONCE uses an integer, which happens to be zero, as a
        compile time check. The typecheck uses a cast. The usage of zero or 
other
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 5f9fe4c860..deff947c4f 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -475,7 +475,8 @@ maintainers if you want to suggest a change.
    * - `Rule 11.8 
<https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_08.c>`_
      - Required
      - A cast shall not remove any const or volatile qualification from the 
type pointed to by a pointer
-     -
+     - Casts removing the const qualifier from the argument of the memory
+       deallocation functions xfree() and vfree() are permitted.
 
    * - `Rule 11.9 
<https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_11_09.c>`_
      - Required
-- 
2.43.0

 


Rackspace

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