On Thu, Jul 31, 2014 at 11:56 PM, Edward Cree <ecree@xxxxxxxxxxxxxx> wrote:
> On 31/07/14 16:21, Alexander Duyck wrote:
>> However if you are wanting to use this as a way to disable SR-IOV for a
>> device I wouldn't recommend it. Based on what you have described I
>> would suggest dropping the fix in drivers/pci/quirks that would clear
>> dev->is_physfn if you are in the PF-IOV mode. That way the SR-IOV
>> functionality should be fully disabled.
> I still don't see how this can go in drivers/pci/quirks, because PF-IOV
> mode can only be detected at driver probe time. The way we find out
> that the NIC is in PF-IOV mode is that a request to the MC (the
> Management CPU on the card) to create a vswitch fails. But maybe I'm
> wrong about what quirks can do - is there any relevant documentation?
>
> Clearing dev->is_physfn in the driver probe routine isn't safe:
> dev->sriov memory can get leaked, for example, as sriov_init will get
> called at device add, but sriov_release won't be called at removal.
>
I think this memory leak bug doesn't exist.
The dev->sriov memory was allocated when pci_device_add() called.
whenever devices
were hot-pluged into system or built-in devices were scanned while booting.
The memory of dev->sriov is to be freed by kobject->kobject_release() when
the device reference counter reaches zero when put_device() was called.
for hot-plug, that is pciehp_unconfigure_device()....etc. but not in
driver->remove().
put_device()
kobject_put()
kobject_release()
kobject_cleanup()
device_release()
dev->release(dev)
pci_release_dev()
pci_release_capabilities()
pci_iov_release()
sriov_release(dev);
kfree(dev->sriov);
Thanks,
Ethan
> I'm also unconvinced that having !(dev->is_physfn || dev->is_virtfn) is
> a valid state; but maybe I'm misunderstanding and "is_physfn" doesn't
> actually mean "is a physical function", but rather "has SR-IOV capability".
>> In addition this solution would
>> also resolve the fact that the driver wouldn't actually have to be
>> loaded for it to work so if someone were to load a driver that didn't
>> contain the fix they would be blocked from enabling SR-IOV as well.
> The current driver fails to probe the PF because it assumes the vswitch
> creation failure is fatal. There should never be a driver that knows it
> can live without the vswitch but doesn't know that that breaks SR-IOV.
>
> -Edward
> The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error, please notify the sender immediately and delete the message. Unless you are an addressee (or authorized to receive for an addressee), you may not use, copy or disclose to anyone this message or any information contained in this message. The unauthorized use, disclosure, copying or alteration of this message is strictly prohibited.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
