| Message ID | 7e4ff67a24206177c5a304055f395cc2983bb994.1691053438.git.simone.ballarin@bugseng.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | xen: address violations of MISRA C:2012 Rule 7.3 | expand |
On Thu, 3 Aug 2023, Simone Ballarin wrote: > From: Gianluca Luparini <gianluca.luparini@bugseng.com> > > The xen sources contain violations of MISRA C:2012 Rule 7.3 whose headline > states: > "The lowercase character 'l' shall not be used in a literal suffix". > > Use the "L" suffix instead of the "l" suffix, to avoid potential ambiguity. > If the "u" suffix is used near "L", use the "U" suffix instead, for consistency. > > The changes in this patch are mechanical. > > Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com> > Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
On 04.08.2023 02:47, Stefano Stabellini wrote: > On Thu, 3 Aug 2023, Simone Ballarin wrote: >> From: Gianluca Luparini <gianluca.luparini@bugseng.com> >> >> The xen sources contain violations of MISRA C:2012 Rule 7.3 whose headline >> states: >> "The lowercase character 'l' shall not be used in a literal suffix". >> >> Use the "L" suffix instead of the "l" suffix, to avoid potential ambiguity. >> If the "u" suffix is used near "L", use the "U" suffix instead, for consistency. >> >> The changes in this patch are mechanical. >> >> Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com> >> Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com> > > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> I notice this again was committed with an ack by Tamas which has never appeared on list. At that time I pointed out that the reason may have been connected to the mail (as you had forwarded) having been a HTML one. Yet then looks like the same has happened to me, with "Re: Ping: [PATCH] mem-sharing: move (x86) / drop (Arm) arch_dump_shared_mem_info()". I can't find record of this in the list archive. And that mail, from all I can tell, was a plain text one. George, for the earlier instance Stefano had Cc-ed you, apparently on the assumption that you might be able to do something about this, or initiate that something be done. Is there anything that was found out? Just in case I'll attach the mail I did receive. I also wonder what other mails from you, Tamas, may not have appeared on list, and instead were (presumably) only delivered to people explicitly Cc-ed. Jan > > When !MEM_SHARING no useful output is produced. Move the function into > > mm/mem_sharing.c while conditionalizing the call to it, thus allowing to > > drop it altogether from Arm (and eliminating the need to introduce stubs > > on PPC and RISC-V). > > > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Tamas - any chance of an ack? Acked-by: Tamas K Lengyel <tamas@tklengyel.com>
Tamas, is it possible that you are not actually subscribed to xen-devel with your email tamas@tklengyel.com ? Sorry for top-posting I wanted to make sure Tamas saw this. On Thu, 24 Aug 2023, Jan Beulich wrote: > On 04.08.2023 02:47, Stefano Stabellini wrote: > > On Thu, 3 Aug 2023, Simone Ballarin wrote: > >> From: Gianluca Luparini <gianluca.luparini@bugseng.com> > >> > >> The xen sources contain violations of MISRA C:2012 Rule 7.3 whose headline > >> states: > >> "The lowercase character 'l' shall not be used in a literal suffix". > >> > >> Use the "L" suffix instead of the "l" suffix, to avoid potential ambiguity. > >> If the "u" suffix is used near "L", use the "U" suffix instead, for consistency. > >> > >> The changes in this patch are mechanical. > >> > >> Signed-off-by: Gianluca Luparini <gianluca.luparini@bugseng.com> > >> Signed-off-by: Simone Ballarin <simone.ballarin@bugseng.com> > > > > Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > > I notice this again was committed with an ack by Tamas which has never appeared > on list. At that time I pointed out that the reason may have been connected to > the mail (as you had forwarded) having been a HTML one. > > Yet then looks like the same has happened to me, with "Re: Ping: [PATCH] > mem-sharing: move (x86) / drop (Arm) arch_dump_shared_mem_info()". I can't find > record of this in the list archive. And that mail, from all I can tell, was a > plain text one. > > George, for the earlier instance Stefano had Cc-ed you, apparently on the > assumption that you might be able to do something about this, or initiate that > something be done. Is there anything that was found out? Just in case I'll > attach the mail I did receive. > > I also wonder what other mails from you, Tamas, may not have appeared on list, > and instead were (presumably) only delivered to people explicitly Cc-ed.
diff --git a/xen/common/mem_access.c b/xen/common/mem_access.c index 010e6f8dbf..385950789c 100644 --- a/xen/common/mem_access.c +++ b/xen/common/mem_access.c @@ -60,7 +60,7 @@ int mem_access_memop(unsigned long cmd, case XENMEM_access_op_set_access: rc = -EINVAL; - if ( (mao.pfn != ~0ull) && + if ( (mao.pfn != ~0ULL) && (mao.nr < start_iter || ((mao.pfn + mao.nr - 1) < mao.pfn) || ((mao.pfn + mao.nr - 1) > domain_get_maximum_gpfn(d))) ) @@ -96,7 +96,7 @@ int mem_access_memop(unsigned long cmd, break; rc = -EINVAL; - if ( (mao.pfn > domain_get_maximum_gpfn(d)) && mao.pfn != ~0ull ) + if ( (mao.pfn > domain_get_maximum_gpfn(d)) && mao.pfn != ~0ULL ) break; rc = p2m_get_mem_access(d, _gfn(mao.pfn), &access, 0);