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... 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/94ccd9fd87e302b0435e60b7fe7747c0d059... 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