All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@epam.com>
To: Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <stefano.stabellini@amd.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	"Doug Goldstein" <cardoe@cardoe.com>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Anthony PERARD" <anthony.perard@vates.tech>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Julien Grall" <julien@xen.org>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	"Nicola Vetrini" <nicola.vetrini@bugseng.com>
Subject: Re: [XEN PATCH v2 3/3] eclair: add deviations of MISRA C Rule 5.5
Date: Tue, 15 Jul 2025 09:46:35 +0000	[thread overview]
Message-ID: <d8e714ad-e1a9-4d9d-9a2b-8eb796f21e04@epam.com> (raw)
In-Reply-To: <bd89ecfe-83b3-471b-8455-83b9974bdaf2@suse.com>

Hi Jan and Stefano.

Could we proceed with ARM deviations only so far?
I understand Stefano's preferences, but it can unblock me to address 
next ARM violations.

BR, Dmytro.

On 7/14/25 10:55, Jan Beulich wrote:
> On 12.07.2025 03:13, Stefano Stabellini wrote:
>> On Fri, 11 Jul 2025, Nicola Vetrini wrote:
>>> On 2025-07-09 23:38, Dmytro Prokopchuk1 wrote:
>>>> MISRA C Rule 5.5 states that: "Identifiers shall
>>>> be distinct from macro names".
>>>>
>>>> Update ECLAIR configuration to deviate:
>>>> - clashes in 'xen/include/xen/bitops.h';
>>>> - clashes in 'xen/include/xen/irq.h';
>>>> - clashes in 'xen/common/grant_table.c'.
>>>>
>>>> Signed-off-by: Dmytro Prokopchuk <dmytro_prokopchuk1@epam.com>
>>>> ---
>>>>   automation/eclair_analysis/ECLAIR/deviations.ecl | 8 ++++++++
>>>>   docs/misra/deviations.rst                        | 8 ++++++++
>>>>   2 files changed, 16 insertions(+)
>>>>
>>>> diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> index e8f513fbc5..a5d7b00094 100644
>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> @@ -117,6 +117,14 @@ it defines would (in the common case) be already
>>>> defined. Peer reviewed by the c
>>>>   -config=MC3A2.R5.5,reports+={deliberate,
>>>> "any_area(decl(kind(function))||any_loc(macro(name(memcpy||memset||memmove))))&&any_area(any_loc(file(^xen/common/libelf/libelf-private\\.h$)))"}
>>>>   -doc_end
>>>>
>>>> +-doc_begin="Clashes between function names and macros are deliberate for
>>>> bitops functions, pirq_cleanup_check, update_gnttab_par and
>>>> parse_gnttab_limit functions
>>>> +and needed to have a function-like macro that acts as a wrapper for the
>>>> function to be called. Before calling the function,
>>>> +the macro adds additional checks or adjusts the number of parameters
>>>> depending on the configuration."
>>>> +-config=MC3A2.R5.5,reports+={deliberate,
>>>> "any_area(all_loc(file(^xen/include/xen/bitops\\.h$)))"}
>>>
>>> Bitops violations are not inside "xen/include/xen/bitops.h", but rather
>>> "xen/arch/x86/include/asm/bitops.h"
>>>
>>>> +-config=MC3A2.R5.5,reports+={deliberate,
>>>> "any_area(all_loc(file(^xen/include/xen/irq\\.h$))&&context(name(pirq_cleanup_check)&&kind(function)))"}
>>>
>>> I would rather do (untested)
>>>
>>> -config=MC3A2.R5.5,reports+={deliberate,
>>> "all_area(decl(name(pirq_cleanup_check))||macro(name(pirq_cleanup_check)))"}
>>>
>>>> +-config=MC3A2.R5.5,reports+={deliberate,
>>>> "any_area(all_loc(file(^xen/common/grant_table\\.c$))&&context(name(update_gnttab_par||parse_gnttab_limit)&&kind(function)))"}
>>>> +-doc_end
>>>> +
>>>
>>> same as above
>>>
>>
>> Thanks Nicola! The following deviations are enough and sufficient to
>> zero violations on both ARM and x86:
>>
>> -config=MC3A2.R5.5,reports+={deliberate, "any_area(all_loc(file(^xen/include/xen/bitops\\.h$)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "any_area(all_loc(file(^xen/arch/x86/include/asm/bitops\\.h$)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "any_area(all_loc(file(^.*/compat\\.c$)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "any_area(all_loc(file(^.*/compat/.*$)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "any_area(all_loc(file(^xen/arch/x86/x86_emulate/.*$)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "any_area(all_loc(file(^xen/arch/x86/include/asm/genapic\\.h$)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(parse_gnttab_limit))||macro(name(parse_gnttab_limit)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(update_gnttab_par))||macro(name(update_gnttab_par)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(pirq_cleanup_check))||macro(name(pirq_cleanup_check)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(virt_to_maddr))||macro(name(virt_to_maddr)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(set_px_pminfo))||macro(name(set_px_pminfo)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(set_cx_pminfo))||macro(name(set_cx_pminfo)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(cpu_has_amd_erratum))||macro(name(cpu_has_amd_erratum)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(copy_to_guest_ll))||macro(name(copy_to_guest_ll)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(copy_from_guest_ll))||macro(name(copy_from_guest_ll)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(edd_put_string))||macro(name(edd_put_string)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(cpu_has_amd_erratum))||macro(name(cpu_has_amd_erratum)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(page_list_entry))||macro(name(page_list_entry)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(do_physdev_op))||macro(name(do_physdev_op)))"}
>> -config=MC3A2.R5.5,reports+={deliberate, "all_area(decl(name(do_platform_op))||macro(name(do_platform_op)))"}
>>
>> Jan, are you OK with it?
> 
> For many of them the scope (all_area) looks to be far too wide, especially
> for about everything involved in compat handling. I can only repeat that I
> think that we would be (far) better off not having wider than necessary
> deviations.
> 
> There are others which I may not understand, e.g. the genapic.h one. IOW I
> further think that such a change would need to come with a fair bit of
> explanation / justification.
> 
> Jan

  reply	other threads:[~2025-07-15  9:47 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-09 21:38 [XEN PATCH v2 0/3] address violation of MISRA C Rule 5.5 Dmytro Prokopchuk1
2025-07-09 21:38 ` [XEN PATCH v2 1/3] iommu: " Dmytro Prokopchuk1
2025-07-10  8:21   ` Jan Beulich
2025-07-10  9:44     ` Dmytro Prokopchuk1
2025-07-10  9:47       ` Dmytro Prokopchuk1
2025-07-09 21:38 ` [XEN PATCH v2 2/3] device-tree: " Dmytro Prokopchuk1
2025-07-09 21:38 ` [XEN PATCH v2 3/3] eclair: add deviations " Dmytro Prokopchuk1
2025-07-11  2:17   ` Stefano Stabellini
2025-07-11  8:28   ` Nicola Vetrini
2025-07-12  1:13     ` Stefano Stabellini
2025-07-12  7:45       ` Nicola Vetrini
2025-07-14  7:55       ` Jan Beulich
2025-07-15  9:46         ` Dmytro Prokopchuk1 [this message]
2025-07-15 10:01           ` Jan Beulich
2025-07-15 10:07             ` Dmytro Prokopchuk1
2025-07-15 10:39               ` Jan Beulich
2025-07-15 10:45                 ` Dmytro Prokopchuk1
2025-07-15 10:50               ` Jan Beulich
2025-07-16 16:04                 ` Dmytro Prokopchuk1
2025-07-16 16:20                   ` Jan Beulich
2025-07-16 16:52                   ` Nicola Vetrini
2025-07-16 18:03                     ` Dmytro Prokopchuk1
2025-07-09 21:55 ` [XEN PATCH v2 0/3] address violation " Dmytro Prokopchuk1

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d8e714ad-e1a9-4d9d-9a2b-8eb796f21e04@epam.com \
    --to=dmytro_prokopchuk1@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@vates.tech \
    --cc=cardoe@cardoe.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=nicola.vetrini@bugseng.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=stefano.stabellini@amd.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.