[v2] x86/mctelem: address violations of MISRA C: 2012 Rule 5.3

[XEN PATCH v2] x86/mctelem: address violations of MISRA C: 2012 Rule 5.3

Posted by Nicola Vetrini 2 months, 1 week ago

From: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>

This addresses violations of MISRA C:2012 Rule 5.3 which states as
following: An identifier declared in an inner scope shall not hide an
identifier declared in an outer scope.

In this case the gloabl variable being shadowed is the global static struct
mctctl in this file, therefore the local variables are renamed to avoid this.

No functional change.

Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
---
Changes in v2:
- s/mctctl_cpu/ctl/ and amended file comment and commit message
---
 xen/arch/x86/cpu/mcheck/mctelem.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/xen/arch/x86/cpu/mcheck/mctelem.c b/xen/arch/x86/cpu/mcheck/mctelem.c
index b8d0368a7d37..123e4102adca 100644
--- a/xen/arch/x86/cpu/mcheck/mctelem.c
+++ b/xen/arch/x86/cpu/mcheck/mctelem.c
@@ -168,28 +168,28 @@ static void mctelem_xchg_head(struct mctelem_ent **headp,
 void mctelem_defer(mctelem_cookie_t cookie, bool lmce)
 {
 	struct mctelem_ent *tep = COOKIE2MCTE(cookie);
-	struct mc_telem_cpu_ctl *mctctl = &this_cpu(mctctl);
+	struct mc_telem_cpu_ctl *ctl = &this_cpu(mctctl);
 
-	ASSERT(mctctl->pending == NULL || mctctl->lmce_pending == NULL);
+	ASSERT(ctl->pending == NULL || ctl->lmce_pending == NULL);
 
-	if (mctctl->pending)
-		mctelem_xchg_head(&mctctl->pending, &tep->mcte_next, tep);
+	if (ctl->pending)
+		mctelem_xchg_head(&ctl->pending, &tep->mcte_next, tep);
 	else if (lmce)
-		mctelem_xchg_head(&mctctl->lmce_pending, &tep->mcte_next, tep);
+		mctelem_xchg_head(&ctl->lmce_pending, &tep->mcte_next, tep);
 	else {
 		/*
 		 * LMCE is supported on Skylake-server and later CPUs, on
 		 * which mce_broadcast is always true. Therefore, non-empty
-		 * mctctl->lmce_pending in this branch implies a broadcasting
+		 * ctl->lmce_pending in this branch implies a broadcasting
 		 * MC# is being handled, every CPU is in the exception
-		 * context, and no one is consuming mctctl->pending at this
+		 * context, and no one is consuming ctl->pending at this
 		 * moment. As a result, the following two exchanges together
 		 * can be treated as atomic.
 		 */
-		if (mctctl->lmce_pending)
-			mctelem_xchg_head(&mctctl->lmce_pending,
-					  &mctctl->pending, NULL);
-		mctelem_xchg_head(&mctctl->pending, &tep->mcte_next, tep);
+		if (ctl->lmce_pending)
+			mctelem_xchg_head(&ctl->lmce_pending,
+					  &ctl->pending, NULL);
+		mctelem_xchg_head(&ctl->pending, &tep->mcte_next, tep);
 	}
 }
 
@@ -213,7 +213,7 @@ void mctelem_process_deferred(unsigned int cpu,
 {
 	struct mctelem_ent *tep;
 	struct mctelem_ent *head, *prev;
-	struct mc_telem_cpu_ctl *mctctl = &per_cpu(mctctl, cpu);
+	struct mc_telem_cpu_ctl *ctl = &per_cpu(mctctl, cpu);
 	int ret;
 
 	/*
@@ -232,7 +232,7 @@ void mctelem_process_deferred(unsigned int cpu,
 	 * Any MC# occurring after the following atomic exchange will be
 	 * handled by another round of MCE softirq.
 	 */
-	mctelem_xchg_head(lmce ? &mctctl->lmce_pending : &mctctl->pending,
+	mctelem_xchg_head(lmce ? &ctl->lmce_pending : &ctl->pending,
 			  &this_cpu(mctctl.processing), NULL);
 
 	head = this_cpu(mctctl.processing);
-- 
2.34.1

Re: [XEN PATCH v2] x86/mctelem: address violations of MISRA C: 2012 Rule 5.3

Posted by Stefano Stabellini 2 months, 1 week ago

On Wed, 26 Jun 2024, Nicola Vetrini wrote:
> From: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
> 
> This addresses violations of MISRA C:2012 Rule 5.3 which states as
> following: An identifier declared in an inner scope shall not hide an
> identifier declared in an outer scope.
> 
> In this case the gloabl variable being shadowed is the global static struct
> mctctl in this file, therefore the local variables are renamed to avoid this.
> 
> No functional change.
> 
> Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>

Nice one!

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

Re: [XEN PATCH v2] x86/mctelem: address violations of MISRA C: 2012 Rule 5.3

Posted by Jan Beulich 2 months, 1 week ago

On 27.06.2024 02:57, Stefano Stabellini wrote:
> On Wed, 26 Jun 2024, Nicola Vetrini wrote:
>> From: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
>>
>> This addresses violations of MISRA C:2012 Rule 5.3 which states as
>> following: An identifier declared in an inner scope shall not hide an
>> identifier declared in an outer scope.
>>
>> In this case the gloabl variable being shadowed is the global static struct
>> mctctl in this file, therefore the local variables are renamed to avoid this.

"global" and "static" contradict one another; I think you mean "file scope".
While there (nit) also s/gloabl/global/ or perhaps even s/gloabl// to deal
with the conflict with "static" also there (without writing "file scope"
twice).

>> No functional change.
>>
>> Signed-off-by: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
> 
> Nice one!
> 
> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>

With the adjustment:
Acked-by: Jan Beulich <jbeulich@suse.com>

Jan

Re: [XEN PATCH v2] x86/mctelem: address violations of MISRA C: 2012 Rule 5.3

Posted by Nicola Vetrini 2 months, 1 week ago

On 2024-07-01 10:27, Jan Beulich wrote:
> On 27.06.2024 02:57, Stefano Stabellini wrote:
>> On Wed, 26 Jun 2024, Nicola Vetrini wrote:
>>> From: Alessandro Zucchelli <alessandro.zucchelli@bugseng.com>
>>> 
>>> This addresses violations of MISRA C:2012 Rule 5.3 which states as
>>> following: An identifier declared in an inner scope shall not hide an
>>> identifier declared in an outer scope.
>>> 
>>> In this case the gloabl variable being shadowed is the global static 
>>> struct
>>> mctctl in this file, therefore the local variables are renamed to 
>>> avoid this.
> 
> "global" and "static" contradict one another; I think you mean "file 
> scope".

Yes.

> While there (nit) also s/gloabl/global/ or perhaps even s/gloabl// to 
> deal
> with the conflict with "static" also there (without writing "file 
> scope"
> twice).
> 
>>> No functional change.
>>> 
>>> Signed-off-by: Alessandro Zucchelli 
>>> <alessandro.zucchelli@bugseng.com>
>>> Signed-off-by: Nicola Vetrini <nicola.vetrini@bugseng.com>
>> 
>> Nice one!
>> 
>> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
> 
> With the adjustment:
> Acked-by: Jan Beulich <jbeulich@suse.com>
> 
> Jan

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