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

Re: [PATCH] misra: add deviation for PrintErrMesg() function


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Dmytro Prokopchuk1 <dmytro_prokopchuk1@xxxxxxxx>
  • Date: Tue, 19 Aug 2025 18:33:21 +0000
  • Accept-language: en-US, uk-UA, ru-RU
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; 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=M3VwEsLRkfi8LA2LlMMSvtpPduGc9+igZfMWlXI5awo=; b=tPS1GBgl/QoAfwppopa6xVkgTsY7drkCr+41nkWrCnLnDJ0FpvIC4MF5mz3UzznAeYsYVkPTqALKiAsZWGUu3CvvppVNU+Ma5PIN4cQkScpvcYxlAn99Z5u/LqFzaPjv29LPEAFBB7QAWR2HJochPC3mtUvavFfEmHSiHDWSjGz3W6PnUiOv280wa69rpee+U1IrL9u9dwow+j2IeAZSKqA2pi5O2YHbKK+H/TY8YO3Owe5KijH5Cmh7BF8bELK6lhTsVnPvEvcEJY08ISCiHS2VfaNA38YjsMjoR+7EP2f4SDWPpkLOf85SuDygfnY91obl1wPuyX+eta6aIY7p/g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=xr0Wi5Qv0ellTElOnriWx6N/GuAe+de9gUdP5uZL6RoLDZkqF/9QOQVEJVeKtNE8K5/TjNchb+dnLW+jgALDh1AsxwERevijJdn/Es1j92bAslq5YjN99VbAoYaFbMeZ1D9BEzMQM32ibP0e15if54cRPo2XdJczh62R3ZEpfZqDDtrklUFLVjI8/05H4F9S4vR02dytpLR77v3jDLkj0zFQqNe30Rsm0XJVF+S4aw9esWhVxX7Wjo5wuIbCNpp9CUroiHKxHhltt5GDP+7Vd1CNGG1Fi0RTlqKFv8LtcHI40/VX6Z3qFtSLlL+m3+j1U57rNXjq0vr9FYSak4SOUg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=epam.com;
  • Cc: Nicola Vetrini <nicola.vetrini@xxxxxxxxxxx>, Doug Goldstein <cardoe@xxxxxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Anthony PERARD <anthony.perard@xxxxxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, Julien Grall <julien@xxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Tue, 19 Aug 2025 18:33:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHcEQr89D/JS5GCrUaBbORYWk1wAbRp920AgAASxgCAABODAIAAL66A
  • Thread-topic: [PATCH] misra: add deviation for PrintErrMesg() function


On 8/19/25 18:42, Jan Beulich wrote:
> On 19.08.2025 16:32, Dmytro Prokopchuk1 wrote:
>> On 8/19/25 16:25, Jan Beulich wrote:
>>> On 19.08.2025 15:12, Dmytro Prokopchuk1 wrote:
>>>> MISRA C Rule 2.1 states: "A project shall not contain unreachable code."
>>>>
>>>> The function 'PrintErrMesg()' is implemented to never return control to
>>>> its caller. At the end of its execution, it calls 'blexit()', which, in
>>>> turn, invokes '__builtin_unreachable()'. This makes the 'return false;'
>>>> statement in 'read_file()' function unreachable.
>>>
>>> I'm disappointed. In earlier review comments I pointed out that there are
>>> two. Yet you say "the", without further disambiguation.
>>>
>>>> --- a/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> +++ b/automation/eclair_analysis/ECLAIR/deviations.ecl
>>>> @@ -41,6 +41,10 @@ not executable, and therefore it is safe for them to be 
>>>> unreachable."
>>>>    
>>>> -call_properties+={"name(__builtin_unreachable)&&stmt(begin(any_exp(macro(name(ASSERT_UNREACHABLE)))))",
>>>>  {"noreturn(false)"}}
>>>>    -doc_end
>>>>    
>>>> +-doc_begin="Unreachability caused by the call to the 'PrintErrMesg()' 
>>>> function is deliberate, as it terminates execution, ensuring no control 
>>>> flow continues past this point."
>>>> +-config=MC3A2.R2.1,reports+={deliberate, "any_area(^.*PrintErrMesg.*$ && 
>>>> any_loc(file(^xen/common/efi/boot\\.c$)))"}
>>>> +-doc_end
>>>
>>> I don't understand the description here, nor ...
>>>
>>>> --- a/docs/misra/deviations.rst
>>>> +++ b/docs/misra/deviations.rst
>>>> @@ -97,6 +97,13 @@ Deviations related to MISRA C:2012 Rules:
>>>>           Xen expects developers to ensure code remains safe and reliable 
>>>> in builds,
>>>>           even when debug-only assertions like `ASSERT_UNREACHABLE() are 
>>>> removed.
>>>>    
>>>> +   * - R2.1
>>>> +     - Function `PrintErrMesg()` terminates execution (at the end it calls
>>>> +       `blexit()`, which, in turn, invokes `__builtin_unreachable()`), 
>>>> ensuring
>>>> +       no code beyond this point is ever reached. This guarantees that 
>>>> execution
>>>> +       won't incorrectly proceed or introduce unwanted behavior.
>>>> +     - Tagged as `deliberate` for ECLAIR.
>>>
>>> .. the text here. PrintErrMesg() is noreturn. Why would anything need 
>>> saying about
>>> it? Isn't the problem here solely with the tail of read_file(), while other 
>>> uses
>>> of PrintErrMesg() are okay?
>>
>> I'm a little bit confused.
>>
>> As I understood you proposed to insert the SAF comment before the
>> 'return' statement (with proper justification).
>>
>> And current Eclair configuration & descriptions are not good at all.
> 
> Not sure how that's related, but apart from this, ...
> 
>> Am I right?
> 
> ... yes. Yet how is what you submitted here related to the issue in 
> read_file(),
> which may be addressable by a simple SAF comment (as you say in your reply)?
> 
> Jan

The Eclair reports violation as follows:
"call to function `PrintErrMesg(const CHAR16*, EFI_STATUS)' (unit 
`xen/common/efi/boot.c' with target `xen/arch/arm/efi/boot.o') is one 
cause of unreachability of the next statement"

So, patch was about to ignore violations in file 'xen/common/efi/boot.c'
(actually function read_file() is there) where appears text 'PrintErrMesg'.

Probably this is too unclear. And violation location (read_file()) 
should be explicitly specified...

 From other side simple SAF-xx-safe could address this case as well.

Dmytro.




 


Rackspace

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