All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Liu <wei.liu2@citrix.com>
To: Roger Pau Monne <roger.pau@citrix.com>
Cc: Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Ian Jackson <ian.jackson@eu.citrix.com>, Tim Deegan <tim@xen.org>,
	Julien Grall <julien.grall@arm.com>,
	Jan Beulich <jbeulich@suse.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH 01/10] vpci: move lock
Date: Fri, 29 Jun 2018 11:19:57 +0100	[thread overview]
Message-ID: <20180629101957.4uwf3pisdvxtwxtu@citrix.com> (raw)
In-Reply-To: <20180620144234.51783-2-roger.pau@citrix.com>

On Wed, Jun 20, 2018 at 04:42:25PM +0200, Roger Pau Monne wrote:
> To the outside of the vpci struct. This way the lock can be used to
> check whether vpci is present, and removal can be performed while
> holding the lock, in order to make sure there are no accesses to the
> contents of the vpci struct. Previously removal could race with
> vpci_read for example, since the log was dropped prior to freeing

log -> lock.

> pdev->vpci.
> 
> Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
[...]
> diff --git a/xen/drivers/vpci/header.c b/xen/drivers/vpci/header.c
> index 0ec4c082a6..9d5607d5f8 100644
> --- a/xen/drivers/vpci/header.c
> +++ b/xen/drivers/vpci/header.c
> @@ -131,11 +131,12 @@ bool vpci_process_pending(struct vcpu *v)
>          if ( rc == -ERESTART )
>              return true;
>  
> -        spin_lock(&v->vpci.pdev->vpci->lock);
> -        /* Disable memory decoding unconditionally on failure. */
> -        modify_decoding(v->vpci.pdev, !rc && v->vpci.map,
> -                        !rc && v->vpci.rom_only);
> -        spin_unlock(&v->vpci.pdev->vpci->lock);
> +        spin_lock(&v->vpci.pdev->vpci_lock);
> +        if ( v->vpci.pdev->vpci )

The purpose of this check is to fix a latent bug in the original code?

