[Intel-gfx] [PATCH 1/8] drm/i915/gem: Break out some shmem backend utils
kernel test robot
lkp at intel.com
Tue Sep 14 03:45:30 UTC 2021
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 at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 41869 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20210914/a309ced6/attachment-0001.gz>
More information about the Intel-gfx
mailing list