[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v3] docs/misra: add rule 2.1 exceptions


  • To: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>
  • From: Bertrand Marquis <Bertrand.Marquis@xxxxxxx>
  • Date: Wed, 27 Sep 2023 08:14:46 +0000
  • Accept-language: en-GB, en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=6OWwdHE+5nPN1Ez2Vi00nQLfXpZC3JOsw9blE00uEUQ=; b=YEDP8tCO0VlZ4peDaw0UPyIBBY3jsAG8H0pQZ1wjmc+N065Er+9KLvXS/GwjZ3tra71YvhJgQjkUBXhU0eGaXE6ia2sMkBnvBw6c0hf9WJ/R+jPT/V1VSZl7QUfGP276liOjpRbe9hSFPu9dLf/vaMQHei3FU+D+0grDu0Y0IVjOsrtHybwWAaFcfQE8DTPQZboOq0W779GDNce8K5OaUSlJPvBuQaS3EGix1EUwpMSSgo4u/blPdnQZibHwAKbxgiviLsOiK55PtLT9sg9WSbM0n4BpJVmAjW8iSHokP6KIjqWgUj6jwQ1Ks/fwEjvIEb1qyXqekJwX7zt7K/xGcA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tyxh9TYn0pE4U02JePoD7Dv+QxWEm/icD4fojg5S/Jhl01iWPqcCFhPgVySZ5OpHqC8W2NJOxku8Ky85FgU1lbElZEMwgcnxlCu2MyHVLb1hc2PyVqv62yqUPj8BRMf+S4Up686zVdWFUL4f1QY2GhHL81C3AhZ8BER2pxxLexkj17yYW+N6pbj5F5nWgbsgfufkWcZR/TRZ/LLXYoXwMKWw1gZy9uYnfO5qdALTc7RuhjO6Ttpjyk92+9iT/00JNgAfbSXwO9EfJsXkJsVmmBEw7EhoXF+uN9N967B9EVx0se+4jF4XSv6nRmqS+SQ+uT396Q6nRHLuGxa3f7QcjA==
  • Authentication-results-original: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, "andrew.cooper3@xxxxxxxxxx" <andrew.cooper3@xxxxxxxxxx>, "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, "george.dunlap@xxxxxxxxxx" <george.dunlap@xxxxxxxxxx>, "roberto.bagnara@xxxxxxxxxxx" <roberto.bagnara@xxxxxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, Stefano Stabellini <stefano.stabellini@xxxxxxx>
  • Delivery-date: Wed, 27 Sep 2023 08:15:10 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true
  • Original-authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arm.com;
  • Thread-index: AQHZ4qiwUwH3koR9JUa91LeAyizAArAVxOqAgACZsICAGAuKgIAABdgA
  • Thread-topic: [PATCH v3] docs/misra: add rule 2.1 exceptions

Hi,

> On 27 Sep 2023, at 09:53, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx> wrote:
> 
>>> > diff --git a/xen/arch/arm/psci.c b/xen/arch/arm/psci.c
>>> > index 695d2fa1f1..2a8527cacc 100644
>>> > --- a/xen/arch/arm/psci.c
>>> > +++ b/xen/arch/arm/psci.c
>>> > @@ -59,6 +59,7 @@ void call_psci_cpu_off(void)
>>> >       }
>>> >   }
>>> >   +/* SAF-2-safe */
>>> I think any use of SAF-2-safe should be accompanied with an attribute...
>>> >   void call_psci_system_off(void)
>>> ... noreturn for function or ...
>>> >   {
>>> >       if ( psci_ver > PSCI_VERSION(0, 1) )
>>> > diff --git a/xen/arch/x86/shutdown.c b/xen/arch/x86/shutdown.c
>>> > index 7619544d14..47e0f59024 100644
>>> > --- a/xen/arch/x86/shutdown.c
>>> > +++ b/xen/arch/x86/shutdown.c
>>> > @@ -118,6 +118,7 @@ static inline void kb_wait(void)
>>> >               break;
>>> >   }
>>> >   +/* SAF-2-safe */
>>> >   static void noreturn cf_check __machine_halt(void *unused)
>>> >   {
>>> >       local_irq_disable();
>>> > diff --git a/xen/include/xen/bug.h b/xen/include/xen/bug.h
>>> > index e8a4eea71a..d47c54f034 100644
>>> > --- a/xen/include/xen/bug.h
>>> > +++ b/xen/include/xen/bug.h
>>> > @@ -117,6 +117,7 @@ struct bug_frame {
>>> >   #endif
>>> >     #ifndef BUG
>>> > +/* SAF-2-safe */
>>> >   #define BUG() do {                                              \
>>> >       BUG_FRAME(BUGFRAME_bug,  __LINE__, __FILE__, 0, NULL);      \
>>> >       unreachable();                                              \
>>> ... unreachable for macros. But the /* SAF-2-safe */ feels a little bit
>>> redundant when a function is marked as 'noreturn'.
>>> Is there any way to teach eclair about noreturn?
>> Actually I had the same thought while writing this patch. If we can
>> adopt unreachable and noreturn consistently maybe we don't need
>> SAF-2-safe. If the checker can support it.
>> Nicola, what do you think?
> 
> A couple of remarks:
> - if you put the noreturn attribute on some functions, then surely the code 
> after those is
> reported as unreachable. ECLAIR should pick up all forms of noreturn 
> automatically; otherwise, a simple configuration can be used.
> 
> - Note that the cause of unreachability in the vast majority of cases is the 
> call to
> __builtin_unreachable(), therefore a textual deviation on the definition of 
> unreachable, plus
> a bit of ECLAIR configuration, can deviate it (to be clear, just the SAF 
> comment is not
> sufficient, since deviations comments are meant to be applied at the top 
> expansion location,
> which is not on the macro definition).
> This is what it should look like, roughly:
> 
> -config=MC3R1.R2.1,reports+={deliberate, "any_area(any_loc(text(^<REGEX>$, 
> -1)))"}
> 
> #if (!defined(__clang__) && (__GNUC__ == 4) && (__GNUC_MINOR__ < 5))
> /* SAF-2-safe */
> #define unreachable() do {} while (1)
> #else
> /* SAF-2-safe */
> #define unreachable() __builtin_unreachable()
> #endif
> 
> where REGEX will match the translation of SAF-2-safe.
> 
> However, this will then entail that *some* SAF comments are treated specially 
> and, moreover,
> that some modification to the definition of unreachable won't work
> (e.g.
> #define M() __builtin_unreachable()
> /* SAF-2-safe */
> #define unreachable() M()
> 
> My opinion is that it's far easier for this to be an eclair configuration 
> (which has the
> advantage not to depend on the exact definition of unreachable) and then 
> perhaps a comment
> above it explaining the situation.

I agree here and it is easier to make an overall exception where we list the 
cases
where this is acceptable (ie all flavors of unreacheable) and document that 
eclair
was configured using "xxxx" to handle this.

Cheers
Bertrand

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





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.