From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: Robin Murphy <robin.murphy@arm.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>,
Joerg Roedel <jroedel@suse.de>
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: Fri, 24 Mar 2017 10:27:13 +0800 [thread overview]
Message-ID: <58D48401.10009@huawei.com> (raw)
In-Reply-To: <5fd3cc4b-44c1-e300-6254-892a6dfa435c@arm.com>
On 2017/3/23 19:42, Robin Murphy wrote:
> 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?
Because I'm not sure whether patch #6 can be applied or not.
>
> 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);
>>
>
>
> .
>
--
Thanks!
BestRegards
next prev parent reply other threads:[~2017-03-24 2:29 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
2017-03-24 2:27 ` Leizhen (ThunderTown) [this message]
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=58D48401.10009@huawei.com \
--to=thunder.leizhen@huawei.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=jroedel@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
--cc=robin.murphy@arm.com \
--cc=sudeep.dutt@intel.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
Powered by JetHome