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

Re: [PATCH v9 02/16] vpci: use per-domain PCI lock to protect vpci structure


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Stewart Hildebrand <stewart.hildebrand@xxxxxxx>
  • Date: Wed, 20 Sep 2023 09:56:28 -0400
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=citrix.com smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); 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=XQJh4EW+gXVDVoVOEtiegw9LowjMpw7R7YalCQsWz78=; b=dl13YtBAaH8Iqc7hS0ufiflt7nKJZV4mYFSN/35JhPoxdNs55i//UiPKYFYBSkja37PG2Dp7UJUHzQMRp47tbGu54nUgOyYOUU+AilXc93H/5Pz+dDtGuOHFRzo7I7mtbMEHA7UxOKrYSJKzXKPvfZvWwLFg5gCJRO88akBj8GO7v6wSBT3NU7XokScv3H2bUeqQFqUsvWrDF4Y7xE5bUitFNNI8cKgXisybnfc/lsUomTBEgtR5CdCJfPzKJSIWcOsZ3T/St0dZU01FkYo2wbRjYmHVV6qLpUt6U0PHkiEj7ficeW+c+Q0BnN6PJN5FtfuFSsAVgVesDPMWUIdnwQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PXTXk3DnOXVsCeIlJyyM3V9Nwpq3hnMyye8zAmYn9GyNIZO4Nv/Im04MalI91AUfPd2H6QRrYkDRIZOWAWrZE7M+u4BIsfpLt39c+kzg0+nrJbTD+i4FmPx3R+9OQVc1mD00L/5E1pNafI2g+rygSvpDP+14fjQo2+Kd+UcDC13oVqBOb8wo577ihmXveXNibcsGMsl13WUYsNrBR5AiojVJWU8u3ZySUjU4lEr2ZwZRusQ6/gK4aPHrEpuSs4XAF6j4QnZFH4szeLZwZuMyCKQXNFeY2MKjmbdHuOlhJcXQRF07h4ugPUjHDTQKq8qjTy5t9dik1PdJZtcsQv/n3g==
  • Cc: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "Oleksandr Andrushchenko" <Oleksandr_Andrushchenko@xxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Jun Nakajima <jun.nakajima@xxxxxxxxx>, Kevin Tian <kevin.tian@xxxxxxxxx>, Paul Durrant <paul@xxxxxxx>
  • Delivery-date: Wed, 20 Sep 2023 13:56:51 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 9/20/23 04:09, Roger Pau Monné wrote:
> On Tue, Sep 19, 2023 at 12:20:39PM -0400, Stewart Hildebrand wrote:
>> On 9/19/23 11:39, Roger Pau Monné wrote:
>>> On Tue, Aug 29, 2023 at 11:19:42PM +0000, Volodymyr Babchuk wrote:
>>>> diff --git a/xen/drivers/vpci/msi.c b/xen/drivers/vpci/msi.c
>>>> index 8f2b59e61a..a0733bb2cb 100644
>>>> --- a/xen/drivers/vpci/msi.c
>>>> +++ b/xen/drivers/vpci/msi.c
>>>> @@ -318,15 +321,28 @@ void vpci_dump_msi(void)
>>>>                       * holding the lock.
>>>>                       */
>>>>                      printk("unable to print all MSI-X entries: %d\n", rc);
>>>> -                    process_pending_softirqs();
>>>> -                    continue;
>>>> +                    goto pdev_done;
>>>>                  }
>>>>              }
>>>>
>>>>              spin_unlock(&pdev->vpci->lock);
>>>> + pdev_done:
>>>> +            /*
>>>> +             * Unlock lock to process pending softirqs. This is
>>>> +             * potentially unsafe, as d->pdev_list can be changed in
>>>> +             * meantime.
>>>> +             */
>>>> +            read_unlock(&d->pci_lock);
>>>>              process_pending_softirqs();
>>>> +            if ( !read_trylock(&d->pci_lock) )
>>>> +            {
>>>> +                printk("unable to access other devices for the domain\n");
>>>> +                goto domain_done;
>>>
>>> Shouldn't the domain_done label be after the read_unlock(), so that we
>>> can proceed to try to dump the devices for the next domain?  With the
>>> proposed code a failure to acquire one of the domains pci_lock
>>> terminates the dump.
>>>
>>>> +            }
>>>>          }
>>>> +        read_unlock(&d->pci_lock);
>>>>      }
>>>> + domain_done:
>>>>      rcu_read_unlock(&domlist_read_lock);
>>>>  }
>>>>
>>
>> With the label moved, a no-op expression after the label is needed to make 
>> the compiler happy:
>>
>>             }
>>         }
>>         read_unlock(&d->pci_lock);
>>  domain_done:
>>         (void)0;
>>     }
>>     rcu_read_unlock(&domlist_read_lock);
>> }
>>
>>
>> If the no-op is omitted, the compiler may complain (gcc 9.4.0):
>>
>> drivers/vpci/msi.c: In function ‘vpci_dump_msi’:
>> drivers/vpci/msi.c:351:2: error: label at end of compound statement
>>   351 |  domain_done:
>>       |  ^~~~~~~~~~~
> 
> 
> Might be better to place the label at the start of the loop, and
> likely rename to next_domain.

That would bypass the loop condition and increment statements.



 


Rackspace

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