All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger@xenproject.org>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>,
	Nicola Vetrini <nicola.vetrini@bugseng.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Teddy Astie <teddy.astie@vates.tech>
Subject: Re: [PATCH 05/12] x86/crash: address Misra 2.1 rule violation
Date: Thu, 10 Sep 2026 14:29:07 +0200	[thread overview]
Message-ID: <aqKikxvL_6SCs_Cj@macbook.local> (raw)
In-Reply-To: <f51588b3-4100-4353-a35d-ac0780f2aab0@suse.com>

On Thu, Sep 10, 2026 at 11:52:10AM +0200, Jan Beulich wrote:
> On 10.09.2026 11:30, Roger Pau Monné wrote:
> > On Thu, Sep 10, 2026 at 10:38:34AM +0200, Jan Beulich wrote:
> >> On 10.09.2026 09:49, Roger Pau Monné wrote:
> >>> On Fri, Aug 28, 2026 at 09:02:18AM +0200, Jan Beulich wrote:
> >>>> The use of unreachable(), when unreachability is visible to Eclair (and
> >>>> compilers), is deemed a violation. Drop the redundant statement.
> >>>
> >>> Urg, isn't that something that should be fixed in Eclair then?
> >>> Otherwise all the unreachable() calls in our codebase are likely to be
> >>> found by Eclair sooner or later, and will need to be removed.
> >>
> >> No, aiui most are covered by deviations. In particular ones in BUG() and
> >> ASSERT_UNREACHABLE().
> > 
> > Shouldn't this be a deviation then also?
> 
> Maybe, just that I had no good idea how to express such a deviation (preferably
> without a SAF comment).
> 
> >  Maybe it would be helpful if
> > the commit message states why this is handled differently from other
> > unreachable() instances then.
> 
> I've added "..., , and the one here isn't covered by a deviation" to the first
> sentence. Will that suffice?

TBH, the handling of unreachable() feels inconsistent to me.  I don't
blame you for this, I know you are just trying to fix the remaining
issues.

I guess I will defer the change to someone more familiar with MISRA
and why some unreachable() usages are covered by deviations while
others aren't.

I think the point of adding something to the commit message is to
justify why this is removed vs a deviation being added.

Thanks, Roger.


  reply	other threads:[~2026-09-10 12:29 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-28  6:58 [PATCH 00/12] address most remaining Misra rule 2.1 violations Jan Beulich
2026-08-28  6:59 ` [PATCH 01/12] x86/IO-APIC: address Misra 2.1 rule violations Jan Beulich
2026-08-28  8:31   ` Nicola Vetrini
2026-09-10  7:38   ` Roger Pau Monné
2026-08-28  7:00 ` [PATCH 02/12] x86/mm: pagetable_dying() is HVM+SHADOW_PAGING only Jan Beulich
2026-09-10  7:36   ` Roger Pau Monné
2026-08-28  7:00 ` [PATCH 03/12] x86/shadow: eliminate unused forms of sh_map_and_validate_gl<N>e() Jan Beulich
2026-09-10  7:45   ` Roger Pau Monné
2026-08-28  7:01 ` [PATCH 04/12] x86: add noreturn in a few more places Jan Beulich
2026-08-29 13:21   ` Nicola Vetrini
2026-09-01  8:10     ` Jan Beulich
2026-08-31 19:13   ` Andrew Cooper
2026-09-01  6:26     ` Jan Beulich
2026-09-09 19:07       ` Nicola Vetrini
2026-09-10  6:43         ` Jan Beulich
2026-09-11 20:48           ` Nicola Vetrini
2026-09-01  6:31     ` Jan Beulich
2026-08-28  7:02 ` [PATCH 05/12] x86/crash: address Misra 2.1 rule violation Jan Beulich
2026-09-10  7:49   ` Roger Pau Monné
2026-09-10  8:38     ` Jan Beulich
2026-09-10  9:30       ` Roger Pau Monné
2026-09-10  9:52         ` Jan Beulich
2026-09-10 12:29           ` Roger Pau Monné [this message]
2026-09-11 18:53             ` Nicola Vetrini
2026-08-28  7:02 ` [PATCH 06/12] kexec: machine_reboot_kexec() doesn't return Jan Beulich
2026-08-28  9:55   ` Nicola Vetrini
2026-08-28  7:03 ` [PATCH 07/12] altp2m: address Misra 2.1 rule violation Jan Beulich
2026-08-31  1:14   ` Stefano Stabellini
2026-08-28  7:04 ` [PATCH 08/12] Arm/GIC: add noreturn in a few more places Jan Beulich
2026-08-31  1:21   ` Stefano Stabellini
2026-08-28  7:04 ` [PATCH 09/12] Eclair: deviate BUILD_ERROR() wrt rule 2.1 and introduce variants Jan Beulich
2026-08-29 14:04   ` Nicola Vetrini
2026-09-01  6:36     ` Jan Beulich
2026-08-31  1:30   ` Stefano Stabellini
2026-08-28  7:05 ` [PATCH 10/12] PCI/physdev: address Misra 2.1 rule violation Jan Beulich
2026-08-31  1:30   ` Stefano Stabellini
2026-08-28  7:05 ` [PATCH 11/12] x86/HVM: address Misra 2.1 rule violations Jan Beulich
2026-09-10  7:54   ` Roger Pau Monné
2026-08-28  7:06 ` [PATCH 12/12] x86/nSVM: address Misra 2.1 rule violation Jan Beulich
2026-09-10  7:44   ` Roger Pau Monné
2026-09-10  8:42     ` Jan Beulich

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=aqKikxvL_6SCs_Cj@macbook.local \
    --to=roger@xenproject.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=nicola.vetrini@bugseng.com \
    --cc=teddy.astie@vates.tech \
    --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.