Re: [Intel-gfx] [PATCH 1/8] drm/i915/gem: Break out some shmem backend utils

[kernel test robot <lkp@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 5902 bytes --]

Hi Matthew,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on drm-exynos/exynos-drm-next linus/master v5.15-rc1 next-20210913]
[cannot apply to drm-intel/for-linux-next tegra-drm/drm/tegra/for-next drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Matthew-Auld/drm-i915-gem-Break-out-some-shmem-backend-utils/20210914-021041
base:   git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a015-20210913 (attached as .config)
compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 261cbe98c38f8c1ee1a482fe76511110e790f58a)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/94ccd9fd87e302b0435e60b7fe7747c0d0599133
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Matthew-Auld/drm-i915-gem-Break-out-some-shmem-backend-utils/20210914-021041
        git checkout 94ccd9fd87e302b0435e60b7fe7747c0d0599133
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

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

All warnings (new ones prefixed by >>):

>> drivers/gpu/drm/i915/gem/i915_gem_shmem.c:273:20: warning: variable 'mapping' is uninitialized when used here [-Wuninitialized]
           shmem_free_st(st, mapping, false, false);
                             ^~~~~~~
   drivers/gpu/drm/i915/gem/i915_gem_shmem.c:201:31: note: initialize the variable 'mapping' to silence this warning
           struct address_space *mapping;
                                        ^
                                         = NULL
   1 warning generated.


vim +/mapping +273 drivers/gpu/drm/i915/gem/i915_gem_shmem.c

   195	
   196	static int shmem_get_pages(struct drm_i915_gem_object *obj)
   197	{
   198		struct drm_i915_private *i915 = to_i915(obj->base.dev);
   199		struct intel_memory_region *mem = obj->mm.region;
   200		const unsigned long page_count = obj->base.size / PAGE_SIZE;
   201		struct address_space *mapping;
   202		struct sg_table *st;
   203		struct sgt_iter sgt_iter;
   204		struct page *page;
   205		unsigned int max_segment = i915_sg_segment_size();
   206		int ret;
   207	
   208		/*
   209		 * Assert that the object is not currently in any GPU domain. As it
   210		 * wasn't in the GTT, there shouldn't be any way it could have been in
   211		 * a GPU cache
   212		 */
   213		GEM_BUG_ON(obj->read_domains & I915_GEM_GPU_DOMAINS);
   214		GEM_BUG_ON(obj->write_domain & I915_GEM_GPU_DOMAINS);
   215	
   216	rebuild_st:
   217		st = shmem_alloc_st(i915, obj->base.size, mem,
   218				    obj->base.filp->f_mapping, max_segment);
   219		if (IS_ERR(st)) {
   220			ret = PTR_ERR(st);
   221			goto err_st;
   222		}
   223	
   224		ret = i915_gem_gtt_prepare_pages(obj, st);
   225		if (ret) {
   226			/*
   227			 * DMA remapping failed? One possible cause is that
   228			 * it could not reserve enough large entries, asking
   229			 * for PAGE_SIZE chunks instead may be helpful.
   230			 */
   231			if (max_segment > PAGE_SIZE) {
   232				for_each_sgt_page(page, sgt_iter, st)
   233					put_page(page);
   234				sg_free_table(st);
   235				kfree(st);
   236	
   237				max_segment = PAGE_SIZE;
   238				goto rebuild_st;
   239			} else {
   240				dev_warn(i915->drm.dev,
   241					 "Failed to DMA remap %lu pages\n",
   242					 page_count);
   243				goto err_pages;
   244			}
   245		}
   246	
   247		if (i915_gem_object_needs_bit17_swizzle(obj))
   248			i915_gem_object_do_bit_17_swizzle(obj, st);
   249	
   250		/*
   251		 * EHL and JSL add the 'Bypass LLC' MOCS entry, which should make it
   252		 * possible for userspace to bypass the GTT caching bits set by the
   253		 * kernel, as per the given object cache_level. This is troublesome
   254		 * since the heavy flush we apply when first gathering the pages is
   255		 * skipped if the kernel thinks the object is coherent with the GPU. As
   256		 * a result it might be possible to bypass the cache and read the
   257		 * contents of the page directly, which could be stale data. If it's
   258		 * just a case of userspace shooting themselves in the foot then so be
   259		 * it, but since i915 takes the stance of always zeroing memory before
   260		 * handing it to userspace, we need to prevent this.
   261		 *
   262		 * By setting cache_dirty here we make the clflush in set_pages
   263		 * unconditional on such platforms.
   264		 */
   265		if (IS_JSL_EHL(i915) && obj->flags & I915_BO_ALLOC_USER)
   266			obj->cache_dirty = true;
   267	
   268		__i915_gem_object_set_pages(obj, st, i915_sg_dma_sizes(st->sgl));
   269	
   270		return 0;
   271	
   272	err_pages:
 > 273		shmem_free_st(st, mapping, false, false);
   274		/*
   275		 * shmemfs first checks if there is enough memory to allocate the page
   276		 * and reports ENOSPC should there be insufficient, along with the usual
   277		 * ENOMEM for a genuine allocation failure.
   278		 *
   279		 * We use ENOSPC in our driver to mean that we have run out of aperture
   280		 * space and so want to translate the error from shmemfs back to our
   281		 * usual understanding of ENOMEM.
   282		 */
   283	err_st:
   284		if (ret == -ENOSPC)
   285			ret = -ENOMEM;
   286	
   287		return ret;
   288	}
   289	

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

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 41869 bytes --]