Wait to call kobject_uevent() until all of the associated changes are done,
including updating the num_VFs value.
Suggested by: Leon Romanovsky <[email protected]>
Signed-off-by: Jim Harris <[email protected]>
---
drivers/pci/iov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
index 25dbe85c4217..3b768e20c7ab 100644
--- a/drivers/pci/iov.c
+++ b/drivers/pci/iov.c
@@ -683,8 +683,8 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn)
if (rc)
goto err_pcibios;
- kobject_uevent(&dev->dev.kobj, KOBJ_CHANGE);
iov->num_VFs = nr_virtfn;
+ kobject_uevent(&dev->dev.kobj, KOBJ_CHANGE);
return 0;
On Wed, Dec 13, 2023 at 06:58:28PM +0000, Jim Harris wrote:
> Wait to call kobject_uevent() until all of the associated changes are done,
> including updating the num_VFs value.
This seems right to me. Can we add a little rationale to the commit
log? E.g., something about how num_VFs is visible to userspace via
sysfs and we don't want a race between (a) userspace reading num_VFs
because of KOBJ_CHANGE and (b) the kernel updating num_VFs? (If
that's the actual reason.)
If there's a problem report about this, include that reference as
well.
> Suggested by: Leon Romanovsky <[email protected]>
> Signed-off-by: Jim Harris <[email protected]>
> ---
> drivers/pci/iov.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> index 25dbe85c4217..3b768e20c7ab 100644
> --- a/drivers/pci/iov.c
> +++ b/drivers/pci/iov.c
> @@ -683,8 +683,8 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn)
> if (rc)
> goto err_pcibios;
>
> - kobject_uevent(&dev->dev.kobj, KOBJ_CHANGE);
> iov->num_VFs = nr_virtfn;
> + kobject_uevent(&dev->dev.kobj, KOBJ_CHANGE);
>
> return 0;
>
>
On Wed, Dec 13, 2023 at 01:26:52PM -0600, Bjorn Helgaas wrote:
> On Wed, Dec 13, 2023 at 06:58:28PM +0000, Jim Harris wrote:
> > Wait to call kobject_uevent() until all of the associated changes are done,
> > including updating the num_VFs value.
>
> This seems right to me. Can we add a little rationale to the commit
> log? E.g., something about how num_VFs is visible to userspace via
> sysfs and we don't want a race between (a) userspace reading num_VFs
> because of KOBJ_CHANGE and (b) the kernel updating num_VFs? (If
> that's the actual reason.)
>
> If there's a problem report about this, include that reference as
> well.
There's a second patch that I haven't pushed yet that has more of the
rationale that led to this suggestion from Leon - see thread
"Locking between vfio hot-remove..." I'll push the two patches as a series.
The second patch will effectively revert 35ff867b7, since Leon felt the
reasoning behind that patch was incorrect. I'll tie all of that into the
cover letter.
-Jim
>
> > Suggested by: Leon Romanovsky <[email protected]>
> > Signed-off-by: Jim Harris <[email protected]>
> > ---
> > drivers/pci/iov.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/iov.c b/drivers/pci/iov.c
> > index 25dbe85c4217..3b768e20c7ab 100644
> > --- a/drivers/pci/iov.c
> > +++ b/drivers/pci/iov.c
> > @@ -683,8 +683,8 @@ static int sriov_enable(struct pci_dev *dev, int nr_virtfn)
> > if (rc)
> > goto err_pcibios;
> >
> > - kobject_uevent(&dev->dev.kobj, KOBJ_CHANGE);
> > iov->num_VFs = nr_virtfn;
> > + kobject_uevent(&dev->dev.kobj, KOBJ_CHANGE);
> >
> > return 0;
> >
> >