Hi Sebastian, kernel test robot noticed the following build warnings:
[auto build test WARNING on drm-intel/for-linux-next] [also build test WARNING on linus/master v6.16-rc2 next-20250617] [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#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Sebastian-Brzezinka/drm-i915-Add-sanity-check-for-relocation-entry-pointer-in-execbuffer/20250616-222313 base: git://anongit.freedesktop.org/drm-intel for-linux-next patch link: https://lore.kernel.org/r/lofb2i4actwlvfk6xbtihirrc34j3pb6xecvcl433a2xbm7zy6%40akz3ko2bh2i5 patch subject: [PATCH] drm/i915: Add sanity check for relocation entry pointer in execbuffer config: i386-randconfig-062-20250617 (https://download.01.org/0day-ci/archive/20250617/[email protected]/config) compiler: gcc-12 (Debian 12.2.0-14) 12.2.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250617/[email protected]/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <[email protected]> | Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ sparse warnings: (new ones prefixed by >>) >> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1431:24: sparse: sparse: >> incorrect type in argument 1 (different address spaces) @@ expected void >> const [noderef] __user *ptr @@ got struct drm_i915_gem_relocation_entry >> const *reloc @@ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1431:24: sparse: expected void const [noderef] __user *ptr drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1431:24: sparse: got struct drm_i915_gem_relocation_entry const *reloc vim +1431 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 1420 1421 static u64 1422 eb_relocate_entry(struct i915_execbuffer *eb, 1423 struct eb_vma *ev, 1424 const struct drm_i915_gem_relocation_entry *reloc) 1425 { 1426 struct drm_i915_private *i915 = eb->i915; 1427 struct eb_vma *target; 1428 int err; 1429 1430 /* Sanity check for non-canonical or NULL pointer */ > 1431 if (!reloc || !access_ok(reloc, sizeof(*reloc))) { 1432 DRM_ERROR("Invalid relocation entry pointer: %p\n", reloc); 1433 return -EFAULT; 1434 } 1435 1436 /* we've already hold a reference to all valid objects */ 1437 target = eb_get_vma(eb, reloc->target_handle); 1438 if (unlikely(!target)) 1439 return -ENOENT; 1440 1441 /* Validate that the target is in a valid r/w GPU domain */ 1442 if (unlikely(reloc->write_domain & (reloc->write_domain - 1))) { 1443 drm_dbg(&i915->drm, "reloc with multiple write domains: " 1444 "target %d offset %d " 1445 "read %08x write %08x\n", 1446 reloc->target_handle, 1447 (int) reloc->offset, 1448 reloc->read_domains, 1449 reloc->write_domain); 1450 return -EINVAL; 1451 } 1452 if (unlikely((reloc->write_domain | reloc->read_domains) 1453 & ~I915_GEM_GPU_DOMAINS)) { 1454 drm_dbg(&i915->drm, "reloc with read/write non-GPU domains: " 1455 "target %d offset %d " 1456 "read %08x write %08x\n", 1457 reloc->target_handle, 1458 (int) reloc->offset, 1459 reloc->read_domains, 1460 reloc->write_domain); 1461 return -EINVAL; 1462 } 1463 1464 if (reloc->write_domain) { 1465 target->flags |= EXEC_OBJECT_WRITE; 1466 1467 /* 1468 * Sandybridge PPGTT errata: We need a global gtt mapping 1469 * for MI and pipe_control writes because the gpu doesn't 1470 * properly redirect them through the ppgtt for non_secure 1471 * batchbuffers. 1472 */ 1473 if (reloc->write_domain == I915_GEM_DOMAIN_INSTRUCTION && 1474 GRAPHICS_VER(eb->i915) == 6 && 1475 !i915_vma_is_bound(target->vma, I915_VMA_GLOBAL_BIND)) { 1476 struct i915_vma *vma = target->vma; 1477 1478 reloc_cache_unmap(&eb->reloc_cache); 1479 mutex_lock(&vma->vm->mutex); 1480 err = i915_vma_bind(target->vma, 1481 target->vma->obj->pat_index, 1482 PIN_GLOBAL, NULL, NULL); 1483 mutex_unlock(&vma->vm->mutex); 1484 reloc_cache_remap(&eb->reloc_cache, ev->vma->obj); 1485 if (err) 1486 return err; 1487 } 1488 } 1489 1490 /* 1491 * If the relocation already has the right value in it, no 1492 * more work needs to be done. 1493 */ 1494 if (!DBG_FORCE_RELOC && 1495 gen8_canonical_addr(i915_vma_offset(target->vma)) == reloc->presumed_offset) 1496 return 0; 1497 1498 /* Check that the relocation address is valid... */ 1499 if (unlikely(reloc->offset > 1500 ev->vma->size - (eb->reloc_cache.use_64bit_reloc ? 8 : 4))) { 1501 drm_dbg(&i915->drm, "Relocation beyond object bounds: " 1502 "target %d offset %d size %d.\n", 1503 reloc->target_handle, 1504 (int)reloc->offset, 1505 (int)ev->vma->size); 1506 return -EINVAL; 1507 } 1508 if (unlikely(reloc->offset & 3)) { 1509 drm_dbg(&i915->drm, "Relocation not 4-byte aligned: " 1510 "target %d offset %d.\n", 1511 reloc->target_handle, 1512 (int)reloc->offset); 1513 return -EINVAL; 1514 } 1515 1516 /* 1517 * If we write into the object, we need to force the synchronisation 1518 * barrier, either with an asynchronous clflush or if we executed the 1519 * patching using the GPU (though that should be serialised by the 1520 * timeline). To be completely sure, and since we are required to 1521 * do relocations we are already stalling, disable the user's opt 1522 * out of our synchronisation. 1523 */ 1524 ev->flags &= ~EXEC_OBJECT_ASYNC; 1525 1526 /* and update the user's relocation entry */ 1527 return relocate_entry(ev->vma, reloc, eb, target->vma); 1528 } 1529 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki
