linux-kernel - Re: [PATCH] virtio_pci: support enabling VFs

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]

Message-ID: <5063D90B-7955-4F1E-85A2-D8AFD661ACB7@intel.com>
Date:   Wed, 30 May 2018 17:11:37 +0000
From:   "Rustad, Mark D" <mark.d.rustad@...el.com>
To:     "Duyck, Alexander H" <alexander.h.duyck@...el.com>
CC:     "mst@...hat.com" <mst@...hat.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "virtualization@...ts.linux-foundation.org" 
        <virtualization@...ts.linux-foundation.org>,
        "virtio-dev@...ts.oasis-open.org" <virtio-dev@...ts.oasis-open.org>,
        "Daly, Dan" <dan.daly@...el.com>,
        "Bie, Tiwei" <tiwei.bie@...el.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "Liang, Cunming" <cunming.liang@...el.com>,
        "Wang, Zhihong" <zhihong.wang@...el.com>
Subject: Re: [PATCH] virtio_pci: support enabling VFs

On May 30, 2018, at 9:54 AM, Duyck, Alexander H  
<alexander.h.duyck@...el.com> wrote:

> On Wed, 2018-05-30 at 09:44 -0700, Rustad, Mark D wrote:
>> On May 30, 2018, at 9:22 AM, Michael S. Tsirkin <mst@...hat.com> wrote:
>>
>>>> +static int virtio_pci_sriov_configure(struct pci_dev *pci_dev, int
>>>> num_vfs)
>>>> +{
>>>> +	struct virtio_pci_device *vp_dev = pci_get_drvdata(pci_dev);
>>>> +	struct virtio_device *vdev = &vp_dev->vdev;
>>>> +	int (*sriov_configure)(struct pci_dev *pci_dev, int num_vfs);
>>>> +
>>>> +	if (!(vdev->config->get_status(vdev) & VIRTIO_CONFIG_S_DRIVER_OK))
>>>> +		return -EBUSY;
>>>> +
>>>> +	if (!__virtio_test_bit(vdev, VIRTIO_F_SR_IOV))
>>>> +		return -EINVAL;
>>>> +
>>>> +	sriov_configure = pci_sriov_configure_simple;
>>>> +	if (sriov_configure == NULL)
>>>> +		return -ENOENT;
>>>
>>> BTW what is all this trickery in aid of?
>>
>> When SR-IOV support is not compiled into the kernel,
>> pci_sriov_configure_simple is #defined as NULL. This allows it to compile
>> in that case, even though there is utterly no way for it to be called in
>> that case. It is an alternative to #ifs in the code.
>
> Why even have the call though? I would wrap all of this in an #ifdef
> and strip it out since you couldn't support SR-IOV if it isn't present
> in the kernel anyway.

I am inclined to agree. In this case, the presence of #ifdefs I think would  
be clearer. As written, someone will want to get rid of the pointer only to  
create a build problem when SR-IOV is not configured.

--
Mark Rustad, Networking Division, Intel Corporation

Download attachment "signature.asc" of type "application/pgp-signature" (874 bytes)