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

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


  • To: Oleksandr Andrushchenko <andr2000@xxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Mon, 14 Feb 2022 15:19:50 +0100
  • 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=eIBMFJoRrQzjeSs7y+hAQfYO83nR9GrxY26fC53/D28=; b=Bgws0JRM60BRWckvRs3OFkDGaJ2dxcZ+8iFj013fYowUkEODD1YwJBRqpybmGdcVvUoVuVGa9DmzMWNIvn8it1ynXhFSu9KuURBFxu0vNa4L0IFEAJL73DMHx+/ueWuEjTINUm8KupAB6iTcO0Jj4Ph+S4rP+DviXelHfrWjJoa5Uu60Fli4VJ4wH+MFGAL4ChNS2x0vdUlnRh3xLACEUqIs7Ae437rKs9u1QG0W1bTDC8+hwfEsH4HygA0ONsixLPb4L4kGFlT5WGLbdTlJ9+0QH+jVtgKQNFQ/7BZt77ckenuQ6vuDBEJ667EKZZiBVKWPY3p+Zu6SqLcCjptX6Q==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=D2Ehfshwq3BtVCmJ8yCWnjWYHMftAqpKvHfFdjnBortp2DuZBykvnnB5AiPFu5yGhfgTaFVOyuGFeuK4TWGzGkVpXkXCy+G6n5OrinPavYmMKrVSRbIurbKEQeyDvFRkTbXMPixE7LfPse3xhjoRE1+eisK1B2EkjFIDq9edcp1BCtYqL62iUqVBVg0YsoRwIpagvqtjRXMlM0Obhgalq+vCtSNB9ojk212VU4bCZYZ78Vh9Z3sfXS0dUFI8KsRaWiZsT/qdy98HjyRD3FlbyFQTNeCKzm+hj+A6ZELEqbeqc9wk2SYZkkRelfBkDawS7vHvnQTrbQJznV0vDahpfQ==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: roger.pau@xxxxxxxxxx, julien@xxxxxxx, sstabellini@xxxxxxxxxx, oleksandr_tyshchenko@xxxxxxxx, volodymyr_babchuk@xxxxxxxx, artem_mygaiev@xxxxxxxx, bertrand.marquis@xxxxxxx, rahul.singh@xxxxxxx, Oleksandr Andrushchenko <oleksandr_andrushchenko@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Mon, 14 Feb 2022 14:19:59 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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 ...

Jan




 


Rackspace

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