MISRA C Rule 20.12 states: "A macro parameter used as an operand to
the # or ## operators, which is itself subject to further macro replacement,
shall only be used as an operand to these operators".

In this case, builds where CONFIG_DEBUG_LOCK_PROFILE=y the domain_lock
macro is used both as a regular macro argument and as an operand for
stringification in the expansion of macro spin_lock_init_prof.
A SAF-x-safe deviation is introduced to justify this.

No functional change.

Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
 docs/misra/safe.json | 8 ++++++++
 xen/common/domain.c  | 1 +
 2 files changed, 9 insertions(+)

diff --git a/docs/misra/safe.json b/docs/misra/safe.json
index 9b13bcf71706..c213e0a0be3b 100644
--- a/docs/misra/safe.json
+++ b/docs/misra/safe.json
@@ -52,6 +52,14 @@
         },
         {
             "id": "SAF-6-safe",
+            "analyser": {
+                "eclair": "MC3R1.R20.12"
+            },
+            "name": "MC3R1.R20.12: use of a macro argument that deliberately violates the Rule",
+            "text": "A macro parameter that is itself a macro is intentionally used within the macro both as a regular parameter and for text replacement."
+        },
+        {
+            "id": "SAF-7-safe",
             "analyser": {},
             "name": "Sentinel",
             "text": "Next ID to be used"
diff --git a/xen/common/domain.c b/xen/common/domain.c
index 67cadb7c3f4f..2c7168093734 100644
--- a/xen/common/domain.c
+++ b/xen/common/domain.c
@@ -632,6 +632,7 @@ struct domain *domain_create(domid_t domid,
 
     atomic_set(&d->refcnt, 1);
     RCU_READ_LOCK_INIT(&d->rcu_lock);
+    /* SAF-6-safe Rule 20.12 expansion of macro domain_lock in debug builds */
     rspin_lock_init_prof(d, domain_lock);
     rspin_lock_init_prof(d, page_alloc_lock);
     spin_lock_init(&d->hypercall_deadlock_mutex);
-- 
2.34.1

On 01.06.2024 12:16, Nicola Vetrini wrote:
> MISRA C Rule 20.12 states: "A macro parameter used as an operand to
> the # or ## operators, which is itself subject to further macro replacement,
> shall only be used as an operand to these operators".
> 
> In this case, builds where CONFIG_DEBUG_LOCK_PROFILE=y the domain_lock
> macro is used both as a regular macro argument and as an operand for
> stringification in the expansion of macro spin_lock_init_prof.

The shouldn't the marker be on the definition of spin_lock_init_prof(),
rather than ...

> --- a/xen/common/domain.c
> +++ b/xen/common/domain.c
> @@ -632,6 +632,7 @@ struct domain *domain_create(domid_t domid,
>  
>      atomic_set(&d->refcnt, 1);
>      RCU_READ_LOCK_INIT(&d->rcu_lock);
> +    /* SAF-6-safe Rule 20.12 expansion of macro domain_lock in debug builds */
>      rspin_lock_init_prof(d, domain_lock);
>      rspin_lock_init_prof(d, page_alloc_lock);
>      spin_lock_init(&d->hypercall_deadlock_mutex);

... actually just one of the two uses here (and presumably several more
elsewhere)?

Jan

On 2024-06-03 08:39, Jan Beulich wrote:
> On 01.06.2024 12:16, Nicola Vetrini wrote:
>> MISRA C Rule 20.12 states: "A macro parameter used as an operand to
>> the # or ## operators, which is itself subject to further macro 
>> replacement,
>> shall only be used as an operand to these operators".
>> 
>> In this case, builds where CONFIG_DEBUG_LOCK_PROFILE=y the domain_lock
>> macro is used both as a regular macro argument and as an operand for
>> stringification in the expansion of macro spin_lock_init_prof.
> 
> The shouldn't the marker be on the definition of spin_lock_init_prof(),
> rather than ...
> 
>> --- a/xen/common/domain.c
>> +++ b/xen/common/domain.c
>> @@ -632,6 +632,7 @@ struct domain *domain_create(domid_t domid,
>> 
>>      atomic_set(&d->refcnt, 1);
>>      RCU_READ_LOCK_INIT(&d->rcu_lock);
>> +    /* SAF-6-safe Rule 20.12 expansion of macro domain_lock in debug 
>> builds */
>>      rspin_lock_init_prof(d, domain_lock);
>>      rspin_lock_init_prof(d, page_alloc_lock);
>>      spin_lock_init(&d->hypercall_deadlock_mutex);
> 
> ... actually just one of the two uses here (and presumably several more
> elsewhere)?
> 
> Jan

Actually it seems that this violation went away with some refactorings, 
so this patch is no longer needed other than for the addition to 
safe.json, so it can be folded into the next one.
I'll make the adjustment.

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