From: Matthew Brost <matthew.brost@intel.com>
To: kbuild-all@lists.01.org
Subject: Re: [kbuild] drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2376 eb_pin_timeline() warn: inconsistent returns '&tl->mutex'.
Date: Mon, 07 Feb 2022 09:59:07 -0800 [thread overview]
Message-ID: <20220207175907.GA8452@jons-linux-dev-box> (raw)
In-Reply-To: <202202072340.xZpz7hAb-lkp@intel.com>
[-- Attachment #1: Type: text/plain, Size: 7250 bytes --]
On Mon, Feb 07, 2022 at 08:59:48PM +0300, Dan Carpenter wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: dfd42facf1e4ada021b939b4e19c935dcdd55566
> commit: 544460c33821b44c2f0c643121303c3dc3f66ef1 drm/i915: Multi-BB execbuf
> config: i386-randconfig-m021-20220207 (https://download.01.org/0day-ci/archive/20220207/202202072340.xZpz7hAb-lkp(a)intel.com/config )
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
This is fixed by the below patch:
https://patchwork.freedesktop.org/patch/msgid/20220111163929.14017-1-matthew.brost(a)intel.com
Matt
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> New smatch warnings:
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2376 eb_pin_timeline() warn: inconsistent returns '&tl->mutex'.
>
> vim +2376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2333 static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2334 bool throttle)
> 8f2a1057d6ec21 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2019-04-25 2335 {
> e5dadff4b09376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-15 2336 struct intel_timeline *tl;
> 2bf541ff6d06f4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Maarten Lankhorst 2020-08-19 2337 struct i915_request *rq = NULL;
> 8f2a1057d6ec21 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2019-04-25 2338
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2339 /*
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2340 * Take a local wakeref for preparing to dispatch the execbuf as
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2341 * we expect to access the hardware fairly frequently in the
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2342 * process, and require the engine to be kept awake between accesses.
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2343 * Upon dispatch, we acquire another prolonged wakeref that we hold
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2344 * until the timeline is idle, which in turn releases the wakeref
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2345 * taken on the engine, and the parent device.
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2346 */
> e5dadff4b09376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-15 2347 tl = intel_context_timeline_lock(ce);
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2348 if (IS_ERR(tl))
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2349 return PTR_ERR(tl);
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2350
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2351 intel_context_enter(ce);
> 2bf541ff6d06f4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Maarten Lankhorst 2020-08-19 2352 if (throttle)
> 2bf541ff6d06f4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Maarten Lankhorst 2020-08-19 2353 rq = eb_throttle(eb, ce);
> e5dadff4b09376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-15 2354 intel_context_timeline_unlock(tl);
> e5dadff4b09376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-15 2355
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2356 if (rq) {
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2357 bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2358 long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2359
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2360 if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2361 timeout) < 0) {
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2362 i915_request_put(rq);
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2363
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2364 tl = intel_context_timeline_lock(ce);
>
> This is mutex_lock_interruptible() so it can fail
>
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2365 intel_context_exit(ce);
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2366 intel_context_timeline_unlock(tl);
>
> Leading to an error pointer dereference. Maybe that's why Smatch is
> complaining? Hard to say. Why are we calling mutex_lock if it's
> O_NONBLOCK code?
>
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2367
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2368 if (nonblock)
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2369 return -EWOULDBLOCK;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2370 else
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2371 return -EINTR;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2372 }
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2373 i915_request_put(rq);
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2374 }
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2375
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 @2376 return 0;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2377 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
> _______________________________________________
> kbuild mailing list -- kbuild(a)lists.01.org
> To unsubscribe send an email to kbuild-leave(a)lists.01.org
>
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Brost <matthew.brost@intel.com>
To: Dan Carpenter <dan.carpenter@oracle.com>
Cc: kbuild@lists.01.org, lkp@intel.com, kbuild-all@lists.01.org,
linux-kernel@vger.kernel.org,
John Harrison <John.C.Harrison@Intel.com>
Subject: Re: [kbuild] drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2376 eb_pin_timeline() warn: inconsistent returns '&tl->mutex'.
Date: Mon, 7 Feb 2022 09:59:07 -0800 [thread overview]
Message-ID: <20220207175907.GA8452@jons-linux-dev-box> (raw)
In-Reply-To: <202202072340.xZpz7hAb-lkp@intel.com>
On Mon, Feb 07, 2022 at 08:59:48PM +0300, Dan Carpenter wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> head: dfd42facf1e4ada021b939b4e19c935dcdd55566
> commit: 544460c33821b44c2f0c643121303c3dc3f66ef1 drm/i915: Multi-BB execbuf
> config: i386-randconfig-m021-20220207 (https://download.01.org/0day-ci/archive/20220207/202202072340.xZpz7hAb-lkp@intel.com/config )
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
This is fixed by the below patch:
https://patchwork.freedesktop.org/patch/msgid/20220111163929.14017-1-matthew.brost@intel.com
Matt
> Reported-by: kernel test robot <lkp@intel.com>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> New smatch warnings:
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2376 eb_pin_timeline() warn: inconsistent returns '&tl->mutex'.
>
> vim +2376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
>
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2333 static int eb_pin_timeline(struct i915_execbuffer *eb, struct intel_context *ce,
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2334 bool throttle)
> 8f2a1057d6ec21 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2019-04-25 2335 {
> e5dadff4b09376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-15 2336 struct intel_timeline *tl;
> 2bf541ff6d06f4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Maarten Lankhorst 2020-08-19 2337 struct i915_request *rq = NULL;
> 8f2a1057d6ec21 drivers/gpu/drm/i915/i915_gem_execbuffer.c Chris Wilson 2019-04-25 2338
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2339 /*
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2340 * Take a local wakeref for preparing to dispatch the execbuf as
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2341 * we expect to access the hardware fairly frequently in the
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2342 * process, and require the engine to be kept awake between accesses.
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2343 * Upon dispatch, we acquire another prolonged wakeref that we hold
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2344 * until the timeline is idle, which in turn releases the wakeref
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2345 * taken on the engine, and the parent device.
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2346 */
> e5dadff4b09376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-15 2347 tl = intel_context_timeline_lock(ce);
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2348 if (IS_ERR(tl))
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2349 return PTR_ERR(tl);
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2350
> a4e57f9031ccd5 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-04 2351 intel_context_enter(ce);
> 2bf541ff6d06f4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Maarten Lankhorst 2020-08-19 2352 if (throttle)
> 2bf541ff6d06f4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Maarten Lankhorst 2020-08-19 2353 rq = eb_throttle(eb, ce);
> e5dadff4b09376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-15 2354 intel_context_timeline_unlock(tl);
> e5dadff4b09376 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Chris Wilson 2019-08-15 2355
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2356 if (rq) {
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2357 bool nonblock = eb->file->filp->f_flags & O_NONBLOCK;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2358 long timeout = nonblock ? 0 : MAX_SCHEDULE_TIMEOUT;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2359
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2360 if (i915_request_wait(rq, I915_WAIT_INTERRUPTIBLE,
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2361 timeout) < 0) {
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2362 i915_request_put(rq);
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2363
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2364 tl = intel_context_timeline_lock(ce);
>
> This is mutex_lock_interruptible() so it can fail
>
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2365 intel_context_exit(ce);
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2366 intel_context_timeline_unlock(tl);
>
> Leading to an error pointer dereference. Maybe that's why Smatch is
> complaining? Hard to say. Why are we calling mutex_lock if it's
> O_NONBLOCK code?
>
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2367
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2368 if (nonblock)
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2369 return -EWOULDBLOCK;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2370 else
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2371 return -EINTR;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2372 }
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2373 i915_request_put(rq);
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2374 }
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2375
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 @2376 return 0;
> 544460c33821b4 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c Matthew Brost 2021-10-14 2377 }
>
> ---
> 0-DAY CI Kernel Test Service, Intel Corporation
> https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
> _______________________________________________
> kbuild mailing list -- kbuild@lists.01.org
> To unsubscribe send an email to kbuild-leave@lists.01.org
>
next prev parent reply other threads:[~2022-02-07 17:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-07 15:18 drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2376 eb_pin_timeline() warn: inconsistent returns '&tl->mutex' kernel test robot
2022-02-07 17:59 ` [kbuild] " Dan Carpenter
2022-02-07 17:59 ` Dan Carpenter
2022-02-07 17:59 ` Matthew Brost [this message]
2022-02-07 17:59 ` Matthew Brost
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=20220207175907.GA8452@jons-linux-dev-box \
--to=matthew.brost@intel.com \
--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: link
Be 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.