[XEN PATCH v2 0/6][RESEND] address violations of MISRA C Rule 20.7

[XEN PATCH v2 0/6][RESEND] address violations of MISRA C Rule 20.7

[Nicola Vetrini]

Hi all,

this series addresses several violations of Rule 20.7, as well as a
small fix to the ECLAIR integration scripts that do not influence
the current behaviour, but were mistakenly part of the upstream
configuration.

Note that by applying this series the rule has a few leftover violations.
Most of those are in x86 code in xen/arch/x86/include/asm/msi.h .
I did send a patch [1] to deal with those, limited only to addressing the MISRA
violations, but in the end it was dropped in favour of a more general cleanup of
the file upon agreement, so this is why those changes are not included here.

[1] https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetrini@bugseng.com/

Changes in v2:
- refactor patch 4 to deviate the pattern, instead of fixing the violations
- The series has been resent because I forgot to properly Cc the mailing list

Nicola Vetrini (6):
  automation/eclair: address violations of MISRA C Rule 20.7
  xen/self-tests: address violations of MISRA rule 20.7
  xen/guest_access: address violations of MISRA rule 20.7
  automation/eclair_analysis: address violations of MISRA C Rule 20.7
  x86/irq: address violations of MISRA C Rule 20.7
  automation/eclair_analysis: clean ECLAIR configuration scripts

 automation/eclair_analysis/ECLAIR/analyze.sh     |  3 +--
 automation/eclair_analysis/ECLAIR/deviations.ecl | 14 ++++++++++++--
 docs/misra/deviations.rst                        |  3 ++-
 xen/include/xen/guest_access.h                   |  4 ++--
 xen/include/xen/irq.h                            |  2 +-
 xen/include/xen/self-tests.h                     |  8 ++++----
 6 files changed, 22 insertions(+), 12 deletions(-)

-- 
2.34.1

[XEN PATCH v2 1/6][RESEND] automation/eclair: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".

The helper macro bitmap_switch has parameters that cannot be parenthesized
in order to comply with the rule, as that would break its functionality.
Moreover, the risk of misuse due developer confusion is deemed not
substantial enough to warrant a more involved refactor, thus the macro
is deviated for this rule.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 447c1e6661d1..c2698e7074aa 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -463,6 +463,14 @@ of this macro do not lead to developer confusion, and can thus be deviated."
 -config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^count_args_$))))"}
 -doc_end
 
+-doc_begin="The arguments of macro bitmap_switch macro can't be parenthesized as
+the rule would require, without breaking the functionality of the macro. This is
+a specialized local helper macro only used within the bitmap.h header, so it is
+less likely to lead to developer confusion and it is deemed better to deviate it."
+-file_tag+={xen_bitmap_h, "^xen/include/xen/bitmap\\.h$"}
+-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(loc(file(xen_bitmap_h))&&^bitmap_switch$))))"}
+-doc_end
+
 -doc_begin="Uses of variadic macros that have one of their arguments defined as
 a macro and used within the body for both ordinary parameter expansion and as an
 operand to the # or ## operators have a behavior that is well-understood and
-- 
2.34.1

Re: [XEN PATCH v2 1/6][RESEND] automation/eclair: address violations of MISRA C Rule 20.7

[Stefano Stabellini]

On Mon, 16 Jun 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses".
> 
> The helper macro bitmap_switch has parameters that cannot be parenthesized
> in order to comply with the rule, as that would break its functionality.
> Moreover, the risk of misuse due developer confusion is deemed not
> substantial enough to warrant a more involved refactor, thus the macro
> is deviated for this rule.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

If possible, I would prefer we used a SAF in-code comment deviation. If
that doesn't work for any reason this patch is fine and I'd ack it.


> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 447c1e6661d1..c2698e7074aa 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -463,6 +463,14 @@ of this macro do not lead to developer confusion, and can thus be deviated."
>  -config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^count_args_$))))"}
>  -doc_end
>  
> +-doc_begin="The arguments of macro bitmap_switch macro can't be parenthesized as
> +the rule would require, without breaking the functionality of the macro. This is
> +a specialized local helper macro only used within the bitmap.h header, so it is
> +less likely to lead to developer confusion and it is deemed better to deviate it."
> +-file_tag+={xen_bitmap_h, "^xen/include/xen/bitmap\\.h$"}
> +-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(loc(file(xen_bitmap_h))&&^bitmap_switch$))))"}
> +-doc_end
> +
>  -doc_begin="Uses of variadic macros that have one of their arguments defined as
>  a macro and used within the body for both ordinary parameter expansion and as an
>  operand to the # or ## operators have a behavior that is well-understood and
> -- 
> 2.34.1
> 

