[Intel-gfx] [PATCH v10 23/23] drm/i915/vm_bind: Support capture of persistent mappings
kernel test robot
lkp at intel.com
Wed Jan 18 20:27:11 UTC 2023
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/202301190440.EuujWDwh-lkp@intel.com/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 <lkp at intel.com>
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
More information about the dri-devel
mailing list