should be an ASSERT()?
That might be an option, yet with the general movement towards also
providing safety on release builds that would likely end up being
if ( dir != IOREQ_WRITE )
{
ASSERT_UNREACHABLE():
return 0;
}
i.e. still an extra check.
Jan
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
violations, getting us one step closer to
marking Rules 5.2 and 5.4 as clean.
The ECLAIR configuration is already using 63, so this change matches
the rules.rst documentation with the ECLAIR behavior.
Signed-off-by: Stefano Stabellini
Reviewed-by: Nicola Vetrini
---
Changes in v2:
- use 63 instead of
ased on an older tree). A last resort may be to special-case those
declarations, but that's undesirable.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)commit caffa89a06275b6b50ace99170b99b500b7b32f7
Author: Nicola Vetrini
Date: Wed Nov 29 12:23:25 2023 +0100
r. It is also possibile to do it the other
way around (align the rst with the ECLAIR configuration), which spares
the need for additional deviations.
In that case, I agree that 63 is better than 64.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
he GNU extension, and where
hence __VA_ARGS__ would - by extrapolation of the Misra rule - need
parenthesizing, when it isn't and can't be.
Isn't it rather the case that variable argument macros need a more
general
deviation, if not an adjustment to the Misra rule? Extending the Cc
list
some ...
Jan
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-06-26 10:20, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
$(objtree
On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen/arch/x86/Makefile
@@ -258,18 +258,20 @@ $(obj)/asm-macros.i: CFLAGS-y += -P
$(objtree
On 2024-06-26 11:26, Jan Beulich wrote:
On 26.06.2024 11:20, Nicola Vetrini wrote:
On 2024-06-26 11:06, Jan Beulich wrote:
On 25.06.2024 21:31, Nicola Vetrini wrote:
On 2024-03-12 09:16, Jan Beulich wrote:
On 11.03.2024 09:59, Simone Ballarin wrote:
--- a/xen/arch/x86/Makefile
+++ b/xen
file, therefore the local variables are renamed to avoid this.
No functional change.
Signed-off-by: Alessandro Zucchelli
Signed-off-by: Nicola Vetrini
---
Changes in v2:
- s/mctctl_cpu/ctl/ and amended file comment and commit message
---
xen/arch/x86/cpu/mcheck/mctelem.c | 26
he 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
---
Changes in v2:
- Switched to a comment-based deviation to allow other tools to
pick this de
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
Reviewed-by: Stefano Stabellini
---
automation/eclair_analysis/ECLAIR/analyze.sh | 3
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
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/gues
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
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
ause 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
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- Introduce a deviation instead of adding parentheses
---
automation/eclair_analy
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Jan Beulich
---
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
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/traps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 9906e874d593..ee91fc56b125 100644
---
here.
[1]
https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetr...@bugseng.com/
Changes in v2:
- Patch 7 is new to this series
Nicola Vetrini (7):
automation/eclair: address violations of MISRA C Rule 20.7
xen/self-tests: address violations of
On 2024-06-26 15:28, 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
On 2024-06-26 15:38, Anthony PERARD wrote:
On Wed, Jun 26, 2024 at 12:31:42PM +0200, Jan Beulich wrote:
On 26.06.2024 12:25, Nicola Vetrini wrote:
> On 2024-06-26 11:26, Jan Beulich wrote:
>> On 26.06.2024 11:20, Nicola Vetrini wrote:
>>> On 2024-06-26 11:06, Jan Beul
s a defensive coding measure to have a safe fallback that is
reachable in non-debug builds, and can thus be deviated with a
comment-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
---
docs/misra/safe.json | 8
xen/arch/x86/mm/p2m-pod.c | 1 +
2 files changed, 9
/-/commit/402e473249cf62dd4c6b3b137aa845db0fe1453a
)
Commit Message: x86/traps: address violations of MISRA C Rule 2...
Commit Author: Nicola Vetrini
Committed by: Jan Beulich ( https://gitlab.com/jbeulich )
Pipeline #1350627221 (
https://gitlab.com/xen-project/xen/-/pipelines/1350627221
s a defensive coding measure to have a safe fallback that is
reachable in non-debug builds, and can thus be deviated with a
comment-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Stefano Stabellini
---
Changes in v2:
- rebased against current staging
---
docs/misr
On 2024-06-28 01:18, Stefano Stabellini wrote:
On Thu, 27 Jun 2024, Nicola Vetrini wrote:
The label 'out_unmap' is only reachable after ASSERT_UNREACHABLE,
so the code below is only executed upon erroneously reaching that
program point and calling domain_crash, thus resulting in th
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
This addresses violations of MISRA C:2012 Rule 5.3 which states as
following: An identifier declared in an inner scope shall not hide
ned-off-by: Nicola Vetrini
---
An alternative approach would be to use an ecl configuration, but that
would be tool-specific.
As this is purely an improvement to the CI, I'd like to ask for a release ack.
---
xen/include/xen/bitmap.h | 15 ---
1 file changed, 12 insertions(+), 3 del
On 2024-07-09 11:40, Jan Beulich wrote:
On 09.07.2024 11:34, Nicola Vetrini wrote:
As noticed in the gitlab analyses, deviating bitmap_switch
for Rule 20.7 in this way does not work for ECLAIR.
Instead, the deviation should be put in the macro invocation.
Why is this? I ask in particular
+_edevice
+_asdevice
+_aedevice
+_steemediator
+_eteemediator
+__init_begin
+_sinittext
+_einittext
+__setup_start
+__setup_end
+__initcall_start
+__presmp_initcall_end
+__initcall_end
+__alt_instructions
+__alt_instructions_end
+__ctors_start
+__ctors_end
+__init_end_efi
+__init_end
+__bss_start
+__per_cpu_start
+__per_cpu_data_end
+__bss_end
+_end
--
2.37.6
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
will carry out that's not a particular concern,
as each symbol will be used to construct a single regex, but for
readability that might be appreciated by the maintainers.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
ild
(and hence the analysis), but the configuration must be generated before
the analysis, the only way this could work in my opinion is this:
- a build without analysis is performed, just enough to build xen.lds
(maybe there is a specific Makefile target to do this)
- generate the configuration,
On 2024-07-26 00:43, Stefano Stabellini wrote:
On Thu, 25 Jul 2024, Nicola Vetrini wrote:
On 2024-07-25 21:01, victorm.l...@amd.com wrote:
> From: Victor Lira
>
> Requested-by: Jan Beulich
> Signed-off-by: Victor Lira
> ---
> Notes:
> This is a utilty script for help w
On 2024-07-30 11:45, Jan Beulich wrote:
On 23.07.2024 10:15, Alessandro Zucchelli wrote:
From: Nicola Vetrini
Add safe deviation for *.c files, as estabilished in past discussion.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
Signed-off-by: Nicola Vetrini
Signed
lowing the presence
of cautions (currently there are no violations).
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/monitored.ecl | 1 +
automation/eclair_analysis/ECLAIR/tagging.ecl | 1 +
2 files changed, 2 insertions(+)
diff --git a/automation/eclai
{GITLAB_USER_LOGIN}"
+event=push
+ref_kind=branch
+ref="${CI_MERGE_REQUEST_SOURCE_BRANCH_NAME}"
headCommitId="${CI_COMMIT_SHA}"
-baseCommitId="${CI_MERGE_REQUEST_DIFF_BASE_SHA}"
+pushUser="${GITLAB_USER_NAME}"
+#endif
+bool static_heap;
+};
+
+#ifdef CONFIG_ACPI
+#define BOOTINFO_ACPI_INIT .acpi.common.max_banks = NR_MEM_BANKS,
+#else
+#define BOOTINFO_ACPI_INIT
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+#define BOOTINFO_SHMEM_INIT .shmem.common.max_banks = NR_SHMEM_BANKS,
+#else
+#define BOOTINFO_SHMEM_INIT
+#endif
+
+#define BOOTINFO_INIT \
+{ \
+.mem.common.max_banks = NR_MEM_BANKS, \
+.reserved_mem.common.max_banks = NR_MEM_BANKS, \
+BOOTINFO_ACPI_INIT \
+BOOTINFO_SHMEM_INIT \
+}
+
+extern struct bootinfo bootinfo;
+
+void populate_boot_allocator(void);
+
+size_t boot_fdt_info(const void *fdt, paddr_t paddr);
+
+const char *boot_fdt_cmdline(const void *fdt);
+
+static inline struct membanks *bootinfo_get_reserved_mem(void)
+{
+return container_of(&bootinfo.reserved_mem.common, struct
membanks, common);
+}
+
+static inline struct membanks *bootinfo_get_mem(void)
+{
+return container_of(&bootinfo.mem.common, struct membanks,
common);
+}
+
+#ifdef CONFIG_ACPI
+static inline struct membanks *bootinfo_get_acpi(void)
+{
+return container_of(&bootinfo.acpi.common, struct membanks,
common);
+}
+#endif
+
+#ifdef CONFIG_STATIC_SHM
+static inline struct membanks *bootinfo_get_shmem(void)
+{
+return container_of(&bootinfo.shmem.common, struct membanks,
common);
+}
+
+static inline struct shmem_membank_extra
*bootinfo_get_shmem_extra(void)
+{
+return bootinfo.shmem.extra;
+}
+#endif
+
+#endif /* XEN_BOOTFDT_H */
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
1UL << (BITS_PER_LONG -
1)), 2);
+RUNTIME_CHECK(arch_generic_hweightl, -1UL, BITS_PER_LONG);
+}
+#endif /* CONFIG_X86 */
#endif /* CONFIG_SELF_TESTS */
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-05-01 21:57, Stefano Stabellini wrote:
On Tue, 30 Apr 2024, Nicola Vetrini wrote:
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
On 2024-05-03 12:10, Jan Beulich wrote:
On 03.05.2024 09:29, Nicola Vetrini wrote:
On 2024-05-01 21:57, Stefano Stabellini wrote:
On Tue, 30 Apr 2024, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parent
50868
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
Repositories under people/* only execute the analyze step if manually
triggered, but in order to avoid blocking the rest of the pipeline
if such step is not run, allow it to fail.
Reported-by: Andrew Cooper
Signed-off-by: Nicola Vetrini
---
See https://gitlab.com/xen-project/people/bugseng/xen
using enum constants as controlling expressions
to comply with Rule 14.4.
Amend the comment in the enum definition to reflect the fact that
boolean uses of iommu_intremap are no longer allowed.
No functional change.
Signed-off-by: Maria Celeste Cesario
Signed-off-by: Simone Ballarin
Signed-off-
Tag the rule as clean, as there are no more violations in the codebase
since e8e8afee990a ("svm: Fix MISRA 8.2 violation").
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
Tag the rule as clean, as there are no more violations in the codebase since
93c27d54dd23 ("xen/arm: Fix MISRA regression on R1.1,
flexible array member not at the end").
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1 file changed, 1 inser
On 2024-05-01 21:54, Stefano Stabellini wrote:
On Mon, 29 Apr 2024, Nicola Vetrini wrote:
On 2024-04-25 02:28, Stefano Stabellini wrote:
> On Tue, 23 Apr 2024, Nicola Vetrini wrote:
> > The count_args_ macro violates Rule 20.7, but it can't be made
> > compliant with Rule 2
gy adopted to bring them into
compliance is to add parentheses around macro arguments where needed.
Nicola Vetrini (4):
x86/vpmu: address violations of MISRA C Rule 20.7
x86/hvm: address violations of MISRA C Rule 20.7
x86_64/uaccess: address violations of MISRA C Rule 20.7
x86_64/cpu_idl
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/x86_64/cpu_idle.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/arch/x86/x86_64/cpu_idle.c b/xen/arch/x86/x86_64/cpu_idle.c
index fc
n possibly alter the semantics of the passed-in macro parameter.
xlat_malloc_init is touched for consistency, despite the construct
being already deviated.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/x86_64/uaccess.h | 7 ---
1 file changed, 4 insert
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/hvm/mtrr.c | 2 +-
xen/arch/x86/hvm/rtc.c | 2 +-
xen/arch/x86/include/asm/hvm/save.h | 2 +-
3 files changed, 3 insertions(+), 3 deletion
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/cpu/vpmu_amd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/xen/arch/x86/cpu/vpmu_amd.c b/xen/arch/x86/cpu/vpmu_amd.c
index db2fa420e14a..97
allowing
uses of these functions in the project.
The rules are also marked as clean as a consequence.
Signed-off-by: Nicola Vetrini
---
.../eclair_analysis/ECLAIR/deviations.ecl | 14 ++
.../eclair_analysis/ECLAIR/monitored.ecl | 2 ++
automation/eclair_analysis/ECLAIR
On 2024-05-16 01:18, Stefano Stabellini wrote:
On Wed, 15 May 2024, Nicola Vetrini wrote:
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
This rule has no more violations in the codebase, so it can be
set as clean.
No functional change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/tagging.ecl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/automation/eclair_analysis/ECLAIR/tagging.ecl
Some MISRA C rules already have no violations in Xen, so they can be
set as clean.
Reorder the rules in tagging.ecl according to version ordering
(i.e. sort -V) and split the configuration on multiple lines for
readability.
Signed-off-by: Nicola Vetrini
---
.../eclair_analysis/ECLAIR
s good so once we agree on the commit message, then
I am happy to update it on commit.
Cheers,
since Julien is ok with the patch, with the commit message he proposed,
I think this needs an R-by or an A-by in order to commit for 4.19.
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
sult, they can be exempted using a comment-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
---
Adding the asmlinkage macro to variables is not appropriate, as
this pseudo-attribute may expand, for instance, to a different calling
convention in the future (e.g. stdcall)
---
xe
e function must remain
extern.
Therefore, this function is deviated using a comment-based deviation.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/traps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/traps.c b/xen/arch/x86/traps.c
index 468a03608102..99
Hi all,
this series contains various miscellaneous changes to the ECLAIR and deviations
for MISRA rules
Nicola Vetrini (4):
docs/misra: exclude gdbsx from MISRA compliance
automation/eclair_analysis: avoid an ECLAIR warning about escaping
x86: address violations of MISRA C Rule 8.4
x86
The parentheses in this regular expression should be doubly
escaped because they are undergo escaping twice.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/automation/eclair_analysis
These files are used when debugging Xen, and are not meant to comply
with MISRA rules at the moment.
No functional change.
Signed-off-by: Nicola Vetrini
---
docs/misra/exclude-list.json | 8
1 file changed, 8 insertions(+)
diff --git a/docs/misra/exclude-list.json b/docs/misra
On 2024-05-28 08:28, Jan Beulich wrote:
On 27.05.2024 16:53, Nicola Vetrini wrote:
Rule 8.4 states: "A compatible declaration shall be visible when
an object or function with external linkage is defined."
These variables are only referenced from asm modules, so they
need to be extern
CC: Simone Ballarin
CC: Federico Serafini
CC: Nicola Vetrini
v2:
* Fall back to generic, not builtin.
* Extend the testing with multi-bit values.
* Use always_inline for x86
* Defer x86 optimisation to a later change
---
xen/arch/arm/include/asm/bitops.h | 2 +-
xen/arch/ppc/include/as
On 2024-05-31 10:48, Andrew Cooper wrote:
On 31/05/2024 9:34 am, Andrew Cooper wrote:
On 31/05/2024 7:56 am, Nicola Vetrini wrote:
On 2024-05-31 03:14, Stefano Stabellini wrote:
On Fri, 24 May 2024, Andrew Cooper wrote:
Perform constant-folding unconditionally, rather than having it
Patches 1 to 4 address violations of MISRA C Rule 20.12 by deviating certain
uses of some macros, while the last patch addresses some regressions introduced
by the latest bitops series
Nicola Vetrini (5):
xen/domain: deviate violation of MISRA C Rule 20.12
x86/domain: deviate violation of
ameter and for token pasting the rule deliberately violated.
A SAF-x-safe comment is used to deviate the usage.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/include/asm/shared.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/xen/arch/x86/include/asm/shared.h
b/xe
change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index cf62a874d928..f29db9e08248 100644
--- a
ator.
No functional change.
Fixes: ea59e7d780d9 ("xen/bitops: Cleanup and new infrastructure ahead of
rearrangements")
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 2 +-
xen/include/xen/self-tests.h | 2 +-
2 files changed,
ular macro argument and as an operand for
stringification in the expansion of CHECK_FIELD_.
This is deviated using a SAF-x-safe comment.
No functional change.
Signed-off-by: Nicola Vetrini
---
xen/arch/x86/domain.c | 1 +
xen/arch/x86/domctl.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/xe
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
---
docs/misra/safe.json | 8
xen/common/domain.c | 1 +
2 files
On 2024-06-01 14:47, Andrew Cooper wrote:
On 01/06/2024 11:16 am, Nicola Vetrini wrote:
ea59e7d780d9 ("xen/bitops: Cleanup and new infrastructure ahead of
rearrangements")
introduced new violations on previously clean rules 20.9 and 20.12.
The first is introduced because CONFIG_CC_I
On 2024-06-01 15:08, Andrew Cooper wrote:
On 01/06/2024 1:58 pm, Nicola Vetrini wrote:
On 2024-06-01 14:47, Andrew Cooper wrote:
On 01/06/2024 11:16 am, Nicola Vetrini wrote:
ea59e7d780d9 ("xen/bitops: Cleanup and new infrastructure ahead of
rearrangements")
introduced new vio
On 2024-06-01 16:37, Andrew Cooper wrote:
On 01/06/2024 11:16 am, Nicola Vetrini wrote:
Patches 1 to 4 address violations of MISRA C Rule 20.12 by deviating
certain
uses of some macros, while the last patch addresses some regressions
introduced
by the latest bitops series
Nicola Vetrini (5
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are added
to the list of clean guidelines.
Some guidelines listed in the additional clean section for ARM are also
clean on x86, so they can be removed from there.
No functional change.
Signed-off-by: Nicola Vetrini
---
+Cc
On 2024-06-03 07:58, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -483,6 +483,12 @@ leads to a violation of the Rule are deviated."
-config=MC3R1.R20.12,m
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"
On 2024-06-03 20:52, Jan Beulich wrote:
On 03.06.2024 09:13, Nicola Vetrini wrote:
On 2024-06-03 07:58, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR/deviations.ecl
+++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
@@ -483,6 +483,12
On 2024-06-03 23:24, Jan Beulich wrote:
On 03.06.2024 21:12, Nicola Vetrini wrote:
On 2024-06-03 20:52, Jan Beulich wrote:
On 03.06.2024 09:13, Nicola Vetrini wrote:
On 2024-06-03 07:58, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/automation/eclair_analysis/ECLAIR
On 2024-06-04 13:39, Oleksii K. wrote:
On Sat, 2024-06-01 at 21:13 +0200, Nicola Vetrini wrote:
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are
added
to the list of clean guidelines.
Some guidelines listed in the additional clean section for ARM are
also
clean on x86, so
On 2024-06-04 08:08, Jan Beulich wrote:
On 01.06.2024 12:16, Nicola Vetrini wrote:
--- a/xen/arch/x86/include/asm/shared.h
+++ b/xen/arch/x86/include/asm/shared.h
@@ -76,6 +76,7 @@ static inline void arch_set_##field(struct vcpu *v,
\
GET_SET_SHARED(unsigned long, max_pfn
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are added
to the list of clean guidelines.
Some guidelines listed in the additional clean section for ARM are also
clean on x86, so they can be removed from there.
No functional change.
Signed-off-by: Nicola Vetrini
patches.
Nicola Vetrini (3):
x86/domain: deviate violation of MISRA C Rule 20.12
automation/eclair_analysis: address remaining violations of MISRA C
Rule 20.12
automation/eclair_analysis: add more clean MISRA guidelines
automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++
automation
change.
Signed-off-by: Nicola Vetrini
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++
1 file changed, 6 insertions(+)
diff --git a/automation/eclair_analysis/ECLAIR/deviations.ecl
b/automation/eclair_analysis/ECLAIR/deviations.ecl
index 447c1e6661d1..e2653f77eb2c 100644
--- a
ular macro argument and as an operand for
stringification in the expansion of CHECK_FIELD_.
This is deviated using a SAF-x-safe comment.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
docs/misra/safe.json | 8
xen/arch/x86/domain.c | 1 +
xen/arch/x86/domctl.
On 2024-06-10 09:43, Jan Beulich wrote:
On 07.06.2024 22:13, Nicola Vetrini wrote:
Rules 20.9, 20.12 and 14.4 are now clean on ARM and x86, so they are
added
to the list of clean guidelines.
Why is 20.9 being mentioned here when ...
--- a/automation/eclair_analysis/ECLAIR/tagging.ecl
+++ b
he 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
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 8
1 file changed, 8 insertion
here.
[1]
https://lore.kernel.org/xen-devel/2f2c865f20d0296e623f1d65bed25c083f5dd497.1711700095.git.nicola.vetr...@bugseng.com/
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
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
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
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
These local helpers could in principle be deviated, but the readability
and functionality are essentially unchanged by complying with the rule,
so I decided to modify the macro def
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
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
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
---
automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
1 file changed, 1 insertion
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
---
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 af
On 2024-06-12 11:19, Jan Beulich wrote:
On 11.06.2024 17:53, Nicola Vetrini wrote:
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
On 2024-06-12 12:36, Jan Beulich wrote:
On 12.06.2024 11:52, Nicola Vetrini wrote:
On 2024-06-12 11:19, Jan Beulich wrote:
On 11.06.2024 17:53, Nicola Vetrini wrote:
MISRA C Rule 20.7 states: "Expressions resulting from the expansion
of macro parameters shall be enclosed in parent
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Reviewed-by: Jan Beulich
---
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
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
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/gues
ause 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
---
Changes in v2:
- Introduce a deviation instead of adding parentheses
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 6 ++
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
---
automation/eclair_analysis/ECLAIR/analyze.sh | 3 +--
1 file changed, 1 insertion
n possibly alter the semantics of the passed-in macro parameter.
No functional change.
Signed-off-by: Nicola Vetrini
Acked-by: Jan Beulich
---
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
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
he 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
---
automation/eclair_analysis/ECLAIR/deviations.ecl | 8
1 file changed, 8 insertion
nks,
Nicola
[1]
https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/staging/X86_64-BUGSENG/latest/PROJECT.ecd;/by_service/MC3R1.R5.3.html
--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)
On 2024-06-19 15:42, Jan Beulich wrote:
On 19.06.2024 15:23, Nicola Vetrini wrote:
I was looking at the shadowing due to the struct identifier and the
local variables "mctctl" in x86/cpu/mcheck/mctelem.c (see [1], the
second report). This kind of shadowing seems very intentiona
1 - 100 of 1053 matches
Mail list logo
