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-20210820]
[cannot apply to tegra-drm/drm/tegra/for-next linus/master drm/drm-next v5.14-rc6]
[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-submissio...
base:
git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-buildonly-randconfig-r002-20210821 (attached as .config)
compiler: clang version 14.0.0 (
https://github.com/llvm/llvm-project
9e9d70591e72fc6762b4b9a226b68ed1307419bf)
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/7e7ae2111b2855ac3d63aa5c806c6936d...
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
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(a)intel.com>
All warnings (new ones prefixed by >>):
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:608:20: warning:
comparison of array 'eb->batch_len' equal to a null pointer is always false
[-Wtautological-pointer-compare]
if (unlikely(eb->batch_len ==
0)) { /* impossible! */
~~~~^~~~~~~~~ ~
include/linux/compiler.h:78:42: note: expanded from macro 'unlikely'
# define unlikely(x) __builtin_expect(!!(x), 0)
^
1 warning generated.
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