From: Alex Williamson <alex.williamson@redhat.com>
To: Alexey Kardashevskiy <aik@ozlabs.ru>
Cc: Kirti Wankhede <kwankhede@nvidia.com>,
pbonzini@redhat.com, kraxel@redhat.com, cjia@nvidia.com,
qemu-devel@nongnu.org, kvm@vger.kernel.org, kevin.tian@intel.com,
jike.song@intel.com, bjsdjshi@linux.vnet.ibm.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v11 15/22] vfio: Introduce vfio_set_irqs_validate_and_prepare()
Date: Tue, 8 Nov 2016 20:35:00 -0700 [thread overview]
Message-ID: <20161108203500.526244d6@t450s.home> (raw)
In-Reply-To: <26a4171a-e68f-c8e5-af39-b5af2c1645fe@ozlabs.ru>
On Wed, 9 Nov 2016 14:07:58 +1100
Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 09/11/16 07:22, Kirti Wankhede wrote:
> > On 11/8/2016 2:16 PM, Alexey Kardashevskiy wrote:
> >> On 05/11/16 08:10, Kirti Wankhede wrote:
> >>> Vendor driver using mediated device framework would use same mechnism to
> >>> validate and prepare IRQs. Introducing this function to reduce code
> >>> replication in multiple drivers.
> >>>
> >>> Signed-off-by: Kirti Wankhede <kwankhede@nvidia.com>
> >>> Signed-off-by: Neo Jia <cjia@nvidia.com>
> >>> Change-Id: Ie201f269dda0713ca18a07dc4852500bd8b48309
> >>> ---
> >>> drivers/vfio/vfio.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++++
> >>> include/linux/vfio.h | 4 ++++
> >>> 2 files changed, 52 insertions(+)
> >>>
> >>> diff --git a/drivers/vfio/vfio.c b/drivers/vfio/vfio.c
> >>> index 9a03be0942a1..ed2361e4b904 100644
> >>> --- a/drivers/vfio/vfio.c
> >>> +++ b/drivers/vfio/vfio.c
> >>> @@ -1858,6 +1858,54 @@ int vfio_info_add_capability(struct vfio_info_cap *caps, int cap_type_id,
> >>> }
> >>> EXPORT_SYMBOL(vfio_info_add_capability);
> >>>
> >>> +int vfio_set_irqs_validate_and_prepare(struct vfio_irq_set *hdr, int num_irqs,
> >>> + int max_irq_type, size_t *data_size)
> >>> +{
> >>> + unsigned long minsz;
> >>> + size_t size;
> >>> +
> >>> + minsz = offsetofend(struct vfio_irq_set, count);
> >>> +
> >>> + if ((hdr->argsz < minsz) || (hdr->index >= max_irq_type) ||
> >>> + (hdr->count >= (U32_MAX - hdr->start)) ||
> >>> + (hdr->flags & ~(VFIO_IRQ_SET_DATA_TYPE_MASK |
> >>> + VFIO_IRQ_SET_ACTION_TYPE_MASK)))
> >>> + return -EINVAL;
> >>> +
> >>> + if (data_size)
> >>
> >> Pointless check, the callers will pass non null pointer with value
> >> initialized to 0 anyway.
> >>
> >
> > Not always, When VFIO_IRQ_SET_DATA_NONE flag is set, caller can pass
> > data_size = NULL.
>
>
> Today data_size is not NULL in all cases and the way it is used now (ioctl
> VFIO_DEVICE_SET_IRQS) gives me an idea that this is not going to change.
>
> >
> >>
> >>> + *data_size = 0;
> >>> +
> >>> + if (hdr->start >= num_irqs || hdr->start + hdr->count > num_irqs)
> >>> + return -EINVAL;
> >>> +
> >>> + switch (hdr->flags & VFIO_IRQ_SET_DATA_TYPE_MASK) {
> >>> + case VFIO_IRQ_SET_DATA_NONE:
> >>> + size = 0;
> >>> + break;
> >>> + case VFIO_IRQ_SET_DATA_BOOL:
> >>> + size = sizeof(uint8_t);
> >>> + break;
> >>> + case VFIO_IRQ_SET_DATA_EVENTFD:
> >>> + size = sizeof(int32_t);
> >>> + break;
> >>> + default:
> >>> + return -EINVAL;
> >>> + }
> >>> +
> >>> + if (size) {
> >>
> >> The whole branch would even work for size == 0.
> >>
> >
> > In that case below check (!data_size) might result in error if data_size
> > == NULL, whereas its not error case when size == 0, i.e.
> > VFIO_IRQ_SET_DATA_NONE flag set.
> >
> >>> + if (hdr->argsz - minsz < hdr->count * size)
> >>> + return -EINVAL;
> >>> +
> >>> + if (!data_size)
> >>> + return -EINVAL;
> >>
> >> Redundant check as well.
> >>
> >
> > This is not redundant. If you see above check, it sets its init value to
> > 0 but doesn't fail.
> >
> >>> +
> >>> + *data_size = hdr->count * size;
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>
> >> It does not really prepare anything as the name suggests. It looks like
> >> this is 2 different helpers actually:
> >>
> >> int vfio_set_irqs_validate()
> >> and
> >> size_t vfio_set_irqs_hdr_to_data_size()
> >>
> >
> > Later one is the prepare.
>
>
> Does not like it prepares anything, just a simple converter.
>
>
> >> And it would make it easier to review/bisect if 16/22 and 17/22 were merged
> >> into this one as this patch alone adds new code which it does not use and
> >> all 3 patches are fairly small.
> >>
> >
> > I do had all 3 patch merged in one in earlier version of patchset. This
> > is split as per Alex's suggestion.
>
> I got this from another mail from Alex. Which I find strange but whatever,
> this is his realm anyway :)
Maybe you haven't noticed, but your patch series are often difficult to
deal with, they almost always split across functional areas and
maintainers. Splitting out code to common functions and _then_
updating the callers to make use of it is a common way to deal with
that. We're in the same functional area here, but it's still
good practice. Thanks,
Alex
next prev parent reply other threads:[~2016-11-09 3:35 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-04 21:10 [PATCH v11 00/22] Add Mediated device support Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 01/22] vfio: Mediated device Core driver Kirti Wankhede
2016-11-07 6:40 ` Tian, Kevin
[not found] ` <20161108092552.GA2090@bjsdjshi@linux.vnet.ibm.com>
2016-11-08 21:06 ` Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 02/22] vfio: VFIO based driver for Mediated devices Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 03/22] vfio: Rearrange functions to get vfio_group from dev Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 04/22] vfio: Common function to increment container_users Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 05/22] vfio iommu: Added pin and unpin callback functions to vfio_iommu_driver_ops Kirti Wankhede
2016-11-07 19:36 ` Alex Williamson
2016-11-08 13:55 ` Kirti Wankhede
2016-11-08 16:39 ` Alex Williamson
2016-11-08 18:47 ` Kirti Wankhede
2016-11-08 19:14 ` Alex Williamson
2016-11-04 21:10 ` [PATCH v11 06/22] vfio iommu type1: Update arguments of vfio_lock_acct Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 07/22] vfio iommu type1: Update argument of vaddr_get_pfn() Kirti Wankhede
2016-11-07 8:42 ` Alexey Kardashevskiy
2016-11-04 21:10 ` [PATCH v11 08/22] vfio iommu type1: Add find_iommu_group() function Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 09/22] vfio iommu type1: Add task structure to vfio_dma Kirti Wankhede
2016-11-07 21:03 ` Alex Williamson
2016-11-08 14:13 ` Kirti Wankhede
2016-11-08 16:43 ` Alex Williamson
2016-11-04 21:10 ` [PATCH v11 10/22] vfio iommu type1: Add support for mediated devices Kirti Wankhede
2016-11-07 23:16 ` Alex Williamson
2016-11-08 2:20 ` Jike Song
2016-11-08 16:18 ` Alex Williamson
2016-11-08 15:06 ` Kirti Wankhede
2016-11-08 17:05 ` Alex Williamson
2016-11-08 6:52 ` Alexey Kardashevskiy
2016-11-15 5:17 ` Alexey Kardashevskiy
2016-11-15 6:33 ` Kirti Wankhede
2016-11-15 7:27 ` Alexey Kardashevskiy
2016-11-15 7:56 ` Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 11/22] vfio iommu: Add blocking notifier to notify DMA_UNMAP Kirti Wankhede
2016-11-07 23:45 ` Alex Williamson
2016-11-08 16:26 ` Kirti Wankhede
2016-11-08 17:46 ` Alex Williamson
2016-11-08 19:59 ` Kirti Wankhede
2016-11-08 21:28 ` Alex Williamson
2016-11-14 7:52 ` Kirti Wankhede
2016-11-14 15:37 ` Alex Williamson
2016-11-04 21:10 ` [PATCH v11 12/22] vfio: Add notifier callback to parent's ops structure of mdev Kirti Wankhede
2016-11-07 23:51 ` Alex Williamson
2016-11-04 21:10 ` [PATCH v11 13/22] vfio: Introduce common function to add capabilities Kirti Wankhede
2016-11-08 7:29 ` Alexey Kardashevskiy
2016-11-08 20:46 ` Kirti Wankhede
2016-11-08 21:42 ` Alex Williamson
2016-11-09 2:23 ` Alexey Kardashevskiy
2016-11-04 21:10 ` [PATCH v11 14/22] vfio_pci: Update vfio_pci to use vfio_info_add_capability() Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 15/22] vfio: Introduce vfio_set_irqs_validate_and_prepare() Kirti Wankhede
2016-11-08 8:46 ` Alexey Kardashevskiy
2016-11-08 20:22 ` Kirti Wankhede
2016-11-09 3:07 ` Alexey Kardashevskiy
2016-11-09 3:35 ` Alex Williamson [this message]
2016-11-04 21:10 ` [PATCH v11 16/22] vfio_pci: Updated to use vfio_set_irqs_validate_and_prepare() Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 17/22] vfio_platform: " Kirti Wankhede
2016-11-08 8:52 ` Alexey Kardashevskiy
2016-11-08 20:41 ` Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 18/22] vfio: Define device_api strings Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 19/22] docs: Add Documentation for Mediated devices Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 20/22] docs: Sysfs ABI for mediated device framework Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 21/22] docs: Sample driver to demonstrate how to use Mediated " Kirti Wankhede
2016-11-04 21:10 ` [PATCH v11 22/22] MAINTAINERS: Add entry VFIO based Mediated device drivers Kirti Wankhede
2016-11-07 3:30 ` [PATCH v11 00/22] Add Mediated device support Alexey Kardashevskiy
2016-11-07 3:59 ` Kirti Wankhede
2016-11-07 5:06 ` Kirti Wankhede
2016-11-07 6:15 ` Alexey Kardashevskiy
2016-11-07 6:36 ` Kirti Wankhede
2016-11-07 6:46 ` Alexey Kardashevskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161108203500.526244d6@t450s.home \
--to=alex.williamson@redhat.com \
--cc=aik@ozlabs.ru \
--cc=bjsdjshi@linux.vnet.ibm.com \
--cc=cjia@nvidia.com \
--cc=jike.song@intel.com \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kwankhede@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).