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 <leonro@xxxxxxxxxx> > > Signed-off-by: Jim Harris <jim.harris@xxxxxxxxxxx> > > --- > > 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; > > > >
