From: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
To: Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org,
geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org
Subject: Re: [PATCH v6 03/07] iommu/ipmmu-vmsa: Break out utlb parsing code
Date: Fri, 11 Nov 2016 03:00:33 +0200 [thread overview]
Message-ID: <3032720.BPnZvxWODA@avalon> (raw)
In-Reply-To: <20161019233603.10506.93030.sendpatchset@little-apple>
Hi Magnus,
Thank you for the patch.
On Thursday 20 Oct 2016 08:36:03 Magnus Damm wrote:
> From: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
>
> Break out the utlb parsing code and dev_data allocation into a
> separate function. This is preparation for future code sharing.
>
> Signed-off-by: Magnus Damm <damm+renesas-yzvPICuk2ACczHhG9Qg4qA@public.gmane.org>
> Reviewed-by: Joerg Roedel <jroedel-l3A5Bk7waGM@public.gmane.org>
> ---
>
> Changes since V5:
> - None
>
> Changes since V4:
> - Dropped hunk with fix to apply on top of:
> b1e2afc iommu/ipmmu-vmsa: Fix wrong error handle of ipmmu_add_device
>
> Changes since V3:
> - Initialize "mmu" to NULL, check before accessing
> - Removed group parameter from ipmmu_init_platform_device()
>
> Changes since V2:
> - Included this new patch from the following series:
> [PATCH 00/04] iommu/ipmmu-vmsa: IPMMU CONFIG_IOMMU_DMA update
> - Reworked code to fit on top on previous two patches in current series.
>
> drivers/iommu/ipmmu-vmsa.c | 58 ++++++++++++++++++++++++++---------------
> 1 file changed, 37 insertions(+), 21 deletions(-)
>
> --- 0006/drivers/iommu/ipmmu-vmsa.c
> +++ work/drivers/iommu/ipmmu-vmsa.c 2016-09-20 21:49:34.580607110 +0900
> @@ -647,22 +647,15 @@ static int ipmmu_find_utlbs(struct ipmmu
> return 0;
> }
>
> -static int ipmmu_add_device(struct device *dev)
> +static int ipmmu_init_platform_device(struct device *dev)
The device doesn't have to be a platform device, how about calling this
ipmmu_init_device_archdata() ?
> {
> struct ipmmu_vmsa_archdata *archdata;
> struct ipmmu_vmsa_device *mmu;
> - struct iommu_group *group = NULL;
> unsigned int *utlbs;
> unsigned int i;
> int num_utlbs;
> int ret = -ENODEV;
>
> - if (dev->archdata.iommu) {
> - dev_warn(dev, "IOMMU driver already assigned to device %s\n",
> - dev_name(dev));
> - return -EINVAL;
> - }
> -
> /* Find the master corresponding to the device. */
>
> num_utlbs = of_count_phandle_with_args(dev->of_node, "iommus",
> @@ -699,6 +692,36 @@ static int ipmmu_add_device(struct devic
> }
> }
>
> + archdata = kzalloc(sizeof(*archdata), GFP_KERNEL);
> + if (!archdata) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + archdata->mmu = mmu;
> + archdata->utlbs = utlbs;
> + archdata->num_utlbs = num_utlbs;
> + dev->archdata.iommu = archdata;
> + return 0;
> +
> +error:
> + kfree(utlbs);
> + return ret;
> +}
> +
> +static int ipmmu_add_device(struct device *dev)
> +{
> + struct ipmmu_vmsa_archdata *archdata;
> + struct ipmmu_vmsa_device *mmu = NULL;
> + struct iommu_group *group;
> + int ret;
> +
> + if (dev->archdata.iommu) {
> + dev_warn(dev, "IOMMU driver already assigned to device %s\n",
> + dev_name(dev));
> + return -EINVAL;
> + }
> +
> /* Create a device group and add the device to it. */
> group = iommu_group_alloc();
> if (IS_ERR(group)) {
> @@ -716,16 +739,9 @@ static int ipmmu_add_device(struct devic
> goto error;
> }
>
> - archdata = kzalloc(sizeof(*archdata), GFP_KERNEL);
> - if (!archdata) {
> - ret = -ENOMEM;
> + ret = ipmmu_init_platform_device(dev);
> + if (ret < 0)
> goto error;
> - }
> -
> - archdata->mmu = mmu;
> - archdata->utlbs = utlbs;
> - archdata->num_utlbs = num_utlbs;
> - dev->archdata.iommu = archdata;
>
> /*
> * Create the ARM mapping, used by the ARM DMA mapping core to
allocate
> @@ -736,6 +752,8 @@ static int ipmmu_add_device(struct devic
> * - Make the mapping size configurable ? We currently use a 2GB
mapping
> * at a 1GB offset to ensure that NULL VAs will fault.
> */
> + archdata = dev->archdata.iommu;
> + mmu = archdata->mmu;
> if (!mmu->mapping) {
> struct dma_iommu_mapping *mapping;
>
> @@ -760,10 +778,8 @@ static int ipmmu_add_device(struct devic
> return 0;
>
> error:
> - arm_iommu_release_mapping(mmu->mapping);
> -
> - kfree(dev->archdata.iommu);
> - kfree(utlbs);
> + if (mmu)
> + arm_iommu_release_mapping(mmu->mapping);
Looking at the surrounding code, shouldn't the mapping only be destroyed here
if it has been created by the same call to the function ? If there's an
existing mapping for the IPMMU instance and the arm_iommu_attach_device() call
fails, releasing the mapping seems to be a bug. As the bug isn't introduced by
this patch, we can fix it separately, but if you end up resubmitting due to
the first comment you could also add a fix.
>
> dev->archdata.iommu = NULL;
--
Regards,
Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Magnus Damm <magnus.damm@gmail.com>
Cc: iommu@lists.linux-foundation.org,
laurent.pinchart+renesas@ideasonboard.com,
geert+renesas@glider.be, joro@8bytes.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
horms+renesas@verge.net.au, robin.murphy@arm.com,
m.szyprowski@samsung.com
Subject: Re: [PATCH v6 03/07] iommu/ipmmu-vmsa: Break out utlb parsing code
Date: Fri, 11 Nov 2016 03:00:33 +0200 [thread overview]
Message-ID: <3032720.BPnZvxWODA@avalon> (raw)
In-Reply-To: <20161019233603.10506.93030.sendpatchset@little-apple>
Hi Magnus,
Thank you for the patch.
On Thursday 20 Oct 2016 08:36:03 Magnus Damm wrote:
> From: Magnus Damm <damm+renesas@opensource.se>
>
> Break out the utlb parsing code and dev_data allocation into a
> separate function. This is preparation for future code sharing.
>
> Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
> Reviewed-by: Joerg Roedel <jroedel@suse.de>
> ---
>
> Changes since V5:
> - None
>
> Changes since V4:
> - Dropped hunk with fix to apply on top of:
> b1e2afc iommu/ipmmu-vmsa: Fix wrong error handle of ipmmu_add_device
>
> Changes since V3:
> - Initialize "mmu" to NULL, check before accessing
> - Removed group parameter from ipmmu_init_platform_device()
>
> Changes since V2:
> - Included this new patch from the following series:
> [PATCH 00/04] iommu/ipmmu-vmsa: IPMMU CONFIG_IOMMU_DMA update
> - Reworked code to fit on top on previous two patches in current series.
>
> drivers/iommu/ipmmu-vmsa.c | 58 ++++++++++++++++++++++++++---------------
> 1 file changed, 37 insertions(+), 21 deletions(-)
>
> --- 0006/drivers/iommu/ipmmu-vmsa.c
> +++ work/drivers/iommu/ipmmu-vmsa.c 2016-09-20 21:49:34.580607110 +0900
> @@ -647,22 +647,15 @@ static int ipmmu_find_utlbs(struct ipmmu
> return 0;
> }
>
> -static int ipmmu_add_device(struct device *dev)
> +static int ipmmu_init_platform_device(struct device *dev)
The device doesn't have to be a platform device, how about calling this
ipmmu_init_device_archdata() ?
> {
> struct ipmmu_vmsa_archdata *archdata;
> struct ipmmu_vmsa_device *mmu;
> - struct iommu_group *group = NULL;
> unsigned int *utlbs;
> unsigned int i;
> int num_utlbs;
> int ret = -ENODEV;
>
> - if (dev->archdata.iommu) {
> - dev_warn(dev, "IOMMU driver already assigned to device %s\n",
> - dev_name(dev));
> - return -EINVAL;
> - }
> -
> /* Find the master corresponding to the device. */
>
> num_utlbs = of_count_phandle_with_args(dev->of_node, "iommus",
> @@ -699,6 +692,36 @@ static int ipmmu_add_device(struct devic
> }
> }
>
> + archdata = kzalloc(sizeof(*archdata), GFP_KERNEL);
> + if (!archdata) {
> + ret = -ENOMEM;
> + goto error;
> + }
> +
> + archdata->mmu = mmu;
> + archdata->utlbs = utlbs;
> + archdata->num_utlbs = num_utlbs;
> + dev->archdata.iommu = archdata;
> + return 0;
> +
> +error:
> + kfree(utlbs);
> + return ret;
> +}
> +
> +static int ipmmu_add_device(struct device *dev)
> +{
> + struct ipmmu_vmsa_archdata *archdata;
> + struct ipmmu_vmsa_device *mmu = NULL;
> + struct iommu_group *group;
> + int ret;
> +
> + if (dev->archdata.iommu) {
> + dev_warn(dev, "IOMMU driver already assigned to device %s\n",
> + dev_name(dev));
> + return -EINVAL;
> + }
> +
> /* Create a device group and add the device to it. */
> group = iommu_group_alloc();
> if (IS_ERR(group)) {
> @@ -716,16 +739,9 @@ static int ipmmu_add_device(struct devic
> goto error;
> }
>
> - archdata = kzalloc(sizeof(*archdata), GFP_KERNEL);
> - if (!archdata) {
> - ret = -ENOMEM;
> + ret = ipmmu_init_platform_device(dev);
> + if (ret < 0)
> goto error;
> - }
> -
> - archdata->mmu = mmu;
> - archdata->utlbs = utlbs;
> - archdata->num_utlbs = num_utlbs;
> - dev->archdata.iommu = archdata;
>
> /*
> * Create the ARM mapping, used by the ARM DMA mapping core to
allocate
> @@ -736,6 +752,8 @@ static int ipmmu_add_device(struct devic
> * - Make the mapping size configurable ? We currently use a 2GB
mapping
> * at a 1GB offset to ensure that NULL VAs will fault.
> */
> + archdata = dev->archdata.iommu;
> + mmu = archdata->mmu;
> if (!mmu->mapping) {
> struct dma_iommu_mapping *mapping;
>
> @@ -760,10 +778,8 @@ static int ipmmu_add_device(struct devic
> return 0;
>
> error:
> - arm_iommu_release_mapping(mmu->mapping);
> -
> - kfree(dev->archdata.iommu);
> - kfree(utlbs);
> + if (mmu)
> + arm_iommu_release_mapping(mmu->mapping);
Looking at the surrounding code, shouldn't the mapping only be destroyed here
if it has been created by the same call to the function ? If there's an
existing mapping for the IPMMU instance and the arm_iommu_attach_device() call
fails, releasing the mapping seems to be a bug. As the bug isn't introduced by
this patch, we can fix it separately, but if you end up resubmitting due to
the first comment you could also add a fix.
>
> dev->archdata.iommu = NULL;
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2016-11-11 1:00 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-19 23:35 [PATCH v6 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V6 Magnus Damm
2016-10-19 23:35 ` Magnus Damm
2016-10-19 23:35 ` [PATCH v6 01/07] iommu/ipmmu-vmsa: Remove platform data handling Magnus Damm
2016-10-19 23:35 ` Magnus Damm
2016-10-19 23:35 ` [PATCH v6 02/07] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for context Magnus Damm
2016-10-19 23:35 ` Magnus Damm
2016-11-11 0:46 ` Laurent Pinchart
2016-11-11 0:46 ` Laurent Pinchart
2016-10-19 23:36 ` [PATCH v6 03/07] iommu/ipmmu-vmsa: Break out utlb parsing code Magnus Damm
2016-10-19 23:36 ` Magnus Damm
2016-11-11 1:00 ` Laurent Pinchart [this message]
2016-11-11 1:00 ` Laurent Pinchart
2016-10-19 23:36 ` [PATCH v6 04/07] iommu/ipmmu-vmsa: Break out domain allocation code Magnus Damm
2016-11-11 1:02 ` Laurent Pinchart
2016-11-11 1:02 ` Laurent Pinchart
2016-10-19 23:36 ` [PATCH v6 05/07] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops Magnus Damm
2016-10-19 23:36 ` Magnus Damm
2016-10-21 17:52 ` Robin Murphy
2016-10-21 17:52 ` Robin Murphy
2016-11-10 11:42 ` Joerg Roedel
[not found] ` <20161110114206.GC9996-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
2016-11-11 1:13 ` Laurent Pinchart
2016-11-11 1:13 ` Laurent Pinchart
2016-11-11 10:37 ` Joerg Roedel
2016-11-11 1:50 ` Laurent Pinchart
2016-11-11 14:44 ` Robin Murphy
2016-11-11 14:44 ` Robin Murphy
[not found] ` <dbb87293-4760-607f-841c-368a5692ecc9-5wv7dgnIgG8@public.gmane.org>
2016-11-12 1:57 ` Laurent Pinchart
2016-11-12 1:57 ` Laurent Pinchart
2016-11-11 1:24 ` Laurent Pinchart
2016-11-11 1:24 ` Laurent Pinchart
2016-11-11 2:01 ` [PATCH] iommu/ipmmu-vmsa: Unify domain alloc/free implementations Laurent Pinchart
2016-11-11 2:01 ` Laurent Pinchart
2016-10-19 23:36 ` [PATCH v6 06/07] iommu/ipmmu-vmsa: ARM and ARM64 archdata access Magnus Damm
2016-10-21 17:32 ` Robin Murphy
2016-10-21 17:32 ` Robin Murphy
2016-11-11 1:27 ` Laurent Pinchart
2016-10-19 23:36 ` [PATCH v6 07/07] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency Magnus Damm
2016-10-19 23:36 ` Magnus Damm
2016-11-10 11:42 ` [PATCH v6 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V6 Joerg Roedel
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=3032720.BPnZvxWODA@avalon \
--to=laurent.pinchart-rylnwiuwjnjg/c1bvhzhaw@public.gmane.org \
--cc=geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org \
--cc=horms+renesas-/R6kz+dDXgpPR4JQBCEnsQ@public.gmane.org \
--cc=iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=laurent.pinchart+renesas-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-renesas-soc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.