linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: thunder.leizhen@huawei.com (Leizhen (ThunderTown))
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 4/4] iommu/iova: Make dma_32bit_pfn implicit
Date: Thu, 20 Jul 2017 10:55:40 +0800	[thread overview]
Message-ID: <59701BAC.7060800@huawei.com> (raw)
In-Reply-To: <201707192352.79mkRePJ%fengguang.wu@intel.com>



On 2017/7/19 23:07, kbuild test robot wrote:
> Hi Zhen,
> 
> [auto build test WARNING on iommu/next]
> [also build test WARNING on v4.13-rc1]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
> 
> url:    https://github.com/0day-ci/linux/commits/Robin-Murphy/Optimise-64-bit-IOVA-allocations/20170719-060847
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git next
> config: arm-multi_v7_defconfig (attached as .config)
> compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
>         wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
>         chmod +x ~/bin/make.cross
>         # save the attached .config to linux build tree
>         make.cross ARCH=arm 
> 
> All warnings (new ones prefixed by >>):
> 
>    drivers/iommu/iova.c: In function 'init_iova_domain':
>>> drivers/iommu/iova.c:53:41: warning: large integer implicitly truncated to unsigned type [-Woverflow]
>      iovad->dma_32bit_pfn = iova_pfn(iovad, 1ULL << 32);
OK, I see. I think the problem is that "1ULL << 32" exceed the scope of 32bits general register. We should
replace "1ULL << 32" with DMA_BIT_MASK(32), the latter will minus one to keep it can be safely stored in
the general register.

iovad->dma_32bit_pfn = iova_pfn(iovad, DMA_BIT_MASK(32)) + 1;

>                                             ^~~~
> 
> vim +53 drivers/iommu/iova.c
> 
>     35	
>     36	void
>     37	init_iova_domain(struct iova_domain *iovad, unsigned long granule,
>     38		unsigned long start_pfn)
>     39	{
>     40		/*
>     41		 * IOVA granularity will normally be equal to the smallest
>     42		 * supported IOMMU page size; both *must* be capable of
>     43		 * representing individual CPU pages exactly.
>     44		 */
>     45		BUG_ON((granule > PAGE_SIZE) || !is_power_of_2(granule));
>     46	
>     47		spin_lock_init(&iovad->iova_rbtree_lock);
>     48		iovad->rbroot = RB_ROOT;
>     49		iovad->cached_node = NULL;
>     50		iovad->cached32_node = NULL;
>     51		iovad->granule = granule;
>     52		iovad->start_pfn = start_pfn;
>   > 53		iovad->dma_32bit_pfn = iova_pfn(iovad, 1ULL << 32);
>     54		init_iova_rcaches(iovad);
>     55	}
>     56	EXPORT_SYMBOL_GPL(init_iova_domain);
>     57	
> 
> ---
> 0-DAY kernel test infrastructure                Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all                   Intel Corporation
> 

-- 
Thanks!
BestRegards

  reply	other threads:[~2017-07-20  2:55 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-18 16:57 [PATCH 0/4] Optimise 64-bit IOVA allocations Robin Murphy
2017-07-18 16:57 ` [PATCH 1/4] iommu/iova: Optimise rbtree searching Robin Murphy
2017-07-18 16:57 ` [PATCH 2/4] iommu/iova: Optimise the padding calculation Robin Murphy
2017-07-18 16:57 ` [PATCH 3/4] iommu/iova: Extend rbtree node caching Robin Murphy
2017-07-18 16:57 ` [PATCH 4/4] iommu/iova: Make dma_32bit_pfn implicit Robin Murphy
2017-07-19 15:07   ` kbuild test robot
2017-07-20  2:55     ` Leizhen (ThunderTown) [this message]
2017-07-19  8:37 ` [PATCH 0/4] Optimise 64-bit IOVA allocations Ard Biesheuvel
2017-07-19 10:23   ` Robin Murphy
2017-07-21  9:48     ` Leizhen (ThunderTown)

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=59701BAC.7060800@huawei.com \
    --to=thunder.leizhen@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.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).