Re: [XEN PATCH v2 1/6][RESEND] automation/eclair: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

On 2024-06-21 02:18, Stefano Stabellini wrote:
> On Mon, 16 Jun 2024, Nicola Vetrini wrote:
>> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
>> of macro parameters shall be enclosed in parentheses".
>> 
>> The helper macro bitmap_switch has parameters that cannot be 
>> parenthesized
>> in order to comply with the rule, as that would break its 
>> functionality.
>> Moreover, the risk of misuse due developer confusion is deemed not
>> substantial enough to warrant a more involved refactor, thus the macro
>> is deviated for this rule.
>> 
>> No functional change.
>> 
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> If possible, I would prefer we used a SAF in-code comment deviation. If
> that doesn't work for any reason this patch is fine and I'd ack it.
> 

Would that be an improvement for safety in your opinion?

> 
>> ---
>>  automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>> 
>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl 
>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> index 447c1e6661d1..c2698e7074aa 100644
>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>> @@ -463,6 +463,14 @@ of this macro do not lead to developer confusion, 
>> and can thus be deviated."
>>  -config=MC3R1.R20.7,reports+={safe, 
>> "any_area(any_loc(any_exp(macro(^count_args_$))))"}
>>  -doc_end
>> 
>> +-doc_begin="The arguments of macro bitmap_switch macro can't be 
>> parenthesized as
>> +the rule would require, without breaking the functionality of the 
>> macro. This is
>> +a specialized local helper macro only used within the bitmap.h 
>> header, so it is
>> +less likely to lead to developer confusion and it is deemed better to 
>> deviate it."
>> +-file_tag+={xen_bitmap_h, "^xen/include/xen/bitmap\\.h$"}
>> +-config=MC3R1.R20.7,reports+={safe, 
>> "any_area(any_loc(any_exp(macro(loc(file(xen_bitmap_h))&&^bitmap_switch$))))"}
>> +-doc_end
>> +
>>  -doc_begin="Uses of variadic macros that have one of their arguments 
>> defined as
>>  a macro and used within the body for both ordinary parameter 
>> expansion and as an
>>  operand to the # or ## operators have a behavior that is 
>> well-understood and
>> --
>> 2.34.1
>> 

-- 
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

Re: [XEN PATCH v2 1/6][RESEND] automation/eclair: address violations of MISRA C Rule 20.7

[Stefano Stabellini]

On Tue, 25 Jun 2024, Nicola Vetrini wrote:
> On 2024-06-21 02:18, Stefano Stabellini wrote:
> > On Mon, 16 Jun 2024, Nicola Vetrini wrote:
> > > MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> > > of macro parameters shall be enclosed in parentheses".
> > > 
> > > The helper macro bitmap_switch has parameters that cannot be parenthesized
> > > in order to comply with the rule, as that would break its functionality.
> > > Moreover, the risk of misuse due developer confusion is deemed not
> > > substantial enough to warrant a more involved refactor, thus the macro
> > > is deviated for this rule.
> > > 
> > > No functional change.
> > > 
> > > Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> > 
> > If possible, I would prefer we used a SAF in-code comment deviation. If
> > that doesn't work for any reason this patch is fine and I'd ack it.
> > 
> 
> Would that be an improvement for safety in your opinion?

Not for safety, as they both achieve the same result, but for
maintainability. The deviations under deviations.ecl are project-wide so
in my opinion should only be used for project-wide global deviations
from a rule. Specific deviations for functions should be done with SAF.
Another reason for this is that deviations under deviations.ecl need to
be manually ported to any other static analyzer one by one while SAF is
meant to support multiple automatically.

