[Intel-gfx] [PATCH 24/27] drm/i915: Multi-BB execbuf

kernel test robot lkp at intel.com
Mon Aug 30 03:46:52 UTC 2021


Hi Matthew,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip drm-exynos/exynos-drm-next next-20210827]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.14]
[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-Brost/Parallel-submission-aka-multi-bb-execbuf/20210821-065348
base:   git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel-8.3-kselftests (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-348-gf0e6938b-dirty
        # https://github.com/0day-ci/linux/commit/7e7ae2111b2855ac3d63aa5c806c6936daaa6bbc
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Matthew-Brost/Parallel-submission-aka-multi-bb-execbuf/20210821-065348
        git checkout 7e7ae2111b2855ac3d63aa5c806c6936daaa6bbc
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=x86_64 SHELL=/bin/bash

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


sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:608:21: sparse: sparse: Using plain integer as NULL pointer

vim +608 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c

   548	
   549	static int
   550	eb_add_vma(struct i915_execbuffer *eb,
   551		   unsigned int *current_batch,
   552		   unsigned int i,
   553		   struct i915_vma *vma)
   554	{
   555		struct drm_i915_private *i915 = eb->i915;
   556		struct drm_i915_gem_exec_object2 *entry = &eb->exec[i];
   557		struct eb_vma *ev = &eb->vma[i];
   558	
   559		ev->vma = vma;
   560		ev->exec = entry;
   561		ev->flags = entry->flags;
   562	
   563		if (eb->lut_size > 0) {
   564			ev->handle = entry->handle;
   565			hlist_add_head(&ev->node,
   566				       &eb->buckets[hash_32(entry->handle,
   567							    eb->lut_size)]);
   568		}
   569	
   570		if (entry->relocation_count)
   571			list_add_tail(&ev->reloc_link, &eb->relocs);
   572	
   573		/*
   574		 * SNA is doing fancy tricks with compressing batch buffers, which leads
   575		 * to negative relocation deltas. Usually that works out ok since the
   576		 * relocate address is still positive, except when the batch is placed
   577		 * very low in the GTT. Ensure this doesn't happen.
   578		 *
   579		 * Note that actual hangs have only been observed on gen7, but for
   580		 * paranoia do it everywhere.
   581		 */
   582		if (is_batch_buffer(eb, i)) {
   583			if (entry->relocation_count &&
   584			    !(ev->flags & EXEC_OBJECT_PINNED))
   585				ev->flags |= __EXEC_OBJECT_NEEDS_BIAS;
   586			if (eb->reloc_cache.has_fence)
   587				ev->flags |= EXEC_OBJECT_NEEDS_FENCE;
   588	
   589			eb->batches[*current_batch] = ev;
   590	
   591			if (unlikely(ev->flags & EXEC_OBJECT_WRITE)) {
   592				drm_dbg(&i915->drm,
   593					"Attempting to use self-modifying batch buffer\n");
   594				return -EINVAL;
   595			}
   596	
   597			if (range_overflows_t(u64,
   598					      eb->batch_start_offset,
   599					      eb->args->batch_len,
   600					      ev->vma->size)) {
   601				drm_dbg(&i915->drm, "Attempting to use out-of-bounds batch\n");
   602				return -EINVAL;
   603			}
   604	
   605			if (eb->args->batch_len == 0)
   606				eb->batch_len[*current_batch] = ev->vma->size -
   607					eb->batch_start_offset;
 > 608			if (unlikely(eb->batch_len == 0)) { /* impossible! */
   609				drm_dbg(&i915->drm, "Invalid batch length\n");
   610				return -EINVAL;
   611			}
   612	
   613			++*current_batch;
   614		}
   615	
   616		return 0;
   617	}
   618	

---
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: 42173 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20210830/be1630e3/attachment-0001.gz>


More information about the Intel-gfx mailing list