linux-kernel - Re: [PATCH 9/9] vfio/pci: export igd support into vendor vfio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 10 Mar 2021 08:31:27 -0400
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Christoph Hellwig <hch@....de>
Cc:     Max Gurtovoy <mgurtovoy@...dia.com>, alex.williamson@...hat.com,
        cohuck@...hat.com, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org, liranl@...dia.com, oren@...dia.com,
        tzahio@...dia.com, leonro@...dia.com, yarong@...dia.com,
        aviadye@...dia.com, shahafs@...dia.com, artemp@...dia.com,
        kwankhede@...dia.com, ACurrid@...dia.com, cjia@...dia.com,
        yishaih@...dia.com, mjrosato@...ux.ibm.com, aik@...abs.ru
Subject: Re: [PATCH 9/9] vfio/pci: export igd support into vendor vfio_pci
 driver

On Wed, Mar 10, 2021 at 09:15:08AM +0100, Christoph Hellwig wrote:
> > +		vfio_pci_vf_token_user_add(vdev, -1);
> > +		vfio_pci_core_spapr_eeh_release(vdev);
> > +		vfio_pci_core_disable(vdev);
> > +	}
> > +	mutex_unlock(&vdev->reflck->lock);
> 
> But more importantly all this code should be in a helper exported
> from the core code.

Yes, that needs more refactoring. I'm viewing this series as a
"statement of intent" and once we commit to doing this we can go
through the bigger effort to split up vfio_pci_core and tidy its API.

Obviously this is a big project, given the past comments I don't want
to send more effort here until we see a community consensus emerge
that this is what we want to do. If we build a sub-driver instead the
work is all in the trash bin.

> > +	module_put(THIS_MODULE);
> 
> This looks bogus - the module reference is now gone while
> igd_vfio_pci_release is still running.  Module refcounting always
> need to be done by the caller, not the individual driver.

Yes, this module handling in vfio should be in the core code linked to
the core fops driven by the vfio_driver_ops.

It is on my list to add to my other series, this isn't the only place
in VFIO drivers are doing this..

> > +	case PCI_VENDOR_ID_INTEL:
> > +		if (pdev->class == PCI_CLASS_DISPLAY_VGA << 8)
> > +			return get_igd_vfio_pci_driver(pdev);
> 
> And this now means that the core code has a dependency on the igd
> one, making the whole split rather pointless.

Yes, if CONFIG_VFIO_PCI_DRIVER_COMPAT is set - this is a uAPI so we
don't want to see it broken. The intention is to organize the software
layers differently, not to decouple the two modules.

Future things, like the mlx5 driver that is coming, will not use this
COMPAT path at all.

Jason