[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zco2pmQWR49V9Imw@kbusch-mbp.mynextlight.net>
Date: Mon, 12 Feb 2024 08:17:58 -0700
From: Keith Busch <kbusch@...nel.org>
To: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@...ux.intel.com>
Cc: Jim Harris <jim.harris@...sung.com>,
Bjorn Helgaas <bhelgaas@...gle.com>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Leon Romanovsky <leonro@...dia.com>,
Jason Gunthorpe <jgg@...dia.com>,
Alex Williamson <alex.williamson@...hat.com>,
"pierre.cregut@...nge.com" <pierre.cregut@...nge.com>
Subject: Re: [PATCH v2 2/2] pci/iov: fix kobject_uevent() ordering in
sriov_enable()
On Fri, Feb 09, 2024 at 07:22:17PM -0800, Kuppuswamy Sathyanarayanan wrote:
> On 2/9/24 3:52 PM, Jim Harris wrote:
> > @@ -677,8 +677,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);
Since it's accessed unlocked now, I *think* this wants appropriate
barriers to ensure the order is observed the same on all CPUs. Something
like 'smp_store_release(&iov->num_VFs, nr_virtfn)' for writing it, and
use 'smp_load_acquire()' on the read-side.
Powered by blists - more mailing lists