drivers/vdpa/vdpa_user/iova_domain.c:305 vduse_domain_alloc_iova() warn: should 'iova_pfn << shift' be a 64 bit type?

drivers/vdpa/vdpa_user/iova_domain.c:305 vduse_domain_alloc_iova() warn: should 'iova_pfn << shift' be a 64 bit type?

[Dan Carpenter]

Hi Xie,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
head:   79e06c4c4950be2abd8ca5d2428a8c915aa62c24
commit: c8a6153b6c59d95c0e091f053f6f180952ade91e vduse: Introduce VDUSE - vDPA Device in Userspace
config: arm-randconfig-m031-20220116 (https://download.01.org/0day-ci/archive/20220117/202201171409.rqbXNHlz-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>

smatch warnings:
drivers/vdpa/vdpa_user/iova_domain.c:305 vduse_domain_alloc_iova() warn: should 'iova_pfn << shift' be a 64 bit type?

vim +305 drivers/vdpa/vdpa_user/iova_domain.c

8c773d53fb7b64 Xie Yongji 2021-08-31  287  static dma_addr_t
8c773d53fb7b64 Xie Yongji 2021-08-31  288  vduse_domain_alloc_iova(struct iova_domain *iovad,
8c773d53fb7b64 Xie Yongji 2021-08-31  289  			unsigned long size, unsigned long limit)
8c773d53fb7b64 Xie Yongji 2021-08-31  290  {
8c773d53fb7b64 Xie Yongji 2021-08-31  291  	unsigned long shift = iova_shift(iovad);
8c773d53fb7b64 Xie Yongji 2021-08-31  292  	unsigned long iova_len = iova_align(iovad, size) >> shift;
8c773d53fb7b64 Xie Yongji 2021-08-31  293  	unsigned long iova_pfn;
8c773d53fb7b64 Xie Yongji 2021-08-31  294  
8c773d53fb7b64 Xie Yongji 2021-08-31  295  	/*
8c773d53fb7b64 Xie Yongji 2021-08-31  296  	 * Freeing non-power-of-two-sized allocations back into the IOVA caches
8c773d53fb7b64 Xie Yongji 2021-08-31  297  	 * will come back to bite us badly, so we have to waste a bit of space
8c773d53fb7b64 Xie Yongji 2021-08-31  298  	 * rounding up anything cacheable to make sure that can't happen. The
8c773d53fb7b64 Xie Yongji 2021-08-31  299  	 * order of the unadjusted size will still match upon freeing.
8c773d53fb7b64 Xie Yongji 2021-08-31  300  	 */
8c773d53fb7b64 Xie Yongji 2021-08-31  301  	if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
8c773d53fb7b64 Xie Yongji 2021-08-31  302  		iova_len = roundup_pow_of_two(iova_len);
8c773d53fb7b64 Xie Yongji 2021-08-31  303  	iova_pfn = alloc_iova_fast(iovad, iova_len, limit >> shift, true);
8c773d53fb7b64 Xie Yongji 2021-08-31  304  
8c773d53fb7b64 Xie Yongji 2021-08-31 @305  	return iova_pfn << shift;

I feel like iova_pfn should probably be declared as dma_addr_t?

8c773d53fb7b64 Xie Yongji 2021-08-31  306  }

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

Re: drivers/vdpa/vdpa_user/iova_domain.c:305 vduse_domain_alloc_iova() warn: should 'iova_pfn << shift' be a 64 bit type?

[Yongji Xie]

On Wed, Jan 19, 2022 at 12:44 PM Dan Carpenter <dan.carpenter@oracle.com> wrote:
>
> Hi Xie,
>
> First bad commit (maybe != root cause):
>
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head:   79e06c4c4950be2abd8ca5d2428a8c915aa62c24
> commit: c8a6153b6c59d95c0e091f053f6f180952ade91e vduse: Introduce VDUSE - vDPA Device in Userspace
> config: arm-randconfig-m031-20220116 (https://download.01.org/0day-ci/archive/20220117/202201171409.rqbXNHlz-lkp@intel.com/config)
> compiler: arm-linux-gnueabi-gcc (GCC) 11.2.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> smatch warnings:
> drivers/vdpa/vdpa_user/iova_domain.c:305 vduse_domain_alloc_iova() warn: should 'iova_pfn << shift' be a 64 bit type?
>
> vim +305 drivers/vdpa/vdpa_user/iova_domain.c
>
> 8c773d53fb7b64 Xie Yongji 2021-08-31  287  static dma_addr_t
> 8c773d53fb7b64 Xie Yongji 2021-08-31  288  vduse_domain_alloc_iova(struct iova_domain *iovad,
> 8c773d53fb7b64 Xie Yongji 2021-08-31  289                       unsigned long size, unsigned long limit)
> 8c773d53fb7b64 Xie Yongji 2021-08-31  290  {
> 8c773d53fb7b64 Xie Yongji 2021-08-31  291       unsigned long shift = iova_shift(iovad);
> 8c773d53fb7b64 Xie Yongji 2021-08-31  292       unsigned long iova_len = iova_align(iovad, size) >> shift;
> 8c773d53fb7b64 Xie Yongji 2021-08-31  293       unsigned long iova_pfn;
> 8c773d53fb7b64 Xie Yongji 2021-08-31  294
> 8c773d53fb7b64 Xie Yongji 2021-08-31  295       /*
> 8c773d53fb7b64 Xie Yongji 2021-08-31  296        * Freeing non-power-of-two-sized allocations back into the IOVA caches
> 8c773d53fb7b64 Xie Yongji 2021-08-31  297        * will come back to bite us badly, so we have to waste a bit of space
> 8c773d53fb7b64 Xie Yongji 2021-08-31  298        * rounding up anything cacheable to make sure that can't happen. The
> 8c773d53fb7b64 Xie Yongji 2021-08-31  299        * order of the unadjusted size will still match upon freeing.
> 8c773d53fb7b64 Xie Yongji 2021-08-31  300        */
> 8c773d53fb7b64 Xie Yongji 2021-08-31  301       if (iova_len < (1 << (IOVA_RANGE_CACHE_MAX_SIZE - 1)))
> 8c773d53fb7b64 Xie Yongji 2021-08-31  302               iova_len = roundup_pow_of_two(iova_len);
> 8c773d53fb7b64 Xie Yongji 2021-08-31  303       iova_pfn = alloc_iova_fast(iovad, iova_len, limit >> shift, true);
> 8c773d53fb7b64 Xie Yongji 2021-08-31  304
> 8c773d53fb7b64 Xie Yongji 2021-08-31 @305       return iova_pfn << shift;
>
> I feel like iova_pfn should probably be declared as dma_addr_t?
>

Yes, I think we need something like:

return (dma_addr_t)iova_pfn << shift;

Thanks,
Yongji