| 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
| ||
|
Message-ID: <c4abc3c8-941e-9003-1ab9-af87d624c8b2@ozlabs.ru>
Date: Wed, 9 Nov 2016 13:23:08 +1100
From: Alexey Kardashevskiy <aik@...abs.ru>
To: Kirti Wankhede <kwankhede@...dia.com>
Cc: Alex Williamson <alex.williamson@...hat.com>, pbonzini@...hat.com,
kraxel@...hat.com, cjia@...dia.com, qemu-devel@...gnu.org,
kvm@...r.kernel.org, kevin.tian@...el.com, jike.song@...el.com,
bjsdjshi@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v11 13/22] vfio: Introduce common function to add
capabilities
On 09/11/16 08:42, Alex Williamson wrote:
> On Wed, 9 Nov 2016 02:16:17 +0530
> Kirti Wankhede <kwankhede@...dia.com> wrote:
>
>> On 11/8/2016 12:59 PM, Alexey Kardashevskiy wrote:
>>> On 05/11/16 08:10, Kirti Wankhede wrote:
>>>> Vendor driver using mediated device framework should use
>>>> vfio_info_add_capability() to add capabilities.
>>>> Introduced this function to reduce code duplication in vendor drivers.
>>>>
>>>> Signed-off-by: Kirti Wankhede <kwankhede@...dia.com>
>>>> Signed-off-by: Neo Jia <cjia@...dia.com>
>>>> Change-Id: I6fca329fa2291f37a2c859d0bc97574d9e2ce1a6
>>>> ---
>>>> drivers/vfio/vfio.c | 60 +++++++++++++++++++++++++++++++++++++++++++++++++++-
>>>> include/linux/vfio.h | 3 +++
>>>> 2 files changed, 62 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
>>>> index 4ed1a6a247c6..9a03be0942a1 100644
>>>> --- a/drivers/vfio/vfio.c
>>>> +++ b/drivers/vfio/vfio.c
>>>> @@ -1797,8 +1797,66 @@ void vfio_info_cap_shift(struct vfio_info_cap *caps, size_t offset)
>>>> for (tmp = caps->buf; tmp->next; tmp = (void *)tmp + tmp->next - offset)
>>>> tmp->next += offset;
>>>> }
>>>> -EXPORT_SYMBOL_GPL(vfio_info_cap_shift);
>>>> +EXPORT_SYMBOL(vfio_info_cap_shift);
>>>
>>>
>>> Why this change?
>>>
>>>
>>
>> We want this symbol to be available to all drivers.
>
> IOW, from proprietary drivers. It makes me uncomfortable how many
> non-GPL symbols we're adding (or converting) in this effort, but I'm
> trying to look objectively at every export as to whether a non-GPL
> caller of the function is legitimately separate from in-kernel code.
> For instance are they making use of data structures intrinsic to GPL'd
> code. In this case we're converting a symbol that's just manipulating
> a data buffer to add an offset to each element in a chain. The entries
> are documented in a uapi header. Kirti asked me about this one, and I
> couldn't find any basis to raise an objection. If you spot any reason
> that any of the export symbols in these series really should be GPL,
> please raise the issue.
>
>>>>
>>>> +static int sparse_mmap_cap(struct vfio_info_cap *caps, void *cap_type)
>>>> +{
>>>> + struct vfio_info_cap_header *header;
>>>> + struct vfio_region_info_cap_sparse_mmap *sparse_cap, *sparse = cap_type;
>>>> + size_t size;
>>>> +
>>>> + size = sizeof(*sparse) + sparse->nr_areas * sizeof(*sparse->areas);
>>>> + header = vfio_info_cap_add(caps, size,
>>>> + VFIO_REGION_INFO_CAP_SPARSE_MMAP, 1);
>>>> + if (IS_ERR(header))
>>>> + return PTR_ERR(header);
>>>> +
>>>> + sparse_cap = container_of(header,
>>>> + struct vfio_region_info_cap_sparse_mmap, header);
>>>> + sparse_cap->nr_areas = sparse->nr_areas;
>>>> + memcpy(sparse_cap->areas, sparse->areas,
>>>> + sparse->nr_areas * sizeof(*sparse->areas));
>>>> + return 0;
>>>> +}
>>>> +
>>>> +static int region_type_cap(struct vfio_info_cap *caps, void *cap_type)
>>>> +{
>>>> + struct vfio_info_cap_header *header;
>>>> + struct vfio_region_info_cap_type *type_cap, *cap = cap_type;
>>>> +
>>>> + header = vfio_info_cap_add(caps, sizeof(*cap),
>>>> + VFIO_REGION_INFO_CAP_TYPE, 1);
>>>> + if (IS_ERR(header))
>>>> + return PTR_ERR(header);
>>>> +
>>>> + type_cap = container_of(header, struct vfio_region_info_cap_type,
>>>> + header);
>>>> + type_cap->type = cap->type;
>>>> + type_cap->subtype = cap->subtype;
>>>> + return 0;
>>>> +}
>>>> +
>>>> +int vfio_info_add_capability(struct vfio_info_cap *caps, int cap_type_id,
>>>> + void *cap_type)
>>>> +{
>>>> + int ret = -EINVAL;
>>>> +
>>>> + if (!cap_type)
>>>> + return 0;
>>>> +
>>>> + switch (cap_type_id) {
>>>> + case VFIO_REGION_INFO_CAP_SPARSE_MMAP:
>>>> + ret = sparse_mmap_cap(caps, cap_type);
>>>> + break;
>>>> +
>>>> + case VFIO_REGION_INFO_CAP_TYPE:
>>>> + ret = region_type_cap(caps, cap_type);
>>>> + break;
>>>> + }
>>>> +
>>>> + return ret;
>>>> +}
>>>> +EXPORT_SYMBOL(vfio_info_add_capability);
>>>>
>>>> /*
>>>> * Pin a set of guest PFNs and return their associated host PFNs for local
>>>> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
>>>> index dcda8fccefab..cf90393a11e2 100644
>>>> --- a/include/linux/vfio.h
>>>> +++ b/include/linux/vfio.h
>>>> @@ -113,6 +113,9 @@ extern struct vfio_info_cap_header *vfio_info_cap_add(
>>>> struct vfio_info_cap *caps, size_t size, u16 id, u16 version);
>>>> extern void vfio_info_cap_shift(struct vfio_info_cap *caps, size_t offset);
>>>>
>>>> +extern int vfio_info_add_capability(struct vfio_info_cap *caps,
>>>> + int cap_type_id, void *cap_type);
>>>> +
>>>
>>>
>>> It would make it easier to review and bisect if 14/22 was squashed into
>>> this one.
>>
>> This was split based on Alex's suggestion on earlier version of this
>> patchset.
This could have been mentioned in changelog...
>
> Yeah, generally squashing patches together is the opposite of what we
> want for review and bisect.
13/22 adds a helper which is not used in it so if there is an error, it
won't be caught by bisecting, bisect will incorrectly point to 14/22.
Also, since the new helper in 13/22 is made from chunks removed in 14/22,
I'd like to see both changes in one patch to make sure that nothing was
lost during cut-n-paste. Especially when it is not just 2 patches, like 3
patches later in the series.
imho splitting like this only makes sense (or, rather, just make life
easier) when patches go via different maintainers trees.
However, since Alex is happy, you can ignore me.
> In this case the symbol exports should
> avoid any defined-but-unused warnings. Thanks,
>
> Alex
>
--
Alexey
Powered by blists - more mailing lists