[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [XEN PATCH 10/11] xen/sched: add ASSERT_UNREACHABLE() to address MISRA C:2012 Rule 2.1
- To: Julien Grall <julien@xxxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Tue, 8 Aug 2023 17:36:46 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=0SflO+UEOlwdotTVRSMKPXjDifvAURaeLbRt7mtTpIw=; b=WZ8xfzKNFuJh64FfhyuGh8ofq8Gf2mZHpS2ubF+kz1UFgt4/dbxaEV4TfEjFebpn1cKoIvLewLm8vVBxgHa8njT1STajOLG3LAwkSPyVgQqUJ0w4y+u0Izc3CX2K1ZvJWL9rX/rN3sNDy8rJ1lAgdqGA0rIcUsn6br0HO6vkAiTEoLcBiO2xhM++ABxIgXP/YH1cjfdo//ld4ne5R2MYV3+AyGbqIhvznbJHdA3m6zN8jkD9evjLTpTnDAUakDtXkgt7+1J28Ra/dHk16t3xtD1dfvQC9DtBQW470/6qu739xmhzzP7TLh8nds2G4ksKKLaRDFZWobLqFKrAFtGqhw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mva2z9WvqJl4epr7zZuY5uudnGMKwiSpuHbe7wTO4/hy7c6556cGbzZIbl7RXcX8RitF2XbrYBo51O74aXwDwZ99TcziLuSjC++Yp8um4PfVTRaHrIcWDF3qUAVD9S13/aHJ6psn9bgQVDkKLtu4XWgb/eottV1Ypg7JbMeLytsDWr5+5r4ROsDewyA82WleacCHN3q1gDo/GTED76hffqcJBgmUMa1lxx/fR6f6JLft46AbAsoHrXxJgs7R0DvFyKk4OmxrrN1riK7LDlyEszBnQmbG9MqTHrMwvJyREqKOekSay3hH0Js5NloQVpg+/c671ZNtSjlC2zpckMQdIw==
- Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
- Cc: sstabellini@xxxxxxxxxx, michal.orzel@xxxxxxx, xenia.ragiadakou@xxxxxxx, ayan.kumar.halder@xxxxxxx, consulting@xxxxxxxxxxx, George Dunlap <george.dunlap@xxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
- Delivery-date: Tue, 08 Aug 2023 15:36:59 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 08.08.2023 17:25, Julien Grall wrote:
> On 02/08/2023 15:38, Nicola Vetrini wrote:
>> The break statement after the return statement is definitely unreachable.
>> As such, an call to the ASSERT_UNREACHABLE() macro is added to signal
>> the intentionality of such construct.
>
> How about using unreachable() rather than ASSERT_UNREACHABLE()? The main
> difference is the later will hint the compiler that the code cannot be
> reached and will not crash Xen in debug build (this could be changed).
Isn't using unreachable() in place of ASSERT_UNREACHABLE() unsafe (not
here but in general)? It'll tell the compiler that (in the extreme case)
it can omit the function epilogue, including the return instruction. In
the resulting build, if the code turns out to be reachable, execution
would fall through into whatever follows.
In the case here ...
>> --- a/xen/common/sched/core.c
>> +++ b/xen/common/sched/core.c
>> @@ -2233,6 +2233,7 @@ static bool sched_tasklet_check_cpu(unsigned int cpu)
>> /* fallthrough */
>> case TASKLET_enqueued|TASKLET_scheduled:
>> return true;
>> + ASSERT_UNREACHABLE();
>> break;
>> case TASKLET_scheduled:
>> clear_bit(_TASKLET_scheduled, tasklet_work);
... "return" alone already tells the compiler that "break" is
unreachable. You don't need unreachable() for that. As said before,
"break" like this simply want purging (and Misra is wrong to demand
"break" everywhere - it should instead demand no [unannotated]
fall-through, which can also be achieved by return, continue, and
goto).
Jan
|
