* [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7
@ 2024-03-29 9:11 Nicola Vetrini
2024-03-29 9:11 ` [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style Nicola Vetrini
` (6 more replies)
0 siblings, 7 replies; 17+ messages in thread
From: Nicola Vetrini @ 2024-03-29 9:11 UTC (permalink / raw)
To: nicola.vetrini, xen-devel
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Jan Beulich, Andrew Cooper,
Roger Pau Monné, Volodymyr Babchuk, Simone Ballarin,
Doug Goldstein, George Dunlap
Hi all,
this series aims to refactor some macros that cause violations of MISRA C Rule
20.7 ("Expressions resulting from the expansion of macro parameters shall be
enclosed in parentheses"). All the macros touched by these patches are in some
way involved in violations, and the strategy adopted to bring them into
compliance is to add parentheses around macro arguments where needed.
Deviations from the rule have been amended to encompass also direct use in
initializer lists of macro arguments.
Patch 1 is taken, with adjustments, from the earlier series (which was
incorrectly tagged as v1). All other patches are new in this series and are
pairwise indipendent.
Nicola Vetrini (7):
x86/msi: address violation of MISRA C Rule 20.7 and coding style
arm/public: address violations of MISRA C Rule 20.7
x86/vPMU: address violations of MISRA C Rule 20.7
x86/hvm: address violations of MISRA C Rule 20.7
automation/eclair: add deviations for Rule 20.7
xen/mm: address violations of MISRA C Rule 20.7
x86/amd: address violations of MISRA C Rule 20.7
.../eclair_analysis/ECLAIR/deviations.ecl | 25 +++++++++-
docs/misra/deviations.rst | 14 +++++-
docs/misra/rules.rst | 2 +-
xen/arch/x86/hvm/domain.c | 6 +--
xen/arch/x86/include/asm/amd.h | 3 +-
xen/arch/x86/include/asm/msi.h | 49 ++++++++++---------
xen/arch/x86/include/asm/vpmu.h | 4 +-
xen/include/public/arch-arm.h | 2 +-
xen/include/xen/mm.h | 14 +++---
9 files changed, 77 insertions(+), 42 deletions(-)
--
2.34.1
^ permalink raw reply [flat|nested] 17+ messages in thread
* [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style
2024-03-29 9:11 [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 Nicola Vetrini
@ 2024-03-29 9:11 ` Nicola Vetrini
2024-04-02 15:05 ` Jan Beulich
2024-03-29 9:11 ` [XEN PATCH v3 2/7] arm/public: address violations of MISRA C Rule 20.7 Nicola Vetrini
` (5 subsequent siblings)
6 siblings, 1 reply; 17+ messages in thread
From: Nicola Vetrini @ 2024-03-29 9:11 UTC (permalink / raw)
To: nicola.vetrini, xen-devel
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Jan Beulich, Andrew Cooper,
Roger Pau Monné
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
While at it, the style of these macros has been somewhat uniformed.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
Changes in v2:
- Make the style change more consistent
---
xen/arch/x86/include/asm/msi.h | 49 +++++++++++++++++-----------------
1 file changed, 25 insertions(+), 24 deletions(-)
diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h
index 997ccb87be0c..bd110c357ce4 100644
--- a/xen/arch/x86/include/asm/msi.h
+++ b/xen/arch/x86/include/asm/msi.h
@@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
*/
#define NR_HP_RESERVED_VECTORS 20
-#define msi_control_reg(base) (base + PCI_MSI_FLAGS)
-#define msi_lower_address_reg(base) (base + PCI_MSI_ADDRESS_LO)
-#define msi_upper_address_reg(base) (base + PCI_MSI_ADDRESS_HI)
-#define msi_data_reg(base, is64bit) \
- ( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
-#define msi_mask_bits_reg(base, is64bit) \
- ( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
+#define msi_control_reg(base) ((base) + PCI_MSI_FLAGS)
+#define msi_lower_address_reg(base) ((base) + PCI_MSI_ADDRESS_LO)
+#define msi_upper_address_reg(base) ((base) + PCI_MSI_ADDRESS_HI)
+#define msi_data_reg(base, is64bit) \
+ (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) + PCI_MSI_DATA_32)
+#define msi_mask_bits_reg(base, is64bit) \
+ (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT \
+ : (base) + PCI_MSI_MASK_BIT - 4)
#define msi_pending_bits_reg(base, is64bit) \
- ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
-#define msi_disable(control) control &= ~PCI_MSI_FLAGS_ENABLE
+ ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
+#define msi_disable(control) ({ (control) &= ~PCI_MSI_FLAGS_ENABLE })
#define multi_msi_capable(control) \
- (1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
+ (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
#define multi_msi_enable(control, num) \
- control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
-#define is_64bit_address(control) (!!(control & PCI_MSI_FLAGS_64BIT))
-#define is_mask_bit_support(control) (!!(control & PCI_MSI_FLAGS_MASKBIT))
-#define msi_enable(control, num) multi_msi_enable(control, num); \
- control |= PCI_MSI_FLAGS_ENABLE
-
-#define msix_control_reg(base) (base + PCI_MSIX_FLAGS)
-#define msix_table_offset_reg(base) (base + PCI_MSIX_TABLE)
-#define msix_pba_offset_reg(base) (base + PCI_MSIX_PBA)
-#define msix_enable(control) control |= PCI_MSIX_FLAGS_ENABLE
-#define msix_disable(control) control &= ~PCI_MSIX_FLAGS_ENABLE
-#define msix_table_size(control) ((control & PCI_MSIX_FLAGS_QSIZE)+1)
-#define msix_unmask(address) (address & ~PCI_MSIX_VECTOR_BITMASK)
-#define msix_mask(address) (address | PCI_MSIX_VECTOR_BITMASK)
+ ({ (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE) })
+#define is_64bit_address(control) (!!((control) & PCI_MSI_FLAGS_64BIT))
+#define is_mask_bit_support(control) (!!((control) & PCI_MSI_FLAGS_MASKBIT))
+#define msi_enable(control, num) ({ multi_msi_enable(control, num); \
+ (control) |= PCI_MSI_FLAGS_ENABLE })
+
+#define msix_control_reg(base) ((base) + PCI_MSIX_FLAGS)
+#define msix_table_offset_reg(base) ((base) + PCI_MSIX_TABLE)
+#define msix_pba_offset_reg(base) ((base) + PCI_MSIX_PBA)
+#define msix_enable(control) ({ (control) |= PCI_MSIX_FLAGS_ENABLE })
+#define msix_disable(control) ({ (control) &= ~PCI_MSIX_FLAGS_ENABLE })
+#define msix_table_size(control) (((control) & PCI_MSIX_FLAGS_QSIZE) + 1)
+#define msix_unmask(address) ((address) & ~PCI_MSIX_VECTOR_BITMASK)
+#define msix_mask(address) ((address) | PCI_MSIX_VECTOR_BITMASK)
/*
* MSI Defined Data Structures
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [XEN PATCH v3 2/7] arm/public: address violations of MISRA C Rule 20.7
2024-03-29 9:11 [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 Nicola Vetrini
2024-03-29 9:11 ` [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style Nicola Vetrini
@ 2024-03-29 9:11 ` Nicola Vetrini
2024-04-05 0:11 ` Stefano Stabellini
2024-03-29 9:11 ` [XEN PATCH v3 3/7] x86/vPMU: " Nicola Vetrini
` (4 subsequent siblings)
6 siblings, 1 reply; 17+ messages in thread
From: Nicola Vetrini @ 2024-03-29 9:11 UTC (permalink / raw)
To: nicola.vetrini, xen-devel
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Volodymyr Babchuk
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
xen/include/public/arch-arm.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
index a25e87dbda3a..e167e14f8df9 100644
--- a/xen/include/public/arch-arm.h
+++ b/xen/include/public/arch-arm.h
@@ -209,7 +209,7 @@
do { \
__typeof__(&(hnd)) _sxghr_tmp = &(hnd); \
_sxghr_tmp->q = 0; \
- _sxghr_tmp->p = val; \
+ _sxghr_tmp->p = (val); \
} while ( 0 )
#define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [XEN PATCH v3 3/7] x86/vPMU: address violations of MISRA C Rule 20.7
2024-03-29 9:11 [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 Nicola Vetrini
2024-03-29 9:11 ` [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style Nicola Vetrini
2024-03-29 9:11 ` [XEN PATCH v3 2/7] arm/public: address violations of MISRA C Rule 20.7 Nicola Vetrini
@ 2024-03-29 9:11 ` Nicola Vetrini
2024-04-02 14:53 ` Jan Beulich
2024-03-29 9:11 ` [XEN PATCH v3 4/7] x86/hvm: " Nicola Vetrini
` (3 subsequent siblings)
6 siblings, 1 reply; 17+ messages in thread
From: Nicola Vetrini @ 2024-03-29 9:11 UTC (permalink / raw)
To: nicola.vetrini, xen-devel
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Jan Beulich, Andrew Cooper,
Roger Pau Monné
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
xen/arch/x86/include/asm/vpmu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/include/asm/vpmu.h b/xen/arch/x86/include/asm/vpmu.h
index f271f28e4a74..dae9b43dac6e 100644
--- a/xen/arch/x86/include/asm/vpmu.h
+++ b/xen/arch/x86/include/asm/vpmu.h
@@ -23,8 +23,8 @@
#define MSR_TYPE_ARCH_CTRL 4
/* Start of PMU register bank */
-#define vpmu_reg_pointer(ctxt, offset) ((void *)((uintptr_t)ctxt + \
- (uintptr_t)ctxt->offset))
+#define vpmu_reg_pointer(ctxt, offset) ((void *)((uintptr_t)(ctxt) + \
+ (uintptr_t)(ctxt)->offset))
/* Arch specific operations shared by all vpmus */
struct arch_vpmu_ops {
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [XEN PATCH v3 4/7] x86/hvm: address violations of MISRA C Rule 20.7
2024-03-29 9:11 [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 Nicola Vetrini
` (2 preceding siblings ...)
2024-03-29 9:11 ` [XEN PATCH v3 3/7] x86/vPMU: " Nicola Vetrini
@ 2024-03-29 9:11 ` Nicola Vetrini
2024-04-02 14:55 ` Jan Beulich
2024-03-29 9:11 ` [XEN PATCH v3 5/7] automation/eclair: add deviations for " Nicola Vetrini
` (2 subsequent siblings)
6 siblings, 1 reply; 17+ messages in thread
From: Nicola Vetrini @ 2024-03-29 9:11 UTC (permalink / raw)
To: nicola.vetrini, xen-devel
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Jan Beulich, Andrew Cooper,
Roger Pau Monné
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
xen/arch/x86/hvm/domain.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/xen/arch/x86/hvm/domain.c b/xen/arch/x86/hvm/domain.c
index 7f6e362a702e..b96cf93dd0ef 100644
--- a/xen/arch/x86/hvm/domain.c
+++ b/xen/arch/x86/hvm/domain.c
@@ -132,9 +132,9 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx)
s = (struct segment_register) \
{ 0, { (r)->s ## _ar }, (r)->s ## _limit, (r)->s ## _base }; \
/* Set accessed / busy bit for present segments. */ \
- if ( s.p ) \
- s.type |= (x86_seg_##s != x86_seg_tr ? 1 : 2); \
- check_segment(&s, x86_seg_ ## s); })
+ if ( (s).p ) \
+ (s).type |= (x86_seg_##s != x86_seg_tr ? 1 : 2); \
+ check_segment(&(s), x86_seg_ ## s); })
rc = SEG(cs, regs);
rc |= SEG(ds, regs);
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [XEN PATCH v3 5/7] automation/eclair: add deviations for Rule 20.7
2024-03-29 9:11 [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 Nicola Vetrini
` (3 preceding siblings ...)
2024-03-29 9:11 ` [XEN PATCH v3 4/7] x86/hvm: " Nicola Vetrini
@ 2024-03-29 9:11 ` Nicola Vetrini
2024-04-05 0:13 ` Stefano Stabellini
2024-04-05 0:27 ` Stefano Stabellini
2024-03-29 9:11 ` [XEN PATCH v3 6/7] xen/mm: address violations of MISRA C " Nicola Vetrini
2024-03-29 9:11 ` [XEN PATCH v3 7/7] x86/amd: " Nicola Vetrini
6 siblings, 2 replies; 17+ messages in thread
From: Nicola Vetrini @ 2024-03-29 9:11 UTC (permalink / raw)
To: nicola.vetrini, xen-devel
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Simone Ballarin,
Doug Goldstein, Andrew Cooper, George Dunlap, Jan Beulich
These deviations deal with the following cases:
- macro arguments used directly as initializer list arguments;
- uses of the __config_enabled macro, that can't be brought
into compliance without breaking its functionality;
- exclude files that are out of scope (efi headers and cpu_idle);
- uses of alternative_{call,vcall}[0-9] macros.
The existing configuration for R20.7 is reordered so that it matches the
cases listed in its documentation comment.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
.../eclair_analysis/ECLAIR/deviations.ecl | 25 +++++++++++++++++--
docs/misra/deviations.rst | 14 ++++++++++-
docs/misra/rules.rst | 2 +-
3 files changed, 37 insertions(+), 4 deletions(-)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index de9ba723fbc7..70756503f594 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -401,12 +401,33 @@ unexpected result when the structure is given as argument to a sizeof() operator
-doc_begin="Code violating Rule 20.7 is safe when macro parameters are used: (1)
as function arguments; (2) as macro arguments; (3) as array indices; (4) as lhs
-in assignments."
+in assignments; (5) as initializers, possibly designated, in initalizer lists."
-config=MC3R1.R20.7,expansion_context=
{safe, "context(__call_expr_arg_contexts)"},
+{safe, "left_right(^[(,\\[]$,^[),\\]]$)"},
{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(array_subscript_expr), subscript)))"},
{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(operator(assign), lhs)))"},
-{safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
+{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(init_list_expr||designated_init_expr), init)))"}
+-doc_end
+
+-doc_begin="Violations involving the __config_enabled macros cannot be fixed without
+breaking the macro's logic; futhermore, the macro is only ever used in the context
+of the IS_ENABLED or STATIC_IF/STATIC_IF_NOT macros, so it always receives a literal
+0 or 1 as input, posing no risk to safety."
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^___config_enabled$))))"}
+-doc_end
+
+-doc_begin="Violations due to the use of macros defined in files that are
+not in scope for compliance are allowed, as that is imported code."
+-file_tag+={gnu_efi_include, "^xen/include/efi/.*$"}
+-file_tag+={acpi_cpu_idle, "^xen/arch/x86/acpi/cpu_idle\\.c$"}
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(gnu_efi_include)))"}
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(acpi_cpu_idle)))"}
+-doc_end
+
+-doc_begin="To avoid compromising readability, the macros alternative_(v)?call[0-9] are allowed
+not to parenthesize their arguments."
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^alternative_(v)?call[0-9]$))))"}
-doc_end
-doc_begin="Uses of variadic macros that have one of their arguments defined as
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index eb5ef2bd9dd6..5fdacfd420a1 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -345,7 +345,19 @@ Deviations related to MISRA C:2012 Rules:
(1) as function arguments;
(2) as macro arguments;
(3) as array indices;
- (4) as lhs in assignments.
+ (4) as lhs in assignments;
+ (5) as initializers, possibly designated, in initalizer lists.
+ - Tagged as `safe` for ECLAIR.
+
+ * - R20.7
+ - Violations due to the use of macros defined in files that are not
+ in scope for compliance are allowed, as that is imported code.
+ - Tagged as `safe` for ECLAIR.
+
+ * - R20.7
+ - To avoid compromising readability, the macros `alternative_(v)?call[0-9]`
+ are allowed not to parenthesize their arguments, as there are already
+ sanity checks in place.
- Tagged as `safe` for ECLAIR.
* - R20.12
diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
index 1e134ccebc48..3914af08495b 100644
--- a/docs/misra/rules.rst
+++ b/docs/misra/rules.rst
@@ -560,7 +560,7 @@ maintainers if you want to suggest a change.
shall be enclosed in parentheses
- Extra parentheses are not required when macro parameters are used
as function arguments, as macro arguments, array indices, lhs in
- assignments
+ assignments or as initializers in initalizer lists.
* - `Rule 20.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_09.c>`_
- Required
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [XEN PATCH v3 6/7] xen/mm: address violations of MISRA C Rule 20.7
2024-03-29 9:11 [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 Nicola Vetrini
` (4 preceding siblings ...)
2024-03-29 9:11 ` [XEN PATCH v3 5/7] automation/eclair: add deviations for " Nicola Vetrini
@ 2024-03-29 9:11 ` Nicola Vetrini
2024-04-02 14:56 ` Jan Beulich
2024-03-29 9:11 ` [XEN PATCH v3 7/7] x86/amd: " Nicola Vetrini
6 siblings, 1 reply; 17+ messages in thread
From: Nicola Vetrini @ 2024-03-29 9:11 UTC (permalink / raw)
To: nicola.vetrini, xen-devel
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Andrew Cooper,
George Dunlap, Jan Beulich
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
xen/include/xen/mm.h | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/xen/include/xen/mm.h b/xen/include/xen/mm.h
index 3e84960a365f..7561297a7553 100644
--- a/xen/include/xen/mm.h
+++ b/xen/include/xen/mm.h
@@ -415,15 +415,15 @@ page_list_splice(struct page_list_head *list, struct page_list_head *head)
}
#define page_list_for_each(pos, head) \
- for ( pos = (head)->next; pos; pos = page_list_next(pos, head) )
+ for ( (pos) = (head)->next; (pos); (pos) = page_list_next(pos, head) )
#define page_list_for_each_safe(pos, tmp, head) \
- for ( pos = (head)->next; \
- pos ? (tmp = page_list_next(pos, head), 1) : 0; \
- pos = tmp )
+ for ( (pos) = (head)->next; \
+ (pos) ? ((tmp) = page_list_next(pos, head), 1) : 0; \
+ (pos) = (tmp) )
#define page_list_for_each_safe_reverse(pos, tmp, head) \
- for ( pos = (head)->tail; \
- pos ? (tmp = page_list_prev(pos, head), 1) : 0; \
- pos = tmp )
+ for ( (pos) = (head)->tail; \
+ (pos) ? ((tmp) = page_list_prev(pos, head), 1) : 0; \
+ (pos) = (tmp) )
#else
# define page_list_head list_head
# define PAGE_LIST_HEAD_INIT LIST_HEAD_INIT
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* [XEN PATCH v3 7/7] x86/amd: address violations of MISRA C Rule 20.7
2024-03-29 9:11 [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 Nicola Vetrini
` (5 preceding siblings ...)
2024-03-29 9:11 ` [XEN PATCH v3 6/7] xen/mm: address violations of MISRA C " Nicola Vetrini
@ 2024-03-29 9:11 ` Nicola Vetrini
2024-04-02 14:57 ` Jan Beulich
6 siblings, 1 reply; 17+ messages in thread
From: Nicola Vetrini @ 2024-03-29 9:11 UTC (permalink / raw)
To: nicola.vetrini, xen-devel
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Jan Beulich, Andrew Cooper,
Roger Pau Monné
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses". Therefore, some
macro definitions should gain additional parentheses to ensure that all
current and future users will be safe with respect to expansions that
can possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
xen/arch/x86/include/asm/amd.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/xen/arch/x86/include/asm/amd.h b/xen/arch/x86/include/asm/amd.h
index 2cc0ce2e9fd2..fa4e0fc766aa 100644
--- a/xen/arch/x86/include/asm/amd.h
+++ b/xen/arch/x86/include/asm/amd.h
@@ -119,7 +119,8 @@
#define AMD_LEGACY_ERRATUM(...) -1 /* legacy */, __VA_ARGS__, 0
#define AMD_OSVW_ERRATUM(osvw_id, ...) osvw_id, __VA_ARGS__, 0
#define AMD_MODEL_RANGE(f, m_start, s_start, m_end, s_end) \
- ((f << 24) | (m_start << 16) | (s_start << 12) | (m_end << 4) | (s_end))
+ (((f) << 24) | ((m_start) << 16) | ((s_start) << 12) | \
+ ((m_end) << 4) | (s_end))
#define AMD_MODEL_RANGE_FAMILY(range) (((range) >> 24) & 0xff)
#define AMD_MODEL_RANGE_START(range) (((range) >> 12) & 0xfff)
#define AMD_MODEL_RANGE_END(range) ((range) & 0xfff)
--
2.34.1
^ permalink raw reply related [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 3/7] x86/vPMU: address violations of MISRA C Rule 20.7
2024-03-29 9:11 ` [XEN PATCH v3 3/7] x86/vPMU: " Nicola Vetrini
@ 2024-04-02 14:53 ` Jan Beulich
0 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2024-04-02 14:53 UTC (permalink / raw)
To: Nicola Vetrini
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Andrew Cooper,
Roger Pau Monné, xen-devel
On 29.03.2024 10:11, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 4/7] x86/hvm: address violations of MISRA C Rule 20.7
2024-03-29 9:11 ` [XEN PATCH v3 4/7] x86/hvm: " Nicola Vetrini
@ 2024-04-02 14:55 ` Jan Beulich
0 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2024-04-02 14:55 UTC (permalink / raw)
To: Nicola Vetrini
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Andrew Cooper,
Roger Pau Monné, xen-devel
On 29.03.2024 10:11, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
albeit once again ...
> --- a/xen/arch/x86/hvm/domain.c
> +++ b/xen/arch/x86/hvm/domain.c
> @@ -132,9 +132,9 @@ int arch_set_info_hvm_guest(struct vcpu *v, const struct vcpu_hvm_context *ctx)
> s = (struct segment_register) \
> { 0, { (r)->s ## _ar }, (r)->s ## _limit, (r)->s ## _base }; \
> /* Set accessed / busy bit for present segments. */ \
> - if ( s.p ) \
> - s.type |= (x86_seg_##s != x86_seg_tr ? 1 : 2); \
> - check_segment(&s, x86_seg_ ## s); })
> + if ( (s).p ) \
> + (s).type |= (x86_seg_##s != x86_seg_tr ? 1 : 2); \
... addressing the style issue (blanks around ##) while touching code would have
been nice.
Jan
> + check_segment(&(s), x86_seg_ ## s); })
>
> rc = SEG(cs, regs);
> rc |= SEG(ds, regs);
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 6/7] xen/mm: address violations of MISRA C Rule 20.7
2024-03-29 9:11 ` [XEN PATCH v3 6/7] xen/mm: address violations of MISRA C " Nicola Vetrini
@ 2024-04-02 14:56 ` Jan Beulich
0 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2024-04-02 14:56 UTC (permalink / raw)
To: Nicola Vetrini
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Andrew Cooper,
George Dunlap, xen-devel
On 29.03.2024 10:11, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 7/7] x86/amd: address violations of MISRA C Rule 20.7
2024-03-29 9:11 ` [XEN PATCH v3 7/7] x86/amd: " Nicola Vetrini
@ 2024-04-02 14:57 ` Jan Beulich
0 siblings, 0 replies; 17+ messages in thread
From: Jan Beulich @ 2024-04-02 14:57 UTC (permalink / raw)
To: Nicola Vetrini
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Andrew Cooper,
Roger Pau Monné, xen-devel
On 29.03.2024 10:11, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Acked-by: Jan Beulich <jbeulich@suse.com>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style
2024-03-29 9:11 ` [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style Nicola Vetrini
@ 2024-04-02 15:05 ` Jan Beulich
2024-04-02 17:23 ` Nicola Vetrini
0 siblings, 1 reply; 17+ messages in thread
From: Jan Beulich @ 2024-04-02 15:05 UTC (permalink / raw)
To: Nicola Vetrini
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Andrew Cooper,
Roger Pau Monné, xen-devel
On 29.03.2024 10:11, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
>
> While at it, the style of these macros has been somewhat uniformed.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> ---
> Changes in v2:
> - Make the style change more consistent
> ---
> xen/arch/x86/include/asm/msi.h | 49 +++++++++++++++++-----------------
> 1 file changed, 25 insertions(+), 24 deletions(-)
>
> diff --git a/xen/arch/x86/include/asm/msi.h b/xen/arch/x86/include/asm/msi.h
> index 997ccb87be0c..bd110c357ce4 100644
> --- a/xen/arch/x86/include/asm/msi.h
> +++ b/xen/arch/x86/include/asm/msi.h
> @@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
> */
> #define NR_HP_RESERVED_VECTORS 20
>
> -#define msi_control_reg(base) (base + PCI_MSI_FLAGS)
> -#define msi_lower_address_reg(base) (base + PCI_MSI_ADDRESS_LO)
> -#define msi_upper_address_reg(base) (base + PCI_MSI_ADDRESS_HI)
> -#define msi_data_reg(base, is64bit) \
> - ( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
> -#define msi_mask_bits_reg(base, is64bit) \
> - ( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
> +#define msi_control_reg(base) ((base) + PCI_MSI_FLAGS)
> +#define msi_lower_address_reg(base) ((base) + PCI_MSI_ADDRESS_LO)
> +#define msi_upper_address_reg(base) ((base) + PCI_MSI_ADDRESS_HI)
> +#define msi_data_reg(base, is64bit) \
> + (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) + PCI_MSI_DATA_32)
> +#define msi_mask_bits_reg(base, is64bit) \
> + (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT \
> + : (base) + PCI_MSI_MASK_BIT - 4)
> #define msi_pending_bits_reg(base, is64bit) \
> - ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
> -#define msi_disable(control) control &= ~PCI_MSI_FLAGS_ENABLE
> + ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
> +#define msi_disable(control) ({ (control) &= ~PCI_MSI_FLAGS_ENABLE })
> #define multi_msi_capable(control) \
> - (1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
> + (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
> #define multi_msi_enable(control, num) \
> - control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
> -#define is_64bit_address(control) (!!(control & PCI_MSI_FLAGS_64BIT))
> -#define is_mask_bit_support(control) (!!(control & PCI_MSI_FLAGS_MASKBIT))
> -#define msi_enable(control, num) multi_msi_enable(control, num); \
> - control |= PCI_MSI_FLAGS_ENABLE
> -
> -#define msix_control_reg(base) (base + PCI_MSIX_FLAGS)
> -#define msix_table_offset_reg(base) (base + PCI_MSIX_TABLE)
> -#define msix_pba_offset_reg(base) (base + PCI_MSIX_PBA)
> -#define msix_enable(control) control |= PCI_MSIX_FLAGS_ENABLE
> -#define msix_disable(control) control &= ~PCI_MSIX_FLAGS_ENABLE
> -#define msix_table_size(control) ((control & PCI_MSIX_FLAGS_QSIZE)+1)
> -#define msix_unmask(address) (address & ~PCI_MSIX_VECTOR_BITMASK)
> -#define msix_mask(address) (address | PCI_MSIX_VECTOR_BITMASK)
> + ({ (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE) })
> +#define is_64bit_address(control) (!!((control) & PCI_MSI_FLAGS_64BIT))
> +#define is_mask_bit_support(control) (!!((control) & PCI_MSI_FLAGS_MASKBIT))
> +#define msi_enable(control, num) ({ multi_msi_enable(control, num); \
> + (control) |= PCI_MSI_FLAGS_ENABLE })
Neither this nor ...
> +#define msix_control_reg(base) ((base) + PCI_MSIX_FLAGS)
> +#define msix_table_offset_reg(base) ((base) + PCI_MSIX_TABLE)
> +#define msix_pba_offset_reg(base) ((base) + PCI_MSIX_PBA)
> +#define msix_enable(control) ({ (control) |= PCI_MSIX_FLAGS_ENABLE })
> +#define msix_disable(control) ({ (control) &= ~PCI_MSIX_FLAGS_ENABLE })
... these would compile afaict, if they were used.
Once again - before fiddling with these we need to settle on which of these
we want to keep (and then also use, rather than open-coding), and which to
drop (instead of massaging).
Jan
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style
2024-04-02 15:05 ` Jan Beulich
@ 2024-04-02 17:23 ` Nicola Vetrini
0 siblings, 0 replies; 17+ messages in thread
From: Nicola Vetrini @ 2024-04-02 17:23 UTC (permalink / raw)
To: Jan Beulich
Cc: sstabellini, michal.orzel, xenia.ragiadakou, ayan.kumar.halder,
consulting, bertrand.marquis, julien, Andrew Cooper,
Roger Pau Monné, xen-devel
On 2024-04-02 17:05, Jan Beulich wrote:
> On 29.03.2024 10:11, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses". Therefore, some
>> macro definitions should gain additional parentheses to ensure that
>> all
>> current and future users will be safe with respect to expansions that
>> can possibly alter the semantics of the passed-in macro parameter.
>>
>> While at it, the style of these macros has been somewhat uniformed.
>>
>> No functional change.
>>
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> ---
>> Changes in v2:
>> - Make the style change more consistent
>> ---
>> xen/arch/x86/include/asm/msi.h | 49
>> +++++++++++++++++-----------------
>> 1 file changed, 25 insertions(+), 24 deletions(-)
>>
>> diff --git a/xen/arch/x86/include/asm/msi.h
>> b/xen/arch/x86/include/asm/msi.h
>> index 997ccb87be0c..bd110c357ce4 100644
>> --- a/xen/arch/x86/include/asm/msi.h
>> +++ b/xen/arch/x86/include/asm/msi.h
>> @@ -147,33 +147,34 @@ int msi_free_irq(struct msi_desc *entry);
>> */
>> #define NR_HP_RESERVED_VECTORS 20
>>
>> -#define msi_control_reg(base) (base + PCI_MSI_FLAGS)
>> -#define msi_lower_address_reg(base) (base + PCI_MSI_ADDRESS_LO)
>> -#define msi_upper_address_reg(base) (base + PCI_MSI_ADDRESS_HI)
>> -#define msi_data_reg(base, is64bit) \
>> - ( (is64bit == 1) ? base+PCI_MSI_DATA_64 : base+PCI_MSI_DATA_32 )
>> -#define msi_mask_bits_reg(base, is64bit) \
>> - ( (is64bit == 1) ? base+PCI_MSI_MASK_BIT : base+PCI_MSI_MASK_BIT-4)
>> +#define msi_control_reg(base) ((base) + PCI_MSI_FLAGS)
>> +#define msi_lower_address_reg(base) ((base) + PCI_MSI_ADDRESS_LO)
>> +#define msi_upper_address_reg(base) ((base) + PCI_MSI_ADDRESS_HI)
>> +#define msi_data_reg(base, is64bit) \
>> + (((is64bit) == 1) ? (base) + PCI_MSI_DATA_64 : (base) +
>> PCI_MSI_DATA_32)
>> +#define msi_mask_bits_reg(base, is64bit) \
>> + (((is64bit) == 1) ? (base) + PCI_MSI_MASK_BIT \
>> + : (base) + PCI_MSI_MASK_BIT - 4)
>> #define msi_pending_bits_reg(base, is64bit) \
>> - ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
>> -#define msi_disable(control) control &= ~PCI_MSI_FLAGS_ENABLE
>> + ((base) + PCI_MSI_MASK_BIT + ((is64bit) ? 4 : 0))
>> +#define msi_disable(control) ({ (control) &=
>> ~PCI_MSI_FLAGS_ENABLE })
>> #define multi_msi_capable(control) \
>> - (1 << ((control & PCI_MSI_FLAGS_QMASK) >> 1))
>> + (1 << (((control) & PCI_MSI_FLAGS_QMASK) >> 1))
>> #define multi_msi_enable(control, num) \
>> - control |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE);
>> -#define is_64bit_address(control) (!!(control & PCI_MSI_FLAGS_64BIT))
>> -#define is_mask_bit_support(control) (!!(control &
>> PCI_MSI_FLAGS_MASKBIT))
>> -#define msi_enable(control, num) multi_msi_enable(control, num); \
>> - control |= PCI_MSI_FLAGS_ENABLE
>> -
>> -#define msix_control_reg(base) (base + PCI_MSIX_FLAGS)
>> -#define msix_table_offset_reg(base) (base + PCI_MSIX_TABLE)
>> -#define msix_pba_offset_reg(base) (base + PCI_MSIX_PBA)
>> -#define msix_enable(control) control |= PCI_MSIX_FLAGS_ENABLE
>> -#define msix_disable(control) control &= ~PCI_MSIX_FLAGS_ENABLE
>> -#define msix_table_size(control) ((control &
>> PCI_MSIX_FLAGS_QSIZE)+1)
>> -#define msix_unmask(address) (address & ~PCI_MSIX_VECTOR_BITMASK)
>> -#define msix_mask(address) (address | PCI_MSIX_VECTOR_BITMASK)
>> + ({ (control) |= (((fls(num) - 1) << 4) & PCI_MSI_FLAGS_QSIZE) })
>> +#define is_64bit_address(control) (!!((control) &
>> PCI_MSI_FLAGS_64BIT))
>> +#define is_mask_bit_support(control) (!!((control) &
>> PCI_MSI_FLAGS_MASKBIT))
>> +#define msi_enable(control, num) ({ multi_msi_enable(control,
>> num); \
>> + (control) |=
>> PCI_MSI_FLAGS_ENABLE })
>
> Neither this nor ...
>
>> +#define msix_control_reg(base) ((base) + PCI_MSIX_FLAGS)
>> +#define msix_table_offset_reg(base) ((base) + PCI_MSIX_TABLE)
>> +#define msix_pba_offset_reg(base) ((base) + PCI_MSIX_PBA)
>> +#define msix_enable(control) ({ (control) |=
>> PCI_MSIX_FLAGS_ENABLE })
>> +#define msix_disable(control) ({ (control) &=
>> ~PCI_MSIX_FLAGS_ENABLE })
>
> ... these would compile afaict, if they were used.
>
> Once again - before fiddling with these we need to settle on which of
> these
> we want to keep (and then also use, rather than open-coding), and which
> to
> drop (instead of massaging).
>
> Jan
Ok, we can drop this patch from this for now.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 2/7] arm/public: address violations of MISRA C Rule 20.7
2024-03-29 9:11 ` [XEN PATCH v3 2/7] arm/public: address violations of MISRA C Rule 20.7 Nicola Vetrini
@ 2024-04-05 0:11 ` Stefano Stabellini
0 siblings, 0 replies; 17+ messages in thread
From: Stefano Stabellini @ 2024-04-05 0:11 UTC (permalink / raw)
To: Nicola Vetrini
Cc: xen-devel, sstabellini, michal.orzel, xenia.ragiadakou,
ayan.kumar.halder, consulting, bertrand.marquis, julien,
Volodymyr Babchuk
On Fri, 29 Mar 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses". Therefore, some
> macro definitions should gain additional parentheses to ensure that all
> current and future users will be safe with respect to expansions that
> can possibly alter the semantics of the passed-in macro parameter.
>
> No functional change.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> xen/include/public/arch-arm.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/xen/include/public/arch-arm.h b/xen/include/public/arch-arm.h
> index a25e87dbda3a..e167e14f8df9 100644
> --- a/xen/include/public/arch-arm.h
> +++ b/xen/include/public/arch-arm.h
> @@ -209,7 +209,7 @@
> do { \
> __typeof__(&(hnd)) _sxghr_tmp = &(hnd); \
> _sxghr_tmp->q = 0; \
> - _sxghr_tmp->p = val; \
> + _sxghr_tmp->p = (val); \
> } while ( 0 )
> #define set_xen_guest_handle(hnd, val) set_xen_guest_handle_raw(hnd, val)
>
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 5/7] automation/eclair: add deviations for Rule 20.7
2024-03-29 9:11 ` [XEN PATCH v3 5/7] automation/eclair: add deviations for " Nicola Vetrini
@ 2024-04-05 0:13 ` Stefano Stabellini
2024-04-05 0:27 ` Stefano Stabellini
1 sibling, 0 replies; 17+ messages in thread
From: Stefano Stabellini @ 2024-04-05 0:13 UTC (permalink / raw)
To: Nicola Vetrini
Cc: xen-devel, sstabellini, michal.orzel, xenia.ragiadakou,
ayan.kumar.halder, consulting, bertrand.marquis, julien,
Simone Ballarin, Doug Goldstein, Andrew Cooper, George Dunlap,
Jan Beulich
On Fri, 29 Mar 2024, Nicola Vetrini wrote:
> These deviations deal with the following cases:
> - macro arguments used directly as initializer list arguments;
> - uses of the __config_enabled macro, that can't be brought
> into compliance without breaking its functionality;
> - exclude files that are out of scope (efi headers and cpu_idle);
> - uses of alternative_{call,vcall}[0-9] macros.
>
> The existing configuration for R20.7 is reordered so that it matches the
> cases listed in its documentation comment.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [XEN PATCH v3 5/7] automation/eclair: add deviations for Rule 20.7
2024-03-29 9:11 ` [XEN PATCH v3 5/7] automation/eclair: add deviations for " Nicola Vetrini
2024-04-05 0:13 ` Stefano Stabellini
@ 2024-04-05 0:27 ` Stefano Stabellini
1 sibling, 0 replies; 17+ messages in thread
From: Stefano Stabellini @ 2024-04-05 0:27 UTC (permalink / raw)
To: Nicola Vetrini
Cc: xen-devel, sstabellini, michal.orzel, xenia.ragiadakou,
ayan.kumar.halder, consulting, bertrand.marquis, julien,
Simone Ballarin, Doug Goldstein, Andrew Cooper, George Dunlap,
Jan Beulich
On Fri, 29 Mar 2024, Nicola Vetrini wrote:
> These deviations deal with the following cases:
> - macro arguments used directly as initializer list arguments;
> - uses of the __config_enabled macro, that can't be brought
> into compliance without breaking its functionality;
> - exclude files that are out of scope (efi headers and cpu_idle);
> - uses of alternative_{call,vcall}[0-9] macros.
>
> The existing configuration for R20.7 is reordered so that it matches the
> cases listed in its documentation comment.
>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> ---
> .../eclair_analysis/ECLAIR/deviations.ecl | 25 +++++++++++++++++--
> docs/misra/deviations.rst | 14 ++++++++++-
> docs/misra/rules.rst | 2 +-
> 3 files changed, 37 insertions(+), 4 deletions(-)
>
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index de9ba723fbc7..70756503f594 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -401,12 +401,33 @@ unexpected result when the structure is given as argument to a sizeof() operator
>
> -doc_begin="Code violating Rule 20.7 is safe when macro parameters are used: (1)
> as function arguments; (2) as macro arguments; (3) as array indices; (4) as lhs
> -in assignments."
> +in assignments; (5) as initializers, possibly designated, in initalizer lists."
> -config=MC3R1.R20.7,expansion_context=
> {safe, "context(__call_expr_arg_contexts)"},
> +{safe, "left_right(^[(,\\[]$,^[),\\]]$)"},
> {safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(array_subscript_expr), subscript)))"},
> {safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(operator(assign), lhs)))"},
> -{safe, "left_right(^[(,\\[]$,^[),\\]]$)"}
> +{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(init_list_expr||designated_init_expr), init)))"}
> +-doc_end
> +
> +-doc_begin="Violations involving the __config_enabled macros cannot be fixed without
> +breaking the macro's logic; futhermore, the macro is only ever used in the context
> +of the IS_ENABLED or STATIC_IF/STATIC_IF_NOT macros, so it always receives a literal
> +0 or 1 as input, posing no risk to safety."
> +-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^___config_enabled$))))"}
> +-doc_end
> +
> +-doc_begin="Violations due to the use of macros defined in files that are
> +not in scope for compliance are allowed, as that is imported code."
> +-file_tag+={gnu_efi_include, "^xen/include/efi/.*$"}
> +-file_tag+={acpi_cpu_idle, "^xen/arch/x86/acpi/cpu_idle\\.c$"}
> +-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(gnu_efi_include)))"}
> +-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(file(acpi_cpu_idle)))"}
> +-doc_end
> +
> +-doc_begin="To avoid compromising readability, the macros alternative_(v)?call[0-9] are allowed
> +not to parenthesize their arguments."
> +-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^alternative_(v)?call[0-9]$))))"}
> -doc_end
>
> -doc_begin="Uses of variadic macros that have one of their arguments defined as
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index eb5ef2bd9dd6..5fdacfd420a1 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -345,7 +345,19 @@ Deviations related to MISRA C:2012 Rules:
> (1) as function arguments;
> (2) as macro arguments;
> (3) as array indices;
> - (4) as lhs in assignments.
> + (4) as lhs in assignments;
> + (5) as initializers, possibly designated, in initalizer lists.
> + - Tagged as `safe` for ECLAIR.
> +
> + * - R20.7
> + - Violations due to the use of macros defined in files that are not
> + in scope for compliance are allowed, as that is imported code.
> + - Tagged as `safe` for ECLAIR.
> +
> + * - R20.7
> + - To avoid compromising readability, the macros `alternative_(v)?call[0-9]`
> + are allowed not to parenthesize their arguments, as there are already
> + sanity checks in place.
> - Tagged as `safe` for ECLAIR.
>
> * - R20.12
> diff --git a/docs/misra/rules.rst b/docs/misra/rules.rst
> index 1e134ccebc48..3914af08495b 100644
> --- a/docs/misra/rules.rst
> +++ b/docs/misra/rules.rst
> @@ -560,7 +560,7 @@ maintainers if you want to suggest a change.
> shall be enclosed in parentheses
> - Extra parentheses are not required when macro parameters are used
> as function arguments, as macro arguments, array indices, lhs in
> - assignments
> + assignments or as initializers in initalizer lists.
>
> * - `Rule 20.9 <https://gitlab.com/MISRA/MISRA-C/MISRA-C-2012/Example-Suite/-/blob/master/R_20_09.c>`_
> - Required
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2024-04-05 0:28 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-29 9:11 [XEN PATCH v3 0/7] address violations of MISRA C Rule 20.7 Nicola Vetrini
2024-03-29 9:11 ` [XEN PATCH v3 1/7] x86/msi: address violation of MISRA C Rule 20.7 and coding style Nicola Vetrini
2024-04-02 15:05 ` Jan Beulich
2024-04-02 17:23 ` Nicola Vetrini
2024-03-29 9:11 ` [XEN PATCH v3 2/7] arm/public: address violations of MISRA C Rule 20.7 Nicola Vetrini
2024-04-05 0:11 ` Stefano Stabellini
2024-03-29 9:11 ` [XEN PATCH v3 3/7] x86/vPMU: " Nicola Vetrini
2024-04-02 14:53 ` Jan Beulich
2024-03-29 9:11 ` [XEN PATCH v3 4/7] x86/hvm: " Nicola Vetrini
2024-04-02 14:55 ` Jan Beulich
2024-03-29 9:11 ` [XEN PATCH v3 5/7] automation/eclair: add deviations for " Nicola Vetrini
2024-04-05 0:13 ` Stefano Stabellini
2024-04-05 0:27 ` Stefano Stabellini
2024-03-29 9:11 ` [XEN PATCH v3 6/7] xen/mm: address violations of MISRA C " Nicola Vetrini
2024-04-02 14:56 ` Jan Beulich
2024-03-29 9:11 ` [XEN PATCH v3 7/7] x86/amd: " Nicola Vetrini
2024-04-02 14:57 ` Jan Beulich
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.