The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: kbuild@lists.01.org, lkp@intel.com, kbuild-all@lists.01.org,
	linux-kernel@vger.kernel.org,
	Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>,
	Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: drivers/gpu/drm/i915/gem/i915_gem_throttle.c:59 i915_gem_throttle_ioctl() error: double locked 'ctx->engines_mutex' (orig line 59)
Date: Mon, 16 Nov 2020 13:44:13 +0300	[thread overview]
Message-ID: <20201116104413.GB18329@kadam> (raw)
In-Reply-To: <160552170467.29277.2663645719015888596@build.alporthouse.com>

On Mon, Nov 16, 2020 at 10:15:04AM +0000, Chris Wilson wrote:
> Quoting Dan Carpenter (2020-11-16 10:08:38)
> > tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git  master
> > head:   0062442ecfef0d82cd69e3e600d5006357f8d8e4
> > commit: 27a5dcfe73f4b696b3de8c23a560199bb1c193a4 drm/i915/gem: Remove disordered per-file request list for throttling
> > config: i386-randconfig-m021-20201115 (attached as .config)
> > compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
> > 
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot <lkp@intel.com>
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > 
> > smatch warnings:
> > drivers/gpu/drm/i915/gem/i915_gem_throttle.c:59 i915_gem_throttle_ioctl() error: double locked 'ctx->engines_mutex' (orig line 59)
> > 
> > vim +59 drivers/gpu/drm/i915/gem/i915_gem_throttle.c
> > 
> >     35  int
> >     36  i915_gem_throttle_ioctl(struct drm_device *dev, void *data,
> >     37                          struct drm_file *file)
> >     38  {
> >     39          const unsigned long recent_enough = jiffies - DRM_I915_THROTTLE_JIFFIES;
> >     40          struct drm_i915_file_private *file_priv = file->driver_priv;
> >     41          struct i915_gem_context *ctx;
> >     42          unsigned long idx;
> >     43          long ret;
> >     44  
> >     45          /* ABI: return -EIO if already wedged */
> >     46          ret = intel_gt_terminally_wedged(&to_i915(dev)->gt);
> >     47          if (ret)
> >     48                  return ret;
> >     49  
> >     50          rcu_read_lock();
> >     51          xa_for_each(&file_priv->context_xa, idx, ctx) {
> >     52                  struct i915_gem_engines_iter it;
> >     53                  struct intel_context *ce;
> >     54  
> >     55                  if (!kref_get_unless_zero(&ctx->ref))
> >     56                          continue;
> >     57                  rcu_read_unlock();
> >     58  
> >     59                  for_each_gem_engine(ce,
> >     60                                      i915_gem_context_lock_engines(ctx),
> >                                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > I don't understand why this takes the lock every iteration through the
> > loop
> 
> It doesn't.
> 
> static inline struct i915_gem_engines *
> i915_gem_context_lock_engines(struct i915_gem_context *ctx)
>         __acquires(&ctx->engines_mutex)
> {
>         mutex_lock(&ctx->engines_mutex);
>         return i915_gem_context_engines(ctx);
> }
> 
> static inline void
> i915_gem_context_unlock_engines(struct i915_gem_context *ctx)
>         __releases(&ctx->engines_mutex)
> {
>         mutex_unlock(&ctx->engines_mutex);
> }
> 
> with the i915_gem_engines stored as a local in the iterator at the start
> of the for loop.

Yeah...  But that's true enough.  But what I think is actually causing
the static checker warning are the continues.

    52          xa_for_each(&file_priv->context_xa, idx, ctx) {
    53                  struct i915_gem_engines_iter it;
    54                  struct intel_context *ce;
    55  
    56                  if (!kref_get_unless_zero(&ctx->ref))
    57                          continue;
    58                  rcu_read_unlock();
    59  
    60                  for_each_gem_engine(ce,
    61                                      i915_gem_context_lock_engines(ctx),
    62                                      it) {
    63                          struct i915_request *rq, *target = NULL;
    64  
    65                          if (!ce->timeline)
    66                                  continue;
                                        ^^^^^^^^^
This continue is for the inside loop, so "ctx" isn't iterated.  There
is another continue as well later in the loop.  Potentially they could
be replaced with breaks?

    67  
    68                          mutex_lock(&ce->timeline->mutex);
    69                          list_for_each_entry_reverse(rq,
    70                                                      &ce->timeline->requests,
    71                                                      link) {
    72                                  if (i915_request_completed(rq))

regards,
dan carpenter

      reply	other threads:[~2020-11-16 12:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-16 10:08 drivers/gpu/drm/i915/gem/i915_gem_throttle.c:59 i915_gem_throttle_ioctl() error: double locked 'ctx->engines_mutex' (orig line 59) Dan Carpenter
2020-11-16 10:15 ` Chris Wilson
2020-11-16 10:44   ` Dan Carpenter [this message]

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=20201116104413.GB18329@kadam \
    --to=dan.carpenter@oracle.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kbuild-all@lists.01.org \
    --cc=kbuild@lists.01.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkp@intel.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=tvrtko.ursulin@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox