From: "Gupta, Anshuman" <anshuman.gupta@intel.com>
To: "Deak, Imre" <imre.deak@intel.com>
Cc: "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix incorrect assert about pending power domain async-put work
Date: Thu, 3 Jun 2021 06:22:25 +0000 [thread overview]
Message-ID: <efa7bfa8f8fb4d799c70aa4f093d0c11@intel.com> (raw)
In-Reply-To: <20210602140127.GB2936436@ideak-desk.fi.intel.com>
> -----Original Message-----
> From: Deak, Imre <imre.deak@intel.com>
> Sent: Wednesday, June 2, 2021 7:31 PM
> To: Gupta, Anshuman <anshuman.gupta@intel.com>
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix incorrect assert about pending
> power domain async-put work
>
> On Wed, Jun 02, 2021 at 02:35:28PM +0530, Anshuman Gupta wrote:
> > On 2021-05-26 at 20:07:28 +0530, Imre Deak wrote:
> > > It's possible that an already dequeued put_async_work() will release
> > > the reference (*) that was put asynchronously after the dequeue happened.
> > > This leaves an async-put work pending, without any reference to release.
> > > A subsequent async-put may trigger the
> > >
> > > drm_WARN_ON(!queue_delayed_work(&power_domains-
> >async_put_work));
> > >
> > > warn due to async_put_work() still pending. To avoid the warn,
> > > cancel the pending async_put_work() when releasing the reference at (*)
> above.
> >
> > Not able to visulize the race here between
> > __intel_display_power_put_async and
> > intel_display_power_put_async_work() considering both are protected by
> power_domains->lock.
> >
> > queue_delayed_work_on() documentation says following about return value.
> > "Return: %false if @work was already on a queue, %true otherwise."
> > AFAIU from the doc, queue_delayed_work will return false only when
> > work was in queue after dequeued put_async_work() it should return true ?
>
> Yes, and so the WARN is triggered when __intel_display_power_put_async()
> tries to queue a work when one is already pending in the queue:
>
> 1. get(A)
> 2. put_async(A) -> queues put_async_work() 3. put_async_work() dequeued,
> blocking on power_domains->lock 4. get(A) -> grab_async_put_ref(), reacquires
> the ref that was put in 2.
> 5. put_async(A) -> queues put_async_work() 6. put_async_work() dequeued in 3.
> unblocks, releases the ref that was put in
> 5., put_async_work() queued in 5. still pending in the queue, without
> any reference to release.
> 7. get(A)
> 8. put_async(A) -> tries to queue put_async_work(), but it's already
> pending -> WARN triggers.
>
> The patch avoids the WARN in 8 by cancelling the queued work at 6.
Thanks for explaining it.
Patch looks good to me.
Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com>
>
> > Thanks,
> > Anshuman Gupta.
> > >
> > > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/3421
> > > Fixes: https://gitlab.freedesktop.org/drm/intel/-/issues/2289
> > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display_power.c | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > index 2f7d1664c4738..a95bbf23e6b7c 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > > @@ -2263,6 +2263,12 @@ intel_display_power_put_async_work(struct
> work_struct *work)
> > > fetch_and_zero(&power_domains-
> >async_put_domains[1]);
> > > queue_async_put_domains_work(power_domains,
> > >
> fetch_and_zero(&new_work_wakeref));
> > > + } else {
> > > + /*
> > > + * Cancel the work that got queued after this one got dequeued,
> > > + * since here we released the corresponding async-put
> reference.
> > > + */
> > > + cancel_delayed_work(&power_domains->async_put_work);
> > > }
> > >
> > > out_verify:
> > > --
> > > 2.27.0
> > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2021-06-03 6:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 14:37 [Intel-gfx] [PATCH 1/3] drm/i915/ddi: Flush encoder power domain ref puts during driver unload Imre Deak
2021-05-26 14:37 ` [Intel-gfx] [PATCH 2/3] drm/i915: Fix incorrect assert about pending power domain async-put work Imre Deak
2021-06-02 9:05 ` Anshuman Gupta
2021-06-02 14:01 ` Imre Deak
2021-06-03 6:22 ` Gupta, Anshuman [this message]
2021-05-26 14:37 ` [Intel-gfx] [PATCH 3/3] drm/i915/adlp: Fix AUX power well -> PHY mapping Imre Deak
2021-06-03 9:43 ` Anshuman Gupta
2021-06-09 11:42 ` Jani Nikula
2021-06-09 12:34 ` Imre Deak
2021-05-26 21:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/ddi: Flush encoder power domain ref puts during driver unload Patchwork
2021-05-27 10:02 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2021-05-27 18:04 ` Imre Deak
2021-05-27 19:41 ` Vudum, Lakshminarayana
2021-05-27 18:40 ` [Intel-gfx] ✓ Fi.CI.IGT: success " Patchwork
2021-06-03 16:34 ` Imre Deak
2021-06-02 8:06 ` [Intel-gfx] [PATCH 1/3] " Anshuman Gupta
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=efa7bfa8f8fb4d799c70aa4f093d0c11@intel.com \
--to=anshuman.gupta@intel.com \
--cc=imre.deak@intel.com \
--cc=intel-gfx@lists.freedesktop.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.