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

Re: [XEN PATCH 4/4] xen: address violations of MISRA C:2012 Rule 13.1


  • To: Simone Ballarin <simone.ballarin@xxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 23 Oct 2023 16:03:55 +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=fpIJiKb5ovzB3oo+KARX+SPr3ykDCz0v8w8szud63Rc=; b=IxwTBb7d18xEVEtK2zc0MgRpdMLeJim6GIk5TCaI2iEfkjhERd+AXtPo1vwpfRuWu7s2ea7/ute2lITpbdqBu7Ua/ZnzWK7bKnkhx9QB3bvsFR8Yuy76wIg0Fny1SS60tfY32RyAWF8YKRqUF0P+LUV+xAVlj+K4l8iIYmp1OHTIRUz+qz75daROjJXMJpm8CNfCyN5iAi0kegoeyd6P9tNCHM8x45MK/2xZgUeucryfALfPbORjP+0mIhLYr8Ox0bLis4zh8SEvOY66Lk0KeeiIv5C7c/wZU2lRfI6yXJrC4QVBnmQ3slU50WzFxUrWfNDZT98g3dPS4xIOJAi9jw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b6lVTeQ1BEhSr+wFGhBfvV9NP97dEnLp1T1c29p5ibCDCPOyjZcHb7JAlvbmVZiyoPv2HfZuSYq0nhp2B9PIYs3Fr8eCbnZo9IJCh0aHM9EiOr8TCGdIScx5I9I83z4ydaV02oUpPiPlbCqNUvoCEdiXdQS1fsgofrYOZmhNgvnhOOVu7eFczQZ+EqwVtKke3h6ibykbwCydZQHYmsCn6kmqR45tY/ICGVNWCtsL6JIGD+rIUdo1eTDgvBPp1NQzokf1n0QN7eLPM2p+ehgfxtzLQ6Dxrqv+3mlkGY221xPCgbqdFm4LbQDeqmmxwOltDkyxw+uhDEjf2m+Jlklgeg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: consulting@xxxxxxxxxxx, sstabellini@xxxxxxxxxx, George Dunlap <george.dunlap@xxxxxxxxxx>, Dario Faggioli <dfaggioli@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 23 Oct 2023 14:04:04 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 18.10.2023 16:18, Simone Ballarin wrote:
> --- a/xen/common/sched/core.c
> +++ b/xen/common/sched/core.c
> @@ -1504,6 +1504,8 @@ long vcpu_yield(void)
>  {
>      struct vcpu * v=current;
>      spinlock_t *lock;
> +    domid_t domain_id;
> +    int vcpu_id;

While I realize that the field this variable is initialized from is
plain "int", I still think that being wrong means the new variables
here and below want to be "unsigned int".

> @@ -1515,7 +1517,9 @@ long vcpu_yield(void)
>  
>      SCHED_STAT_CRANK(vcpu_yield);
>  
> -    TRACE_2D(TRC_SCHED_YIELD, current->domain->domain_id, current->vcpu_id);
> +    domain_id = current->domain->domain_id;
> +    vcpu_id = current->vcpu_id;
> +    TRACE_2D(TRC_SCHED_YIELD, domain_id, vcpu_id);

If you touch this, I think you ought to also switch to using "v" in
place of "current" (making the supposed side effect go away aiui).

Yet then (for the further changes to this file) - what persistent
side effect does reading "current" have? Clarification of that is
part of the justification for this change, and hence ought to be
spelled out in the description.

> --- a/xen/drivers/char/ns16550.c
> +++ b/xen/drivers/char/ns16550.c
> @@ -445,10 +445,12 @@ static void __init cf_check ns16550_init_postirq(struct 
> serial_port *port)
>              struct msi_info msi = {
>                  .sbdf = PCI_SBDF(0, uart->ps_bdf[0], uart->ps_bdf[1],
>                                   uart->ps_bdf[2]),
> -                .irq = rc = uart->irq,
> +                .irq = uart->irq,
>                  .entry_nr = 1
>              };
>  
> +            rc = uart->irq;
> +
>              if ( rc > 0 )

If this needs transforming, I think we'd better switch it to

            rc = 0;

            if ( uart->irq > 0 )

thus matching what we have elsewhere in the function.

Jan



 


Rackspace

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