Hi Niranjana, Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on drm-intel/for-linux-next-fixes drm-tip/drm-tip drm/drm-next drm-exynos/exynos-drm-next drm-misc/drm-misc-next linus/master v6.2-rc4 next-20230118] [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/Niranjana-Vishwanathapura/drm-i915-vm_bind-Expose-vm-lookup-function/20230118-151845 base: git://anongit.freedesktop.org/drm-intel for-linux-next patch link: https://lore.kernel.org/r/20230118071609.17572-24-niranjana.vishwanathapura%40intel.com patch subject: [Intel-gfx] [PATCH v10 23/23] drm/i915/vm_bind: Support capture of persistent mappings config: i386-randconfig-a013 (https://download.01.org/0day-ci/archive/20230119/[email protected]/config) compiler: clang version 14.0.6 (https://github.com/llvm/llvm-project f28c006a5895fc0e329fe15fead81e37457cb1d1) 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/intel-lab-lkp/linux/commit/251fbfd52586e3ff4677b44a136d08f9580d79e2 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Niranjana-Vishwanathapura/drm-i915-vm_bind-Expose-vm-lookup-function/20230118-151845 git checkout 251fbfd52586e3ff4677b44a136d08f9580d79e2 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross W=1 O=build_dir ARCH=i386 SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot <[email protected]> All errors (new ones prefixed by >>): >> drivers/gpu/drm/i915/i915_gem.c:181:43: error: no member named >> 'vm_capture_lock' in 'struct i915_address_space' if (!mutex_lock_interruptible(&vma->vm->vm_capture_lock)) { ~~~~~~~ ^ include/linux/mutex.h:188:72: note: expanded from macro 'mutex_lock_interruptible' #define mutex_lock_interruptible(lock) mutex_lock_interruptible_nested(lock, 0) ^~~~ >> drivers/gpu/drm/i915/i915_gem.c:182:36: error: no member named >> 'vm_capture_link' in 'struct i915_vma' sync_unbind = !list_empty(&vma->vm_capture_link); ~~~ ^ drivers/gpu/drm/i915/i915_gem.c:183:27: error: no member named 'vm_capture_lock' in 'struct i915_address_space' mutex_unlock(&vma->vm->vm_capture_lock); ~~~~~~~ ^ 3 errors generated. vim +181 drivers/gpu/drm/i915/i915_gem.c 116 117 int i915_gem_object_unbind(struct drm_i915_gem_object *obj, 118 unsigned long flags) 119 { 120 struct intel_runtime_pm *rpm = &to_i915(obj->base.dev)->runtime_pm; 121 bool vm_trylock = !!(flags & I915_GEM_OBJECT_UNBIND_VM_TRYLOCK); 122 LIST_HEAD(still_in_list); 123 intel_wakeref_t wakeref; 124 struct i915_vma *vma; 125 int ret; 126 127 assert_object_held(obj); 128 129 if (list_empty(&obj->vma.list)) 130 return 0; 131 132 /* 133 * As some machines use ACPI to handle runtime-resume callbacks, and 134 * ACPI is quite kmalloc happy, we cannot resume beneath the vm->mutex 135 * as they are required by the shrinker. Ergo, we wake the device up 136 * first just in case. 137 */ 138 wakeref = intel_runtime_pm_get(rpm); 139 140 try_again: 141 ret = 0; 142 spin_lock(&obj->vma.lock); 143 while (!ret && (vma = list_first_entry_or_null(&obj->vma.list, 144 struct i915_vma, 145 obj_link))) { 146 bool sync_unbind = true; 147 148 list_move_tail(&vma->obj_link, &still_in_list); 149 if (!i915_vma_is_bound(vma, I915_VMA_BIND_MASK)) 150 continue; 151 152 if (flags & I915_GEM_OBJECT_UNBIND_TEST) { 153 ret = -EBUSY; 154 break; 155 } 156 157 /* 158 * Requiring the vm destructor to take the object lock 159 * before destroying a vma would help us eliminate the 160 * i915_vm_tryget() here, AND thus also the barrier stuff 161 * at the end. That's an easy fix, but sleeping locks in 162 * a kthread should generally be avoided. 163 */ 164 ret = -EAGAIN; 165 if (!i915_vm_tryget(vma->vm)) 166 break; 167 168 spin_unlock(&obj->vma.lock); 169 170 /* 171 * Since i915_vma_parked() takes the object lock 172 * before vma destruction, it won't race us here, 173 * and destroy the vma from under us. 174 */ 175 176 /* 177 * Synchronously unbind persistent mappings with capture 178 * request so that vma->resource is valid in the error capture 179 * path without needing extra reference taking in execbuf path. 180 */ > 181 if > (!mutex_lock_interruptible(&vma->vm->vm_capture_lock)) { > 182 sync_unbind = > !list_empty(&vma->vm_capture_link); 183 mutex_unlock(&vma->vm->vm_capture_lock); 184 } 185 186 ret = -EBUSY; 187 if (!sync_unbind && (flags & I915_GEM_OBJECT_UNBIND_ASYNC)) { 188 assert_object_held(vma->obj); 189 ret = i915_vma_unbind_async(vma, vm_trylock); 190 } 191 192 if (ret == -EBUSY && (flags & I915_GEM_OBJECT_UNBIND_ACTIVE || 193 !i915_vma_is_active(vma))) { 194 if (vm_trylock) { 195 if (mutex_trylock(&vma->vm->mutex)) { 196 ret = __i915_vma_unbind(vma); 197 mutex_unlock(&vma->vm->mutex); 198 } 199 } else { 200 ret = i915_vma_unbind(vma); 201 } 202 } 203 204 i915_vm_put(vma->vm); 205 spin_lock(&obj->vma.lock); 206 } 207 list_splice_init(&still_in_list, &obj->vma.list); 208 spin_unlock(&obj->vma.lock); 209 210 if (ret == -EAGAIN && flags & I915_GEM_OBJECT_UNBIND_BARRIER) { 211 rcu_barrier(); /* flush the i915_vm_release() */ 212 goto try_again; 213 } 214 215 intel_runtime_pm_put(rpm, wakeref); 216 217 return ret; 218 } 219 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
