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

Re: [PATCH 2/3] x86/msi: remove return value from msi_set_mask_bit()


  • To: David Vrabel <dvrabel@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 11 Nov 2022 10:44:50 +0100
  • 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=HMdjc1Jw8nTIAr/jG5D1RVh4couVyT+4RZNHhYm/lno=; b=WBypLfs+Jwp9OIl/OYo1bmC1iWC/a5IMNjigTYvKiYpcvNwyHsG7JuMcwNLEGjHfP5hC2ibqYQYtG0UEowbWcMwnn+IpcWZQLLeEnh3IfVMENSxsSAcSMXRilwubxXIw4fZ9FwOJ0OHkq2laSMKYS2mqWA1AkpAtlOXACwpKIH5LF+cTSefORH3ooC+PooVhrI5UlzQbo/+GMW1P14GjPO1XJqrCSdIXDRSwbEmIGDB9HHO8T0rnLQoad+8Yc022sWlFRdI/iMo4kt33DuvJpA4mHx8pGyu9ra/j9SbCDPb0EIbC5Rs5+lwqeoWwl47yWnUyN4Wf0pNwkMRDLyXq6g==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rt4GZIwBCySAJz8mjO2Omdjn3XtZymEZ4MH6p+hgW0llAJdqsVEGPJjH0nnr8fQVPwTQGGYHQ01esqnHSV9CL0LZNaRFQWlyN4pTGCKyCEfEdeSjwpEdtubFv+hQyQSTn403lWUuF+A331QD/Umxxuv5L6ij+Lf1fp1I9kdQzDDorYacOQnR/McBTzvXxdHdY83mijsKxy8QsKx/I8p4g6o3dsRbPxUW1UNKetwK9JYUHY8YgUqmS2enBG1QZ961+rPkXzULhhLSiswrTA7gmcsnVGK7dLR8kvOqt2baui0dx9Tbsu5ho/h36qTehKGM8H9VCQljRSR12TpHOGNxLg==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, David Vrabel <dvrabel@xxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 11 Nov 2022 09:44:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 10.11.2022 17:59, David Vrabel wrote:
> The return value was only used for WARN()s or BUG()s so it has no
> functional purpose. Simplify the code by removing it.
> 
> The meaning of the return value and the purpose of the various WARNs()
> and BUGs() is rather unclear. The only failure path (where an MSI-X
> vector needs to be masked but the MSI-X table is not accessible) has a
> useful warning message.

No, you're removing an important 2nd such path - the default case in the
switch() statement. Getting there would mean another bug elsewhere, which
we don't want to leave undetected for yet longer (and hence yet harder to
debug once finally some misbehavior surfaces). That default case may
warrant the addition of ASSERT_UNREACHABLE() according to the respective
description in ./CODING_STYLE, but I don't see the removal of the
"return" as acceptable (also for another reason as explained below).

The idea of the WARN() / BUG_ON() is to
- not leave failed unmasking unrecorded,
- not continue after failure to mask an entry.
This combines with the functions where the constructs are not having
ways to properly propagate the errors to their callers.

> @@ -361,11 +361,6 @@ static bool msi_set_mask_bit(struct irq_desc *desc, bool 
> host, bool guest)
>  
>              if ( likely(control & PCI_MSIX_FLAGS_ENABLE) )
>                  break;
> -
> -            entry->msi_attrib.host_masked = host;
> -            entry->msi_attrib.guest_masked = guest;
> -
> -            flag = true;
>          }
>          else if ( flag && !(control & PCI_MSIX_FLAGS_MASKALL) )
>          {
> @@ -385,14 +380,10 @@ static bool msi_set_mask_bit(struct irq_desc *desc, 
> bool host, bool guest)
>              control |= PCI_MSIX_FLAGS_MASKALL;
>          pci_conf_write16(pdev->sbdf,
>                           msix_control_reg(entry->msi_attrib.pos), control);
> -        return flag;

Both this and ...

> -    default:
> -        return 0;

... this have previously prevented to make it ...

> +        break;
>      }
>      entry->msi_attrib.host_masked = host;
>      entry->msi_attrib.guest_masked = guest;

... here. This is a change in behavior which is neither obviously benign
nor properly justified in the description, yet clearly going beyond what
the title says the patch is about.

Jan



 


Rackspace

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