More importantly if we change deviations.ecl, deviations.rst should also
be changed the same way. I would say that this is required at a minimum
as deviations.ecl and deviations.rst should be in sync.

 
> > > ---
> > >  automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > index 447c1e6661d1..c2698e7074aa 100644
> > > --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> > > @@ -463,6 +463,14 @@ of this macro do not lead to developer confusion, and
> > > can thus be deviated."
> > >  -config=MC3R1.R20.7,reports+={safe,
> > > "any_area(any_loc(any_exp(macro(^count_args_$))))"}
> > >  -doc_end
> > > 
> > > +-doc_begin="The arguments of macro bitmap_switch macro can't be
> > > parenthesized as
> > > +the rule would require, without breaking the functionality of the macro.
> > > This is
> > > +a specialized local helper macro only used within the bitmap.h header, so
> > > it is
> > > +less likely to lead to developer confusion and it is deemed better to
> > > deviate it."
> > > +-file_tag+={xen_bitmap_h, "^xen/include/xen/bitmap\\.h$"}
> > > +-config=MC3R1.R20.7,reports+={safe,
> > > "any_area(any_loc(any_exp(macro(loc(file(xen_bitmap_h))&&^bitmap_switch$))))"}
> > > +-doc_end
> > > +
> > >  -doc_begin="Uses of variadic macros that have one of their arguments
> > > defined as
> > >  a macro and used within the body for both ordinary parameter expansion
> > > and as an
> > >  operand to the # or ## operators have a behavior that is well-understood
> > > and
> > > --
> > > 2.34.1
> > > 
> 
> -- 
> Nicola Vetrini, BSc
> Software Engineer, BUGSENG srl (https://bugseng.com)
> 

Re: [XEN PATCH v2 1/6][RESEND] automation/eclair: address violations of MISRA C Rule 20.7

[Stefano Stabellini]

On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses".
> 
> The helper macro bitmap_switch has parameters that cannot be parenthesized
> in order to comply with the rule, as that would break its functionality.
> Moreover, the risk of misuse due developer confusion is deemed not
> substantial enough to warrant a more involved refactor, thus the macro
> is deviated for this rule.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

I would have preferred a SAF tag instead but it can be done later

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index 447c1e6661d1..c2698e7074aa 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -463,6 +463,14 @@ of this macro do not lead to developer confusion, and can thus be deviated."
>  -config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(^count_args_$))))"}
>  -doc_end
>  
> +-doc_begin="The arguments of macro bitmap_switch macro can't be parenthesized as
> +the rule would require, without breaking the functionality of the macro. This is
> +a specialized local helper macro only used within the bitmap.h header, so it is
> +less likely to lead to developer confusion and it is deemed better to deviate it."
> +-file_tag+={xen_bitmap_h, "^xen/include/xen/bitmap\\.h$"}
> +-config=MC3R1.R20.7,reports+={safe, "any_area(any_loc(any_exp(macro(loc(file(xen_bitmap_h))&&^bitmap_switch$))))"}
> +-doc_end
> +
>  -doc_begin="Uses of variadic macros that have one of their arguments defined as
>  a macro and used within the body for both ordinary parameter expansion and as an
>  operand to the # or ## operators have a behavior that is well-understood and
> -- 
> 2.34.1
> 

[XEN PATCH v2 2/6][RESEND] xen/self-tests: address violations of MISRA rule 20.7

[Nicola Vetrini]

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: Jan Beulich <jbeulich@suse.com>
---
In this case the use of parentheses can detect misuses of the COMPILE_CHECK
macro for the fn argument that happen to pass the compile-time check
(see e.g. https://godbolt.org/z/n4zTdz595).

An alternative would be to deviate these macros, but since they are used
to check the correctness of other code it seemed the better alternative
to futher ensure that all usages of the macros are safe.
---
 xen/include/xen/self-tests.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/xen/include/xen/self-tests.h b/xen/include/xen/self-tests.h
index 42a4cc4d17fe..58484fe5a8ae 100644
--- a/xen/include/xen/self-tests.h
+++ b/xen/include/xen/self-tests.h
@@ -19,11 +19,11 @@
 #if !defined(CONFIG_CC_IS_CLANG) || CONFIG_CLANG_VERSION >= 80000
 #define COMPILE_CHECK(fn, val, res)                                     \
     do {                                                                \
-        typeof(fn(val)) real = fn(val);                                 \
+        typeof((fn)(val)) real = (fn)(val);                             \
                                                                         \
         if ( !__builtin_constant_p(real) )                              \
             asm ( ".error \"'" STR(fn(val)) "' not compile-time constant\"" ); \
-        else if ( real != res )                                         \
+        else if ( real != (res) )                                       \
             asm ( ".error \"Compile time check '" STR(fn(val) == res) "' failed\"" ); \
     } while ( 0 )
 #else
@@ -37,9 +37,9 @@
  */
 #define RUNTIME_CHECK(fn, val, res)                     \
     do {                                                \
-        typeof(fn(val)) real = fn(HIDE(val));           \
+        typeof((fn)(val)) real = (fn)(HIDE(val));       \
                                                         \
-        if ( real != res )                              \
+        if ( real != (res) )                            \
             panic("%s: %s(%s) expected %u, got %u\n",   \
                   __func__, #fn, #val, real, res);      \
     } while ( 0 )
-- 
2.34.1

[XEN PATCH v2 3/6][RESEND] xen/guest_access: address violations of MISRA rule 20.7

[Nicola Vetrini]

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>
---
 xen/include/xen/guest_access.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/xen/include/xen/guest_access.h b/xen/include/xen/guest_access.h
index af33ae3ab652..8bd2a124e823 100644
--- a/xen/include/xen/guest_access.h
+++ b/xen/include/xen/guest_access.h
@@ -49,9 +49,9 @@
     ((XEN_GUEST_HANDLE(type)) { &(hnd).p->fld })
 
 #define guest_handle_from_ptr(ptr, type)        \
-    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(type)) { (type *)(ptr) })
 #define const_guest_handle_from_ptr(ptr, type)  \
-    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)ptr })
+    ((XEN_GUEST_HANDLE_PARAM(const_##type)) { (const type *)(ptr) })
 
 /*
  * Copy an array of objects to guest context via a guest handle,
-- 
2.34.1

[XEN PATCH v2 4/6][RESEND] automation/eclair_analysis: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parentheses".

The local helpers GRP2 and XADD in the x86 emulator use their first
argument as the constant expression for a case label. This pattern
is deviated project-wide, because it is very unlikely to induce
developer confusion and result in the wrong control flow being
carried out.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
Changes in v2:
- Introduce a deviation instead of adding parentheses
---
 automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++--
 docs/misra/deviations.rst                        | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
index c2698e7074aa..fc248641dc78 100644
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -428,13 +428,15 @@ 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; (5) as initializers, possibly designated, in initalizer lists."
+in assignments; (5) as initializers, possibly designated, in initalizer lists;
+(6) as the constant expression in a switch clause label."
 -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, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(init_list_expr||designated_init_expr), init)))"}
+{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(init_list_expr||designated_init_expr), init)))"},
+{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(case_stmt), lower||upper)))"}
 -doc_end
 
 -doc_begin="Violations involving the __config_enabled macros cannot be fixed without
diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
index 36959aa44ac9..be2cc6bf03eb 100644
--- a/docs/misra/deviations.rst
+++ b/docs/misra/deviations.rst
@@ -376,7 +376,8 @@ Deviations related to MISRA C:2012 Rules:
        (2) as macro arguments;
        (3) as array indices;
        (4) as lhs in assignments;
-       (5) as initializers, possibly designated, in initalizer lists.
+       (5) as initializers, possibly designated, in initalizer lists;
+       (6) as constant expressions of switch case labels.
      - Tagged as `safe` for ECLAIR.
 
    * - R20.7
-- 
2.34.1

Re: [XEN PATCH v2 4/6][RESEND] automation/eclair_analysis: address violations of MISRA C Rule 20.7

[Stefano Stabellini]

On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses".
> 
> The local helpers GRP2 and XADD in the x86 emulator use their first
> argument as the constant expression for a case label. This pattern
> is deviated project-wide, because it is very unlikely to induce
> developer confusion and result in the wrong control flow being
> carried out.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

Re: [XEN PATCH v2 4/6][RESEND] automation/eclair_analysis: address violations of MISRA C Rule 20.7

[Stefano Stabellini]

On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> MISRA C Rule 20.7 states: "Expressions resulting from the expansion
> of macro parameters shall be enclosed in parentheses".
> 
> The local helpers GRP2 and XADD in the x86 emulator use their first
> argument as the constant expression for a case label. This pattern
> is deviated project-wide, because it is very unlikely to induce
> developer confusion and result in the wrong control flow being
> carried out.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
> Changes in v2:
> - Introduce a deviation instead of adding parentheses
> ---
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++++--
>  docs/misra/deviations.rst                        | 3 ++-
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl b/automation/eclair_analysis/ECLAIR/deviations.ecl
> index c2698e7074aa..fc248641dc78 100644
> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
> @@ -428,13 +428,15 @@ 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; (5) as initializers, possibly designated, in initalizer lists."
> +in assignments; (5) as initializers, possibly designated, in initalizer lists;
> +(6) as the constant expression in a switch clause label."
>  -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, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(init_list_expr||designated_init_expr), init)))"}
> +{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(init_list_expr||designated_init_expr), init)))"},
> +{safe, "context(skip_to(__expr_non_syntactic_contexts, stmt_child(node(case_stmt), lower||upper)))"}
>  -doc_end
>  
>  -doc_begin="Violations involving the __config_enabled macros cannot be fixed without
> diff --git a/docs/misra/deviations.rst b/docs/misra/deviations.rst
> index 36959aa44ac9..be2cc6bf03eb 100644
> --- a/docs/misra/deviations.rst
> +++ b/docs/misra/deviations.rst
> @@ -376,7 +376,8 @@ Deviations related to MISRA C:2012 Rules:
>         (2) as macro arguments;
>         (3) as array indices;
>         (4) as lhs in assignments;
> -       (5) as initializers, possibly designated, in initalizer lists.
> +       (5) as initializers, possibly designated, in initalizer lists;
> +       (6) as constant expressions of switch case labels.
>       - Tagged as `safe` for ECLAIR.
>  
>     * - R20.7
> -- 
> 2.34.1
> 

[XEN PATCH v2 5/6][RESEND] x86/irq: address violations of MISRA C Rule 20.7

[Nicola Vetrini]

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>
---
Note that the rule does not apply to f because that parameter
is not used as an expression in the macro, but rather as an identifier.
---
 xen/include/xen/irq.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/include/xen/irq.h b/xen/include/xen/irq.h
index adf33547d25f..0401f06c4fca 100644
--- a/xen/include/xen/irq.h
+++ b/xen/include/xen/irq.h
@@ -178,7 +178,7 @@ extern struct pirq *pirq_get_info(struct domain *d, int pirq);
 
 #define pirq_field(d, p, f, def) ({ \
     const struct pirq *__pi = pirq_info(d, p); \
-    __pi ? __pi->f : def; \
+    __pi ? __pi->f : (def); \
 })
 #define pirq_to_evtchn(d, pirq) pirq_field(d, pirq, evtchn, 0)
 #define pirq_masked(d, pirq) pirq_field(d, pirq, masked, 0)
-- 
2.34.1

[XEN PATCH v2 6/6][RESEND] automation/eclair_analysis: clean ECLAIR configuration scripts

[Nicola Vetrini]

Remove from the ECLAIR integration scripts an unused option, which
was already ignored, and make the help texts consistent
with the rest of the scripts.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/automation/eclair_analysis/ECLAIR/analyze.sh b/automation/eclair_analysis/ECLAIR/analyze.sh
index 0ea5520c93a6..e96456c3c18d 100755
--- a/automation/eclair_analysis/ECLAIR/analyze.sh
+++ b/automation/eclair_analysis/ECLAIR/analyze.sh
@@ -11,7 +11,7 @@ fatal() {
 }
 
 usage() {
-  fatal "Usage: ${script_name} <ARM64|X86_64> <Set0|Set1|Set2|Set3>"
+  fatal "Usage: ${script_name} <ARM64|X86_64> <accepted|monitored>"
 }
 
 if [[ $# -ne 2 ]]; then
@@ -40,7 +40,6 @@ ECLAIR_REPORT_LOG=${ECLAIR_OUTPUT_DIR}/REPORT.log
 if [[ "$1" = "X86_64" ]]; then
   export CROSS_COMPILE=
   export XEN_TARGET_ARCH=x86_64
-  EXTRA_ECLAIR_ENV_OPTIONS=-disable=MC3R1.R20.7
 elif [[ "$1" = "ARM64" ]]; then
   export CROSS_COMPILE=aarch64-linux-gnu-
   export XEN_TARGET_ARCH=arm64
-- 
2.34.1

Re: [XEN PATCH v2 6/6][RESEND] automation/eclair_analysis: clean ECLAIR configuration scripts

[Stefano Stabellini]

On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> Remove from the ECLAIR integration scripts an unused option, which
> was already ignored, and make the help texts consistent
> with the rest of the scripts.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Acked-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/analyze.sh b/automation/eclair_analysis/ECLAIR/analyze.sh
> index 0ea5520c93a6..e96456c3c18d 100755
> --- a/automation/eclair_analysis/ECLAIR/analyze.sh
> +++ b/automation/eclair_analysis/ECLAIR/analyze.sh
> @@ -11,7 +11,7 @@ fatal() {
>  }
>  
>  usage() {
> -  fatal "Usage: ${script_name} <ARM64|X86_64> <Set0|Set1|Set2|Set3>"
> +  fatal "Usage: ${script_name} <ARM64|X86_64> <accepted|monitored>"
>  }
>  
>  if [[ $# -ne 2 ]]; then
> @@ -40,7 +40,6 @@ ECLAIR_REPORT_LOG=${ECLAIR_OUTPUT_DIR}/REPORT.log
>  if [[ "$1" = "X86_64" ]]; then
>    export CROSS_COMPILE=
>    export XEN_TARGET_ARCH=x86_64
> -  EXTRA_ECLAIR_ENV_OPTIONS=-disable=MC3R1.R20.7
>  elif [[ "$1" = "ARM64" ]]; then
>    export CROSS_COMPILE=aarch64-linux-gnu-
>    export XEN_TARGET_ARCH=arm64
> -- 
> 2.34.1
> 

Re: [XEN PATCH v2 6/6][RESEND] automation/eclair_analysis: clean ECLAIR configuration scripts

[Stefano Stabellini]

On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> Remove from the ECLAIR integration scripts an unused option, which
> was already ignored, and make the help texts consistent
> with the rest of the scripts.
> 
> No functional change.
> 
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>


> ---
>  automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/automation/eclair_analysis/ECLAIR/analyze.sh b/automation/eclair_analysis/ECLAIR/analyze.sh
> index 0ea5520c93a6..e96456c3c18d 100755
> --- a/automation/eclair_analysis/ECLAIR/analyze.sh
> +++ b/automation/eclair_analysis/ECLAIR/analyze.sh
> @@ -11,7 +11,7 @@ fatal() {
>  }
>  
>  usage() {
> -  fatal "Usage: ${script_name} <ARM64|X86_64> <Set0|Set1|Set2|Set3>"
> +  fatal "Usage: ${script_name} <ARM64|X86_64> <accepted|monitored>"
>  }
>  
>  if [[ $# -ne 2 ]]; then
> @@ -40,7 +40,6 @@ ECLAIR_REPORT_LOG=${ECLAIR_OUTPUT_DIR}/REPORT.log
>  if [[ "$1" = "X86_64" ]]; then
>    export CROSS_COMPILE=
>    export XEN_TARGET_ARCH=x86_64
> -  EXTRA_ECLAIR_ENV_OPTIONS=-disable=MC3R1.R20.7
>  elif [[ "$1" = "ARM64" ]]; then
>    export CROSS_COMPILE=aarch64-linux-gnu-
>    export XEN_TARGET_ARCH=arm64
> -- 
> 2.34.1
> 

Re: [XEN PATCH v2 0/6][RESEND] address violations of MISRA C Rule 20.7

[Stefano Stabellini]

Hi Oleksii,

I would like to ask for a release-ack as the patch series makes very few
changes outside of the static analysis configuration. The few changes to
the Xen code are very limited, straightforward and makes the code
better, see patch #3 and #5.


On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> Hi all,
> 
> this series addresses several violations of Rule 20.7, as well as a
> small fix to the ECLAIR integration scripts that do not influence
> the current behaviour, but were mistakenly part of the upstream
> configuration.
> 
> Note that by applying this series the rule has a few leftover violations.
> Most of those are in x86 code in xen/arch/x86/include/asm/msi.h .
> I did send a patch [1] to deal with those, limited only to addressing the MISRA
> violations, but in the end it was dropped in favour of a more general cleanup of
> the file upon agreement, so this is why those changes are not included here.
> 
> [1] https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetrini@bugseng.com/
> 
> Changes in v2:
> - refactor patch 4 to deviate the pattern, instead of fixing the violations
> - The series has been resent because I forgot to properly Cc the mailing list
> 
> Nicola Vetrini (6):
>   automation/eclair: address violations of MISRA C Rule 20.7
>   xen/self-tests: address violations of MISRA rule 20.7
>   xen/guest_access: address violations of MISRA rule 20.7
>   automation/eclair_analysis: address violations of MISRA C Rule 20.7
>   x86/irq: address violations of MISRA C Rule 20.7
>   automation/eclair_analysis: clean ECLAIR configuration scripts
> 
>  automation/eclair_analysis/ECLAIR/analyze.sh     |  3 +--
>  automation/eclair_analysis/ECLAIR/deviations.ecl | 14 ++++++++++++--
>  docs/misra/deviations.rst                        |  3 ++-
>  xen/include/xen/guest_access.h                   |  4 ++--
>  xen/include/xen/irq.h                            |  2 +-
>  xen/include/xen/self-tests.h                     |  8 ++++----
>  6 files changed, 22 insertions(+), 12 deletions(-)
> 
> -- 
> 2.34.1
> 

Re: [XEN PATCH v2 0/6][RESEND] address violations of MISRA C Rule 20.7

[Jan Beulich]

On 25.06.2024 02:47, Stefano Stabellini wrote:
> I would like to ask for a release-ack as the patch series makes very few
> changes outside of the static analysis configuration. The few changes to
> the Xen code are very limited, straightforward and makes the code
> better, see patch #3 and #5.

While continuing to touch automation/ may be okay, I really think time has
passed for further Misra changes in 4.19, unless they're fixing actual bugs
of course. Just my personal view though ...

Jan

> On Mon, 17 Jun 2024, Nicola Vetrini wrote:
>> Hi all,
>>
>> this series addresses several violations of Rule 20.7, as well as a
>> small fix to the ECLAIR integration scripts that do not influence
>> the current behaviour, but were mistakenly part of the upstream
>> configuration.
>>
>> Note that by applying this series the rule has a few leftover violations.
>> Most of those are in x86 code in xen/arch/x86/include/asm/msi.h .
>> I did send a patch [1] to deal with those, limited only to addressing the MISRA
>> violations, but in the end it was dropped in favour of a more general cleanup of
>> the file upon agreement, so this is why those changes are not included here.
>>
>> [1] https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetrini@bugseng.com/
>>
>> Changes in v2:
>> - refactor patch 4 to deviate the pattern, instead of fixing the violations
>> - The series has been resent because I forgot to properly Cc the mailing list
>>
>> Nicola Vetrini (6):
>>   automation/eclair: address violations of MISRA C Rule 20.7
>>   xen/self-tests: address violations of MISRA rule 20.7
>>   xen/guest_access: address violations of MISRA rule 20.7
>>   automation/eclair_analysis: address violations of MISRA C Rule 20.7
>>   x86/irq: address violations of MISRA C Rule 20.7
>>   automation/eclair_analysis: clean ECLAIR configuration scripts
>>
>>  automation/eclair_analysis/ECLAIR/analyze.sh     |  3 +--
>>  automation/eclair_analysis/ECLAIR/deviations.ecl | 14 ++++++++++++--
>>  docs/misra/deviations.rst                        |  3 ++-
>>  xen/include/xen/guest_access.h                   |  4 ++--
>>  xen/include/xen/irq.h                            |  2 +-
>>  xen/include/xen/self-tests.h                     |  8 ++++----
>>  6 files changed, 22 insertions(+), 12 deletions(-)
>>
>> -- 
>> 2.34.1
>>

Re: [XEN PATCH v2 0/6][RESEND] address violations of MISRA C Rule 20.7

[oleksii.kurochko]

On Tue, 2024-06-25 at 08:39 +0200, Jan Beulich wrote:
> On 25.06.2024 02:47, Stefano Stabellini wrote:
> > I would like to ask for a release-ack as the patch series makes
> > very few
> > changes outside of the static analysis configuration. The few
> > changes to
> > the Xen code are very limited, straightforward and makes the code
> > better, see patch #3 and #5.
> 
> While continuing to touch automation/ may be okay, I really think
> time has
> passed for further Misra changes in 4.19, unless they're fixing
> actual bugs
> of course. Just my personal view though ...
I am not quite sure I understand the concern. From my perspective, the
patch series addresses several MISRA violations without introducing any
functional changes. It seems safe to incorporate these MISRA changes
even at this stage of the release.

~ Oleksii
> 
> Jan
> 
> > On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> > > Hi all,
> > > 
> > > this series addresses several violations of Rule 20.7, as well as
> > > a
> > > small fix to the ECLAIR integration scripts that do not influence
> > > the current behaviour, but were mistakenly part of the upstream
> > > configuration.
> > > 
> > > Note that by applying this series the rule has a few leftover
> > > violations.
> > > Most of those are in x86 code in xen/arch/x86/include/asm/msi.h .
> > > I did send a patch [1] to deal with those, limited only to
> > > addressing the MISRA
> > > violations, but in the end it was dropped in favour of a more
> > > general cleanup of
> > > the file upon agreement, so this is why those changes are not
> > > included here.
> > > 
> > > [1]
> > > https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetrini@bugseng.com/
> > > 
> > > Changes in v2:
> > > - refactor patch 4 to deviate the pattern, instead of fixing the
> > > violations
> > > - The series has been resent because I forgot to properly Cc the
> > > mailing list
> > > 
> > > Nicola Vetrini (6):
> > >   automation/eclair: address violations of MISRA C Rule 20.7
> > >   xen/self-tests: address violations of MISRA rule 20.7
> > >   xen/guest_access: address violations of MISRA rule 20.7
> > >   automation/eclair_analysis: address violations of MISRA C Rule
> > > 20.7
> > >   x86/irq: address violations of MISRA C Rule 20.7
> > >   automation/eclair_analysis: clean ECLAIR configuration scripts
> > > 
> > >  automation/eclair_analysis/ECLAIR/analyze.sh     |  3 +--
> > >  automation/eclair_analysis/ECLAIR/deviations.ecl | 14
> > > ++++++++++++--
> > >  docs/misra/deviations.rst                        |  3 ++-
> > >  xen/include/xen/guest_access.h                   |  4 ++--
> > >  xen/include/xen/irq.h                            |  2 +-
> > >  xen/include/xen/self-tests.h                     |  8 ++++----
> > >  6 files changed, 22 insertions(+), 12 deletions(-)
> > > 
> > > -- 
> > > 2.34.1
> > > 
> 

Re: [XEN PATCH v2 0/6][RESEND] address violations of MISRA C Rule 20.7

[Stefano Stabellini]

On Wed, 26 Jun 2024, oleksii.kurochko@gmail.com wrote:
> On Tue, 2024-06-25 at 08:39 +0200, Jan Beulich wrote:
> > On 25.06.2024 02:47, Stefano Stabellini wrote:
> > > I would like to ask for a release-ack as the patch series makes
> > > very few
> > > changes outside of the static analysis configuration. The few
> > > changes to
> > > the Xen code are very limited, straightforward and makes the code
> > > better, see patch #3 and #5.
> > 
> > While continuing to touch automation/ may be okay, I really think
> > time has
> > passed for further Misra changes in 4.19, unless they're fixing
> > actual bugs
> > of course. Just my personal view though ...
> I am not quite sure I understand the concern. From my perspective, the
> patch series addresses several MISRA violations without introducing any
> functional changes. It seems safe to incorporate these MISRA changes
> even at this stage of the release.

I agree with you but I guess Jan's point is that every change even small
could introduce a regression. This is your decision.

This is the updated version:
https://marc.info/?l=xen-devel&m=171940854121984

Re: [XEN PATCH v2 0/6][RESEND] address violations of MISRA C Rule 20.7

[Jan Beulich]

On 26.06.2024 19:42, oleksii.kurochko@gmail.com wrote:
> On Tue, 2024-06-25 at 08:39 +0200, Jan Beulich wrote:
>> On 25.06.2024 02:47, Stefano Stabellini wrote:
>>> I would like to ask for a release-ack as the patch series makes
>>> very few
>>> changes outside of the static analysis configuration. The few
>>> changes to
>>> the Xen code are very limited, straightforward and makes the code
>>> better, see patch #3 and #5.
>>
>> While continuing to touch automation/ may be okay, I really think
>> time has
>> passed for further Misra changes in 4.19, unless they're fixing
>> actual bugs
>> of course. Just my personal view though ...
> I am not quite sure I understand the concern. From my perspective, the
> patch series addresses several MISRA violations without introducing any
> functional changes. It seems safe to incorporate these MISRA changes
> even at this stage of the release.

It's your call in the end. Seeing we're not even at RC1 yet (which I had
long expected us to be past), perhaps I'm overly concerned.

Jan

Re: [XEN PATCH v2 0/6][RESEND] address violations of MISRA C Rule 20.7

[oleksii.kurochko]

On Mon, 2024-06-24 at 17:47 -0700, Stefano Stabellini wrote:
> Hi Oleksii,
> 
> I would like to ask for a release-ack as the patch series makes very
> few
> changes outside of the static analysis configuration. The few changes
> to
> the Xen code are very limited, straightforward and makes the code
> better, see patch #3 and #5.
Release-Acked-by: Oleksii Kurochko <oleksii.kurochko@gmail.com>

~ Oleksii
> 
> 
> On Mon, 17 Jun 2024, Nicola Vetrini wrote:
> > Hi all,
> > 
> > this series addresses several violations of Rule 20.7, as well as a
> > small fix to the ECLAIR integration scripts that do not influence
> > the current behaviour, but were mistakenly part of the upstream
> > configuration.
> > 
> > Note that by applying this series the rule has a few leftover
> > violations.
> > Most of those are in x86 code in xen/arch/x86/include/asm/msi.h .
> > I did send a patch [1] to deal with those, limited only to
> > addressing the MISRA
> > violations, but in the end it was dropped in favour of a more
> > general cleanup of
> > the file upon agreement, so this is why those changes are not
> > included here.
> > 
> > [1]
> > https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetrini@bugseng.com/
> > 
> > Changes in v2:
> > - refactor patch 4 to deviate the pattern, instead of fixing the
> > violations
> > - The series has been resent because I forgot to properly Cc the
> > mailing list
> > 
> > Nicola Vetrini (6):
> >   automation/eclair: address violations of MISRA C Rule 20.7
> >   xen/self-tests: address violations of MISRA rule 20.7
> >   xen/guest_access: address violations of MISRA rule 20.7
> >   automation/eclair_analysis: address violations of MISRA C Rule
> > 20.7
> >   x86/irq: address violations of MISRA C Rule 20.7
> >   automation/eclair_analysis: clean ECLAIR configuration scripts
> > 
> >  automation/eclair_analysis/ECLAIR/analyze.sh     |  3 +--
> >  automation/eclair_analysis/ECLAIR/deviations.ecl | 14
> > ++++++++++++--
> >  docs/misra/deviations.rst                        |  3 ++-
> >  xen/include/xen/guest_access.h                   |  4 ++--
> >  xen/include/xen/irq.h                            |  2 +-
> >  xen/include/xen/self-tests.h                     |  8 ++++----
> >  6 files changed, 22 insertions(+), 12 deletions(-)
> > 
> > -- 
> > 2.34.1
> >