[PATCH] drm/i915: Add sanity check for relocation entry pointer in execbuffer
kernel test robot
lkp at intel.com
Tue Jun 17 13:11:27 UTC 2025
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/202506172030.rBM8TgS8-lkp@intel.com/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/202506172030.rBM8TgS8-lkp@intel.com/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 <lkp at intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202506172030.rBM8TgS8-lkp@intel.com/
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
More information about the Intel-gfx
mailing list