From: Robin Murphy <robin.murphy@arm.com>
To: Zhen Lei <thunder.leizhen@huawei.com>,
Joerg Roedel <joro@8bytes.org>,
iommu <iommu@lists.linux-foundation.org>,
David Woodhouse <dwmw2@infradead.org>,
Sudeep Dutt <sudeep.dutt@intel.com>,
Ashutosh Dixit <ashutosh.dixit@intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Cc: Zefan Li <lizefan@huawei.com>, Xinwei Hu <huxinwei@huawei.com>,
Tianhong Ding <dingtianhong@huawei.com>,
Hanjun Guo <guohanjun@huawei.com>
Subject: Re: [PATCH 1/7] iommu/iova: fix incorrect variable types
Date: Thu, 23 Mar 2017 11:42:56 +0000 [thread overview]
Message-ID: <5fd3cc4b-44c1-e300-6254-892a6dfa435c@arm.com> (raw)
In-Reply-To: <1490164067-12552-2-git-send-email-thunder.leizhen@huawei.com>
On 22/03/17 06:27, Zhen Lei wrote:
> Keep these four variables type consistent with the paramters of function
> __alloc_and_insert_iova_range and the members of struct iova:
>
> 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
> unsigned long size, unsigned long limit_pfn,
>
> 2. struct iova {
> unsigned long pfn_hi;
> unsigned long pfn_lo;
>
> In fact, limit_pfn is most likely larger than 32 bits on DMA64.
FWIW if pad_size manages to overflow an int something's probably gone
horribly wrong, but there's no harm in making it consistent with
everything else here. However, given that patch #6 makes this irrelevant
anyway, do we really need to bother?
Robin.
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
> ---
> drivers/iommu/iova.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
> index b7268a1..8ba8b496 100644
> --- a/drivers/iommu/iova.c
> +++ b/drivers/iommu/iova.c
> @@ -104,8 +104,8 @@ __cached_rbnode_delete_update(struct iova_domain *iovad, struct iova *free)
> * Computes the padding size required, to make the start address
> * naturally aligned on the power-of-two order of its size
> */
> -static unsigned int
> -iova_get_pad_size(unsigned int size, unsigned int limit_pfn)
> +static unsigned long
> +iova_get_pad_size(unsigned long size, unsigned long limit_pfn)
> {
> return (limit_pfn + 1 - size) & (__roundup_pow_of_two(size) - 1);
> }
> @@ -117,7 +117,7 @@ static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
> struct rb_node *prev, *curr = NULL;
> unsigned long flags;
> unsigned long saved_pfn;
> - unsigned int pad_size = 0;
> + unsigned long pad_size = 0;
>
> /* Walk the tree backwards */
> spin_lock_irqsave(&iovad->iova_rbtree_lock, flags);
>
next prev parent reply other threads:[~2017-03-23 11:43 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-22 6:27 [PATCH 0/7] iommu/iova: improve the allocation performance of dma64 Zhen Lei
2017-03-22 6:27 ` [PATCH 1/7] iommu/iova: fix incorrect variable types Zhen Lei
2017-03-23 11:42 ` Robin Murphy [this message]
2017-03-24 2:27 ` Leizhen (ThunderTown)
2017-03-31 3:30 ` Leizhen (ThunderTown)
2017-03-22 6:27 ` [PATCH 2/7] iommu/iova: cut down judgement times Zhen Lei
2017-03-23 12:11 ` Robin Murphy
2017-03-31 3:55 ` Leizhen (ThunderTown)
2017-03-22 6:27 ` [PATCH 3/7] iommu/iova: insert start_pfn boundary of dma32 Zhen Lei
2017-03-23 13:01 ` Robin Murphy
2017-03-24 3:43 ` Leizhen (ThunderTown)
2017-03-31 3:32 ` Leizhen (ThunderTown)
2017-03-22 6:27 ` [PATCH 4/7] iommu/iova: adjust __cached_rbnode_insert_update Zhen Lei
2017-03-22 6:27 ` [PATCH 5/7] iommu/iova: to optimize the allocation performance of dma64 Zhen Lei
2017-03-22 6:27 ` [PATCH 6/7] iommu/iova: move the caculation of pad mask out of loop Zhen Lei
2017-03-22 6:27 ` [PATCH 7/7] iommu/iova: fix iovad->dma_32bit_pfn as the last pfn of dma32 Zhen Lei
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=5fd3cc4b-44c1-e300-6254-892a6dfa435c@arm.com \
--to=robin.murphy@arm.com \
--cc=ashutosh.dixit@intel.com \
--cc=dingtianhong@huawei.com \
--cc=dwmw2@infradead.org \
--cc=guohanjun@huawei.com \
--cc=huxinwei@huawei.com \
--cc=iommu@lists.linux-foundation.org \
--cc=joro@8bytes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=sudeep.dutt@intel.com \
--cc=thunder.leizhen@huawei.com \
/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).