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

Re: [PATCH] vpci: introduce per-domain lock to protect vpci structure


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Date: Mon, 14 Feb 2022 14:26:01 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; 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=kglRE+Ltomp1uOqZzKumzA6w/VPuR7sg+jHMWcYKaDw=; b=bpAlwT5BC94oa3m2GtjuiVTZ7B+Fkgyqap+pJFB2DDtO2i6DE1BpvEH61GPI1wcDszvBXBwvSBENbWxDuzPWdn00e7/n3W2HoT/i2rbTkm4mdtf4LbSs5KG6GQaKqvOODoKhC5TL4SdV1MX8ChKxyb0tVhnv5cAmP4bsYHj7CduDNnTUcz0RuIpjFrconxkokfyowxmCV+Anlg3LdPTKXM596ZbZJn/jZ8ivC1eIwdK8Eg7odApyjEhOcuEY9CWANne5xIvHT/5FxL4GSX0hSfmhCBFDCRwNoNYzZiakGRLoex46VLQrjyA9Xj3iFy/V0IjMbEHicCFo1PV5/9x3qg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WgQBvioz8Q9DoKPFITG/ZMC7J1hz0oxFTePwIegIGiGnmftn3h73pCSQEwJbYG+zWZ1QstuPdgDbhDPJmwa3IKpr1AoyZtgSPJI4eD0bYqHXT+E3w1uhMas9L962529/kI6Bklp51LnN7gajWpDZg7wB3woh0lgX7JSy10NwRqP9lt/3pvhFwC4DlIGqXeFqx9vJAjIUSOnGOMpfZKj5nm9R9K3iVN844c4uIiODmsgaqDItiCL8RJplWvnPwFDUpn7J+n3CBIJ9bb0XPZIifL1s2CceVdRCq9wDHOFmuo6FXCDTYiBaPDTmHn40v1ggkDX0XUS5pc1YzL7MUMO97Q==
  • Cc: "roger.pau@xxxxxxxxxx" <roger.pau@xxxxxxxxxx>, "julien@xxxxxxx" <julien@xxxxxxx>, "sstabellini@xxxxxxxxxx" <sstabellini@xxxxxxxxxx>, Oleksandr Tyshchenko <Oleksandr_Tyshchenko@xxxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Artem Mygaiev <Artem_Mygaiev@xxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Rahul Singh <rahul.singh@xxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Oleksandr Andrushchenko <Oleksandr_Andrushchenko@xxxxxxxx>
  • Delivery-date: Mon, 14 Feb 2022 14:26:19 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHYHboQT3cBWYI1/EGunE7hOwop6ayTIGYAgAABuQA=
  • Thread-topic: [PATCH] vpci: introduce per-domain lock to protect vpci structure


On 14.02.22 16:19, Jan Beulich wrote:
> On 09.02.2022 14:36, Oleksandr Andrushchenko wrote:
>> @@ -410,14 +428,37 @@ static void vpci_write_helper(const struct pci_dev 
>> *pdev,
>>                r->private);
>>   }
>>   
>> +static bool vpci_header_write_lock(const struct pci_dev *pdev,
>> +                                   unsigned int start, unsigned int size)
>> +{
>> +    /*
>> +     * Writing the command register and ROM BAR register may trigger
>> +     * modify_bars to run which in turn may access multiple pdevs while
>> +     * checking for the existing BAR's overlap. The overlapping check, if 
>> done
>> +     * under the read lock, requires vpci->lock to be acquired on both 
>> devices
>> +     * being compared, which may produce a deadlock. It is not possible to
>> +     * upgrade read lock to write lock in such a case. So, in order to 
>> prevent
>> +     * the deadlock, check which registers are going to be written and 
>> acquire
>> +     * the lock in the appropriate mode from the beginning.
>> +     */
>> +    if ( !vpci_offset_cmp(start, size, PCI_COMMAND, 2) )
>> +        return true;
>> +
>> +    if ( !vpci_offset_cmp(start, size, pdev->vpci->header.rom_reg, 4) )
>> +        return true;
>> +
>> +    return false;
>> +}
> A function of this name gives (especially at the call site(s)) the
> impression of acquiring a lock. Considering that of the prefixes
> neither "vpci" nor "header" are really relevant here, may I suggest
> to use need_write_lock()?
>
> May I further suggest that you either split the comment or combine
> the two if()-s (perhaps even straight into single return statement)?
> Personally I'd prefer the single return statement approach here ...
That was already questioned by Roger and now it looks like:

static bool overlap(unsigned int r1_offset, unsigned int r1_size,
                     unsigned int r2_offset, unsigned int r2_size)
{
     /* Return true if there is an overlap. */
     return r1_offset < r2_offset + r2_size && r2_offset < r1_offset + r1_size;
}

bool vpci_header_write_lock(const struct pci_dev *pdev,
                             unsigned int start, unsigned int size)
{
     /*
      * Writing the command register and ROM BAR register may trigger
      * modify_bars to run which in turn may access multiple pdevs while
      * checking for the existing BAR's overlap. The overlapping check, if done
      * under the read lock, requires vpci->lock to be acquired on both devices
      * being compared, which may produce a deadlock. It is not possible to
      * upgrade read lock to write lock in such a case. So, in order to prevent
      * the deadlock, check which registers are going to be written and acquire
      * the lock in the appropriate mode from the beginning.
      */
     if ( overlap(start, size, PCI_COMMAND, 2) ||
          (pdev->vpci->header.rom_reg &&
           overlap(start, size, pdev->vpci->header.rom_reg, 4)) )
         return true;

     return false;
}

vpci_header_write_lock moved to header.c and is not static anymore.
So, sitting in header.c, the name seems to be appropriate now
>
> Jan
>
Thank you,
Oleksandr

 


Rackspace

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