> +            /* Disable memory decoding unconditionally on failure. */
> +            modify_decoding(v->vpci.pdev, !rc && v->vpci.map,
> +                            !rc && v->vpci.rom_only);
> +        spin_unlock(&v->vpci.pdev->vpci_lock);
>  
[...]
> diff --git a/xen/drivers/vpci/vpci.c b/xen/drivers/vpci/vpci.c
> index 82607bdb9a..7d52bcf8d0 100644
> --- a/xen/drivers/vpci/vpci.c
> +++ b/xen/drivers/vpci/vpci.c
> @@ -35,9 +35,8 @@ extern vpci_register_init_t *const __start_vpci_array[];
>  extern vpci_register_init_t *const __end_vpci_array[];
>  #define NUM_VPCI_INIT (__end_vpci_array - __start_vpci_array)
>  
> -void vpci_remove_device(struct pci_dev *pdev)
> +static void vpci_remove_device_locked(struct pci_dev *pdev)
>  {
> -    spin_lock(&pdev->vpci->lock);

ASSERT(spin_is_locked(&pdev->vpci_lock));

>      while ( !list_empty(&pdev->vpci->handlers) )
>      {
>          struct vpci_register *r = list_first_entry(&pdev->vpci->handlers,
> @@ -47,13 +46,20 @@ void vpci_remove_device(struct pci_dev *pdev)
>          list_del(&r->node);
>          xfree(r);
>      }
> -    spin_unlock(&pdev->vpci->lock);
>      xfree(pdev->vpci->msix);
>      xfree(pdev->vpci->msi);
>      xfree(pdev->vpci);
>      pdev->vpci = NULL;
>  }
>  
> +void vpci_remove_device(struct pci_dev *pdev)
> +{
> +    spin_lock(&pdev->vpci_lock);
> +    vpci_remove_device_locked(pdev);
> +    spin_unlock(&pdev->vpci_lock);
> +}
> +
> +

Too many blank lines.

>  int __hwdom_init vpci_add_handlers(struct pci_dev *pdev)
>  {
>      unsigned int i;
> @@ -62,12 +68,15 @@ int __hwdom_init vpci_add_handlers(struct pci_dev *pdev)
>      if ( !has_vpci(pdev->domain) )
>          return 0;
>  
> +    spin_lock(&pdev->vpci_lock);
>      pdev->vpci = xzalloc(struct vpci);
>      if ( !pdev->vpci )
> +    {
> +        spin_unlock(&pdev->vpci_lock);
>          return -ENOMEM;
> +    }
>  
>      INIT_LIST_HEAD(&pdev->vpci->handlers);
> -    spin_lock_init(&pdev->vpci->lock);
>  
>      for ( i = 0; i < NUM_VPCI_INIT; i++ )
>      {
[...]
> @@ -77,7 +86,8 @@ int __hwdom_init vpci_add_handlers(struct pci_dev *pdev)
> @@ -315,7 +318,7 @@ static uint32_t merge_result(uint32_t data, uint32_t new, unsigned int size,
>  uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>  {
>      const struct domain *d = current->domain;
> -    const struct pci_dev *pdev;
> +    struct pci_dev *pdev;
>      const struct vpci_register *r;
>      unsigned int data_offset = 0;
>      uint32_t data = ~(uint32_t)0;
> @@ -331,7 +334,12 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>      if ( !pdev )
>          return vpci_read_hw(sbdf, reg, size);
>  
> -    spin_lock(&pdev->vpci->lock);
> +    spin_lock(&pdev->vpci_lock);
> +    if ( !pdev->vpci )
> +    {
> +        spin_unlock(&pdev->vpci_lock);
> +        return vpci_read_hw(sbdf, reg, size);
> +    }
>  
>      /* Read from the hardware or the emulated register handlers. */
>      list_for_each_entry ( r, &pdev->vpci->handlers, node )
> @@ -383,7 +391,7 @@ uint32_t vpci_read(pci_sbdf_t sbdf, unsigned int reg, unsigned int size)
>  
>          data = merge_result(data, tmp_data, size - data_offset, data_offset);
>      }
> -    spin_unlock(&pdev->vpci->lock);
> +    spin_unlock(&pdev->vpci_lock);

I think the critical section in this function and the write function can
shrink a bit. Reading from / writing to hardware shouldn't need to be
protected by vpci_lock.

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

  reply	other threads:[~2018-06-29 10:20 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-20 14:42 [PATCH 00/10] vpci: add support for SR-IOV capability Roger Pau Monne
2018-06-20 14:42 ` [PATCH 01/10] vpci: move lock Roger Pau Monne
2018-06-29 10:19   ` Wei Liu [this message]
2018-06-29 13:27     ` Roger Pau Monné
2018-06-29 13:37       ` Julien Grall
2021-11-23 12:20   ` Oleksandr Andrushchenko
2018-06-20 14:42 ` [PATCH 02/10] vpci/msix: add lock to protect the list of MSIX regions Roger Pau Monne
2018-06-29 10:29   ` Wei Liu
2018-06-20 14:42 ` [PATCH 03/10] vpci: add tear down functions Roger Pau Monne
2018-06-29 10:37   ` Wei Liu
2018-07-02  7:52     ` Roger Pau Monné
2018-06-20 14:42 ` [PATCH 04/10] vpci/msix: add teardown cleanup Roger Pau Monne
2018-06-29 10:52   ` Wei Liu
2018-07-02  7:54     ` Roger Pau Monné
2018-07-02 13:55       ` Wei Liu
2018-07-02 14:02         ` Roger Pau Monné
2018-07-02 14:07           ` Wei Liu
2018-07-02 14:12             ` Roger Pau Monné
2018-06-20 14:42 ` [PATCH 05/10] vpci/msi: " Roger Pau Monne
2018-06-29 10:52   ` Wei Liu
2018-07-02  7:55     ` Roger Pau Monné
2018-06-20 14:42 ` [PATCH 06/10] vpci/header: " Roger Pau Monne
2018-06-29 11:15   ` Wei Liu
2018-07-02  8:04     ` Roger Pau Monné
2018-07-02 14:30       ` Wei Liu
2018-07-02 14:42         ` Roger Pau Monné
2018-06-20 14:42 ` [PATCH 07/10] rangeset: introduce rangeset_merge Roger Pau Monne
2018-06-29 11:23   ` Wei Liu
2018-06-20 14:42 ` [PATCH 08/10] vpci/header: allow multiple map operations Roger Pau Monne
2018-06-29 14:44   ` Wei Liu
2018-06-20 14:42 ` [PATCH 09/10] pci: add vpci hooks for device addition/removal Roger Pau Monne
2018-06-29 14:50   ` Wei Liu
2018-06-20 14:42 ` [PATCH 10/10] vpci/sriov: add support for SR-IOV capability Roger Pau Monne
2018-06-29 15:27   ` Wei Liu
2018-07-02  8:12     ` Roger Pau Monné
2018-07-03  9:27   ` Wei Liu
2018-07-03 10:21     ` Roger Pau Monné
2018-07-03 10:48       ` Jan Beulich
2018-07-03 10:51         ` Roger Pau Monné
2018-07-03 10:56           ` Jan Beulich
2018-07-03 11:07             ` Roger Pau Monné
2018-07-03 11:47               ` Jan Beulich
2018-07-03 10:54       ` Wei Liu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180629101957.4uwf3pisdvxtwxtu@citrix.com \
    --to=wei.liu2@citrix.com \
    --cc=George.Dunlap@eu.citrix.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien.grall@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.