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-submission-a... 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/7e7ae2111b2855ac3d63aa5c806c6936daaa... 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@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