Re: [PATCH 5/6] drm/amdgpu: Auto-validate DMABuf imports in compute VMs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Felix,

kernel test robot noticed the following build errors:

[auto build test ERROR on next-20231201]
[cannot apply to drm-misc/drm-misc-next drm/drm-next drm-exynos/exynos-drm-next drm-intel/for-linux-next drm-intel/for-linux-next-fixes drm-tip/drm-tip linus/master v6.7-rc3 v6.7-rc2 v6.7-rc1 v6.7-rc4]
[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/Felix-Kuehling/drm-amdkfd-Export-DMABufs-from-KFD-using-GEM-handles/20231202-073833
base:   next-20231201
patch link:    https://lore.kernel.org/r/20231201233438.1709981-5-Felix.Kuehling%40amd.com
patch subject: [PATCH 5/6] drm/amdgpu: Auto-validate DMABuf imports in compute VMs
config: x86_64-randconfig-161-20231203 (https://download.01.org/0day-ci/archive/20231205/202312052136.JfzEpgBw-lkp@xxxxxxxxx/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/20231205/202312052136.JfzEpgBw-lkp@xxxxxxxxx/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@xxxxxxxxx>
| Closes: https://lore.kernel.org/oe-kbuild-all/202312052136.JfzEpgBw-lkp@xxxxxxxxx/

All errors (new ones prefixed by >>):

   ld: drivers/gpu/drm/amd/amdgpu/amdgpu_gem.o: in function `amdgpu_gem_object_open':
>> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c:208: undefined reference to `amdgpu_amdkfd_bo_validate_and_fence'


vim +208 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c

   156	
   157	/*
   158	 * Call from drm_gem_handle_create which appear in both new and open ioctl
   159	 * case.
   160	 */
   161	static int amdgpu_gem_object_open(struct drm_gem_object *obj,
   162					  struct drm_file *file_priv)
   163	{
   164		struct amdgpu_bo *abo = gem_to_amdgpu_bo(obj);
   165		struct amdgpu_device *adev = amdgpu_ttm_adev(abo->tbo.bdev);
   166		struct amdgpu_fpriv *fpriv = file_priv->driver_priv;
   167		struct amdgpu_vm *vm = &fpriv->vm;
   168		struct amdgpu_bo_va *bo_va;
   169		struct mm_struct *mm;
   170		int r;
   171	
   172		mm = amdgpu_ttm_tt_get_usermm(abo->tbo.ttm);
   173		if (mm && mm != current->mm)
   174			return -EPERM;
   175	
   176		if (abo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID &&
   177		    abo->tbo.base.resv != vm->root.bo->tbo.base.resv)
   178			return -EPERM;
   179	
   180		r = amdgpu_bo_reserve(abo, false);
   181		if (r)
   182			return r;
   183	
   184		bo_va = amdgpu_vm_bo_find(vm, abo);
   185		if (!bo_va)
   186			bo_va = amdgpu_vm_bo_add(adev, vm, abo);
   187		else
   188			++bo_va->ref_count;
   189		amdgpu_bo_unreserve(abo);
   190	
   191		/* Validate and add eviction fence to DMABuf imports with dynamic
   192		 * attachment in compute VMs. Re-validation will be done by
   193		 * amdgpu_vm_validate_evicted_bos and the fence will be updated by
   194		 * amdgpu_vm_fence_imports in amdgpu_amdkfd_gpuvm_restore_process_bos.
   195		 *
   196		 * Nested locking below for the case that a GEM object is opened in
   197		 * kfd_mem_export_dmabuf. Since the lock below is only taken for imports,
   198		 * but not for export, this is a different lock class that cannot lead to
   199		 * circular lock dependencies.
   200		 */
   201		if (!vm->is_compute_context || !vm->process_info)
   202			return 0;
   203		if (!obj->import_attach ||
   204		    !dma_buf_is_dynamic(obj->import_attach->dmabuf))
   205			return 0;
   206		mutex_lock_nested(&vm->process_info->lock, 1);
   207		if (!WARN_ON(!vm->process_info->eviction_fence)) {
 > 208			r = amdgpu_amdkfd_bo_validate_and_fence(abo, AMDGPU_GEM_DOMAIN_GTT,
   209								&vm->process_info->eviction_fence->base);
   210			if (r)
   211				dev_warn(adev->dev, "%d: validate_and_fence failed: %d\n",
   212					 vm->task_info.pid, r);
   213		}
   214		mutex_unlock(&vm->process_info->lock);
   215	
   216		return 0;
   217	}
   218	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki



[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux