From: kernel test robot <lkp@intel.com> To: Chris Wilson <chris@chris-wilson.co.uk>, intel-gfx@lists.freedesktop.org Cc: kbuild-all@lists.01.org, Chris Wilson <chris@chris-wilson.co.uk> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent waiting inside ring construction for critical sections Date: Thu, 4 Feb 2021 00:58:12 +0800 [thread overview] Message-ID: <202102040029.0Kczv1O6-lkp@intel.com> (raw) In-Reply-To: <20210203124740.9354-1-chris@chris-wilson.co.uk> [-- Attachment #1: Type: text/plain, Size: 6508 bytes --] Hi Chris, 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-tip/drm-tip v5.11-rc6 next-20210125] [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] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Prevent-waiting-inside-ring-construction-for-critical-sections/20210203-204914 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-rhel (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/7930da83ebb0a7bdfaba6f8f2fc96e3c2ec34a78 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Chris-Wilson/drm-i915-Prevent-waiting-inside-ring-construction-for-critical-sections/20210203-204914 git checkout 7930da83ebb0a7bdfaba6f8f2fc96e3c2ec34a78 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c: In function 'i915_gem_do_execbuffer': >> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:3298:10: error: 'struct drm_file' has no member named 'f_flags' 3298 | if (file->f_flags & O_NONBLOCK) | ^~ -- drivers/gpu/drm/i915/i915_request.c: In function '__i915_request_create': >> drivers/gpu/drm/i915/i915_request.c:854:7: error: 'flags' undeclared (first use in this function) 854 | if ((flags & __GFP_RECLAIM) == 0) | ^~~~~ drivers/gpu/drm/i915/i915_request.c:854:7: note: each undeclared identifier is reported only once for each function it appears in vim +3298 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 3240 3241 if (args->flags & I915_EXEC_FENCE_OUT) { 3242 out_fence_fd = get_unused_fd_flags(O_CLOEXEC); 3243 if (out_fence_fd < 0) { 3244 err = out_fence_fd; 3245 goto err_in_fence; 3246 } 3247 } 3248 3249 err = eb_create(&eb); 3250 if (err) 3251 goto err_out_fence; 3252 3253 GEM_BUG_ON(!eb.lut_size); 3254 3255 err = eb_select_context(&eb); 3256 if (unlikely(err)) 3257 goto err_destroy; 3258 3259 err = eb_select_engine(&eb); 3260 if (unlikely(err)) 3261 goto err_context; 3262 3263 err = eb_lookup_vmas(&eb); 3264 if (err) { 3265 eb_release_vmas(&eb, true); 3266 goto err_engine; 3267 } 3268 3269 i915_gem_ww_ctx_init(&eb.ww, true); 3270 3271 err = eb_relocate_parse(&eb); 3272 if (err) { 3273 /* 3274 * If the user expects the execobject.offset and 3275 * reloc.presumed_offset to be an exact match, 3276 * as for using NO_RELOC, then we cannot update 3277 * the execobject.offset until we have completed 3278 * relocation. 3279 */ 3280 args->flags &= ~__EXEC_HAS_RELOC; 3281 goto err_vma; 3282 } 3283 3284 ww_acquire_done(&eb.ww.ctx); 3285 3286 batch = eb.batch->vma; 3287 3288 /* All GPU relocation batches must be submitted prior to the user rq */ 3289 GEM_BUG_ON(eb.reloc_cache.rq); 3290 3291 /* Allocate a request for this batch buffer nice and early. */ 3292 eb.request = i915_request_create(eb.context); 3293 if (IS_ERR(eb.request)) { 3294 err = PTR_ERR(eb.request); 3295 goto err_vma; 3296 } 3297 > 3298 if (file->f_flags & O_NONBLOCK) 3299 i915_request_set_nowait(eb.request); 3300 3301 if (in_fence) { 3302 if (args->flags & I915_EXEC_FENCE_SUBMIT) 3303 err = i915_request_await_execution(eb.request, 3304 in_fence, 3305 eb.engine->bond_execute); 3306 else 3307 err = i915_request_await_dma_fence(eb.request, 3308 in_fence); 3309 if (err < 0) 3310 goto err_request; 3311 } 3312 3313 if (eb.fences) { 3314 err = await_fence_array(&eb); 3315 if (err) 3316 goto err_request; 3317 } 3318 3319 if (out_fence_fd != -1) { 3320 out_fence = sync_file_create(&eb.request->fence); 3321 if (!out_fence) { 3322 err = -ENOMEM; 3323 goto err_request; 3324 } 3325 } 3326 3327 /* 3328 * Whilst this request exists, batch_obj will be on the 3329 * active_list, and so will hold the active reference. Only when this 3330 * request is retired will the the batch_obj be moved onto the 3331 * inactive_list and lose its active reference. Hence we do not need 3332 * to explicitly hold another reference here. 3333 */ 3334 eb.request->batch = batch; 3335 if (eb.batch_pool) 3336 intel_gt_buffer_pool_mark_active(eb.batch_pool, eb.request); 3337 3338 trace_i915_request_queue(eb.request, eb.batch_flags); 3339 err = eb_submit(&eb, batch); 3340 err_request: 3341 i915_request_get(eb.request); 3342 err = eb_request_add(&eb, err); 3343 3344 if (eb.fences) 3345 signal_fence_array(&eb); 3346 3347 if (out_fence) { 3348 if (err == 0) { 3349 fd_install(out_fence_fd, out_fence->file); 3350 args->rsvd2 &= GENMASK_ULL(31, 0); /* keep in-fence */ 3351 args->rsvd2 |= (u64)out_fence_fd << 32; 3352 out_fence_fd = -1; 3353 } else { 3354 fput(out_fence->file); 3355 } 3356 } 3357 i915_request_put(eb.request); 3358 3359 err_vma: 3360 eb_release_vmas(&eb, true); 3361 if (eb.trampoline) 3362 i915_vma_unpin(eb.trampoline); 3363 WARN_ON(err == -EDEADLK); 3364 i915_gem_ww_ctx_fini(&eb.ww); 3365 3366 if (eb.batch_pool) 3367 intel_gt_buffer_pool_put(eb.batch_pool); 3368 if (eb.reloc_pool) 3369 intel_gt_buffer_pool_put(eb.reloc_pool); 3370 if (eb.reloc_context) 3371 intel_context_put(eb.reloc_context); 3372 err_engine: 3373 eb_put_engine(&eb); 3374 err_context: 3375 i915_gem_context_put(eb.gem_context); 3376 err_destroy: 3377 eb_destroy(&eb); 3378 err_out_fence: 3379 if (out_fence_fd != -1) 3380 put_unused_fd(out_fence_fd); 3381 err_in_fence: 3382 dma_fence_put(in_fence); 3383 err_ext: 3384 put_fence_array(eb.fences, eb.num_fences); 3385 return err; 3386 } 3387 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org [-- Attachment #2: .config.gz --] [-- Type: application/gzip, Size: 45943 bytes --] [-- Attachment #3: Type: text/plain, Size: 160 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
WARNING: multiple messages have this Message-ID (diff)
From: kernel test robot <lkp@intel.com> To: kbuild-all@lists.01.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Prevent waiting inside ring construction for critical sections Date: Thu, 04 Feb 2021 00:58:12 +0800 [thread overview] Message-ID: <202102040029.0Kczv1O6-lkp@intel.com> (raw) In-Reply-To: <20210203124740.9354-1-chris@chris-wilson.co.uk> [-- Attachment #1: Type: text/plain, Size: 6703 bytes --] Hi Chris, 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-tip/drm-tip v5.11-rc6 next-20210125] [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] url: https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-Prevent-waiting-inside-ring-construction-for-critical-sections/20210203-204914 base: git://anongit.freedesktop.org/drm-intel for-linux-next config: x86_64-rhel (attached as .config) compiler: gcc-9 (Debian 9.3.0-15) 9.3.0 reproduce (this is a W=1 build): # https://github.com/0day-ci/linux/commit/7930da83ebb0a7bdfaba6f8f2fc96e3c2ec34a78 git remote add linux-review https://github.com/0day-ci/linux git fetch --no-tags linux-review Chris-Wilson/drm-i915-Prevent-waiting-inside-ring-construction-for-critical-sections/20210203-204914 git checkout 7930da83ebb0a7bdfaba6f8f2fc96e3c2ec34a78 # save the attached .config to linux build tree make W=1 ARCH=x86_64 If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot <lkp@intel.com> All errors (new ones prefixed by >>): drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c: In function 'i915_gem_do_execbuffer': >> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:3298:10: error: 'struct drm_file' has no member named 'f_flags' 3298 | if (file->f_flags & O_NONBLOCK) | ^~ -- drivers/gpu/drm/i915/i915_request.c: In function '__i915_request_create': >> drivers/gpu/drm/i915/i915_request.c:854:7: error: 'flags' undeclared (first use in this function) 854 | if ((flags & __GFP_RECLAIM) == 0) | ^~~~~ drivers/gpu/drm/i915/i915_request.c:854:7: note: each undeclared identifier is reported only once for each function it appears in vim +3298 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c 3240 3241 if (args->flags & I915_EXEC_FENCE_OUT) { 3242 out_fence_fd = get_unused_fd_flags(O_CLOEXEC); 3243 if (out_fence_fd < 0) { 3244 err = out_fence_fd; 3245 goto err_in_fence; 3246 } 3247 } 3248 3249 err = eb_create(&eb); 3250 if (err) 3251 goto err_out_fence; 3252 3253 GEM_BUG_ON(!eb.lut_size); 3254 3255 err = eb_select_context(&eb); 3256 if (unlikely(err)) 3257 goto err_destroy; 3258 3259 err = eb_select_engine(&eb); 3260 if (unlikely(err)) 3261 goto err_context; 3262 3263 err = eb_lookup_vmas(&eb); 3264 if (err) { 3265 eb_release_vmas(&eb, true); 3266 goto err_engine; 3267 } 3268 3269 i915_gem_ww_ctx_init(&eb.ww, true); 3270 3271 err = eb_relocate_parse(&eb); 3272 if (err) { 3273 /* 3274 * If the user expects the execobject.offset and 3275 * reloc.presumed_offset to be an exact match, 3276 * as for using NO_RELOC, then we cannot update 3277 * the execobject.offset until we have completed 3278 * relocation. 3279 */ 3280 args->flags &= ~__EXEC_HAS_RELOC; 3281 goto err_vma; 3282 } 3283 3284 ww_acquire_done(&eb.ww.ctx); 3285 3286 batch = eb.batch->vma; 3287 3288 /* All GPU relocation batches must be submitted prior to the user rq */ 3289 GEM_BUG_ON(eb.reloc_cache.rq); 3290 3291 /* Allocate a request for this batch buffer nice and early. */ 3292 eb.request = i915_request_create(eb.context); 3293 if (IS_ERR(eb.request)) { 3294 err = PTR_ERR(eb.request); 3295 goto err_vma; 3296 } 3297 > 3298 if (file->f_flags & O_NONBLOCK) 3299 i915_request_set_nowait(eb.request); 3300 3301 if (in_fence) { 3302 if (args->flags & I915_EXEC_FENCE_SUBMIT) 3303 err = i915_request_await_execution(eb.request, 3304 in_fence, 3305 eb.engine->bond_execute); 3306 else 3307 err = i915_request_await_dma_fence(eb.request, 3308 in_fence); 3309 if (err < 0) 3310 goto err_request; 3311 } 3312 3313 if (eb.fences) { 3314 err = await_fence_array(&eb); 3315 if (err) 3316 goto err_request; 3317 } 3318 3319 if (out_fence_fd != -1) { 3320 out_fence = sync_file_create(&eb.request->fence); 3321 if (!out_fence) { 3322 err = -ENOMEM; 3323 goto err_request; 3324 } 3325 } 3326 3327 /* 3328 * Whilst this request exists, batch_obj will be on the 3329 * active_list, and so will hold the active reference. Only when this 3330 * request is retired will the the batch_obj be moved onto the 3331 * inactive_list and lose its active reference. Hence we do not need 3332 * to explicitly hold another reference here. 3333 */ 3334 eb.request->batch = batch; 3335 if (eb.batch_pool) 3336 intel_gt_buffer_pool_mark_active(eb.batch_pool, eb.request); 3337 3338 trace_i915_request_queue(eb.request, eb.batch_flags); 3339 err = eb_submit(&eb, batch); 3340 err_request: 3341 i915_request_get(eb.request); 3342 err = eb_request_add(&eb, err); 3343 3344 if (eb.fences) 3345 signal_fence_array(&eb); 3346 3347 if (out_fence) { 3348 if (err == 0) { 3349 fd_install(out_fence_fd, out_fence->file); 3350 args->rsvd2 &= GENMASK_ULL(31, 0); /* keep in-fence */ 3351 args->rsvd2 |= (u64)out_fence_fd << 32; 3352 out_fence_fd = -1; 3353 } else { 3354 fput(out_fence->file); 3355 } 3356 } 3357 i915_request_put(eb.request); 3358 3359 err_vma: 3360 eb_release_vmas(&eb, true); 3361 if (eb.trampoline) 3362 i915_vma_unpin(eb.trampoline); 3363 WARN_ON(err == -EDEADLK); 3364 i915_gem_ww_ctx_fini(&eb.ww); 3365 3366 if (eb.batch_pool) 3367 intel_gt_buffer_pool_put(eb.batch_pool); 3368 if (eb.reloc_pool) 3369 intel_gt_buffer_pool_put(eb.reloc_pool); 3370 if (eb.reloc_context) 3371 intel_context_put(eb.reloc_context); 3372 err_engine: 3373 eb_put_engine(&eb); 3374 err_context: 3375 i915_gem_context_put(eb.gem_context); 3376 err_destroy: 3377 eb_destroy(&eb); 3378 err_out_fence: 3379 if (out_fence_fd != -1) 3380 put_unused_fd(out_fence_fd); 3381 err_in_fence: 3382 dma_fence_put(in_fence); 3383 err_ext: 3384 put_fence_array(eb.fences, eb.num_fences); 3385 return err; 3386 } 3387 --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org [-- Attachment #2: config.gz --] [-- Type: application/gzip, Size: 45943 bytes --]
next prev parent reply other threads:[~2021-02-03 16:58 UTC|newest] Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-02-03 12:47 [Intel-gfx] [PATCH] drm/i915: Prevent waiting inside ring construction for critical sections Chris Wilson 2021-02-03 14:55 ` [Intel-gfx] [PATCH v2] " Chris Wilson 2021-02-03 15:00 ` [Intel-gfx] [PATCH v3] " Chris Wilson 2021-02-03 16:58 ` kernel test robot [this message] 2021-02-03 16:58 ` [Intel-gfx] [PATCH] " kernel test robot 2021-02-03 17:24 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Prevent waiting inside ring construction for critical sections (rev3) Patchwork 2021-02-03 17:55 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=202102040029.0Kczv1O6-lkp@intel.com \ --to=lkp@intel.com \ --cc=chris@chris-wilson.co.uk \ --cc=intel-gfx@lists.freedesktop.org \ --cc=kbuild-all@lists.01.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.