All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lukas Wunner <lukas@wunner.de>
To: Lyude Paul <lyude@redhat.com>
Cc: Pierre Moreau <pierre.morrow@free.fr>,
	Archit Taneja <architt@codeaurora.org>,
	Ismo Toijala <ismo.toijala@gmail.com>,
	nouveau@lists.freedesktop.org, intel-gfx@lists.freedesktop.org,
	dri-devel@lists.freedesktop.org,
	Hans de Goede <hdegoede@redhat.com>,
	Ben Skeggs <bskeggs@redhat.com>,
	Alex Deucher <alexander.deucher@amd.com>,
	Dave Airlie <airlied@redhat.com>, Peter Wu <peter@lekensteyn.nl>
Subject: Re: [PATCH 2/5] drm: Allow determining if current task is output poll worker
Date: Wed, 14 Feb 2018 09:19:02 +0100	[thread overview]
Message-ID: <20180214081902.GA20438@wunner.de> (raw)
In-Reply-To: <1518457571.5319.7.camel@redhat.com>

On Mon, Feb 12, 2018 at 12:46:11PM -0500, Lyude Paul wrote:
> On Sun, 2018-02-11 at 10:38 +0100, Lukas Wunner wrote:
> > Introduce a helper to determine if the current task is an output poll
> > worker.
> > 
> > This allows us to fix a long-standing deadlock in several DRM drivers
> > wherein the ->runtime_suspend callback waits for the output poll worker
> > to finish and the worker in turn calls a ->detect callback which waits
> > for runtime suspend to finish.  The ->detect callback is invoked from
> > multiple call sites and waiting for runtime suspend to finish is the
> > correct thing to do except if it's executing in the context of the
> > worker.
[snip]
> > +/**
> > + * drm_kms_helper_is_poll_worker - is %current task an output poll worker?
> > + *
> > + * Determine if %current task is an output poll worker.  This can be used
> > + * to select distinct code paths for output polling versus other contexts.
> > + */
>
> For this, it would be worth explicitly noting in the comments herethat this
> should be called by DRM drivers in order to prevent racing with hotplug
> polling workers, so that new drivers in the future can avoid implementing this
> race condition in their driver.

Good point, I've just sent out a v2 to address your comment.  Let me know
if this isn't what you had in mind.  It may also be worth to expand the
DOC section at the top of drm_probe_helper.c to explain the interaction
between polling and runtime suspend in more detail, but I think this is
better done in a separate patch to keep the present patch small and thus
easily backportable to stable.

Thanks a lot for the review,

Lukas
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2018-02-14  8:19 UTC|newest]

Thread overview: 68+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-11  9:38 [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers Lukas Wunner
2018-02-11  9:38 ` [PATCH 5/5] drm/amdgpu: Fix deadlock on runtime suspend Lukas Wunner
2018-02-11  9:38 ` [PATCH 1/5] workqueue: Allow retrieval of current task's work struct Lukas Wunner
2018-02-12 17:07   ` Tejun Heo
2018-02-12 17:07     ` Tejun Heo
2018-02-11  9:38 ` [PATCH 4/5] drm/radeon: Fix deadlock on runtime suspend Lukas Wunner
2018-02-11  9:38 ` [PATCH 3/5] drm/nouveau: " Lukas Wunner
2018-02-11  9:38 ` [PATCH 2/5] drm: Allow determining if current task is output poll worker Lukas Wunner
2018-02-12 17:46   ` Lyude Paul
2018-02-12 17:46     ` Lyude Paul
2018-02-12 17:50     ` [Intel-gfx] " Chris Wilson
2018-02-12 17:50       ` Chris Wilson
2018-02-12 18:40       ` Lukas Wunner
2018-02-14  8:19     ` Lukas Wunner [this message]
2018-02-14  7:41   ` [PATCH v2] " Lukas Wunner
2018-02-14 19:07     ` Lyude Paul
2018-02-11 18:58 ` [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers Mike Lothian
2018-02-11 18:58   ` Mike Lothian
2018-02-11 19:23   ` Lukas Wunner
2018-02-11 19:41     ` Lukas Wunner
2018-02-11 19:41       ` Lukas Wunner
2018-02-12  0:35       ` Mike Lothian
2018-02-12  0:35         ` Mike Lothian
2018-02-12  3:39         ` Lukas Wunner
2018-02-12  3:39           ` Lukas Wunner
2018-02-12  9:03           ` Mike Lothian
2018-02-12  9:03             ` Mike Lothian
2018-02-12  9:45             ` Lukas Wunner
2018-02-12  9:45               ` Lukas Wunner
2018-02-12 18:58               ` Alex Deucher
2018-02-12 18:58                 ` Alex Deucher
2018-02-13  8:17                 ` Lukas Wunner
2018-02-13  8:17                   ` Lukas Wunner
2018-02-13 15:19                   ` Alex Deucher
2018-02-12 13:04 ` Imre Deak
2018-02-12 13:04   ` Imre Deak
2018-02-16  8:49   ` i915 runtime PM (was: Re: [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers) Lukas Wunner
2018-02-16 12:33     ` Imre Deak
2018-02-12 17:43 ` [PATCH 0/5] Fix deadlock on runtime suspend in DRM drivers Lyude Paul
2018-02-13 10:55 ` Liviu Dudau
2018-02-13 10:55   ` Liviu Dudau
2018-02-13 11:52   ` Lukas Wunner
2018-02-13 15:46     ` Liviu Dudau
2018-02-13 15:46       ` Liviu Dudau
2018-02-14 13:57       ` Lukas Wunner
2018-02-14 13:57         ` Lukas Wunner
2018-02-14  8:46 ` Lukas Wunner
2018-02-14  9:26   ` Maarten Lankhorst
     [not found]     ` <1ab1ea48-125c-a104-c11d-16d1e9d94b98-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2018-02-14 14:08       ` Sean Paul
2018-02-14 14:43         ` Michel Dänzer
2018-02-14 14:58           ` Sean Paul
2018-02-15  5:38             ` Lukas Wunner
2018-02-19 11:48               ` [Intel-gfx] " Daniel Vetter
2018-02-19 12:22                 ` Lukas Wunner
2018-02-17 10:38 ` Lukas Wunner
2018-02-17 10:38   ` Lukas Wunner
2018-02-19 11:34 ` [Nouveau] " Daniel Vetter
2018-02-19 11:34   ` Daniel Vetter
2018-02-19 11:58   ` Lukas Wunner
2018-02-19 11:58     ` Lukas Wunner
2018-02-19 14:05     ` [Intel-gfx] " Daniel Vetter
2018-02-19 14:05       ` Daniel Vetter
2018-02-19 14:47       ` Lukas Wunner
2018-02-19 14:47         ` Lukas Wunner
2018-02-19 14:54         ` Daniel Vetter
2018-02-19 14:54           ` Daniel Vetter
2018-02-19 15:50           ` [Intel-gfx] " Alex Deucher
2018-02-19 15:50             ` Alex Deucher

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=20180214081902.GA20438@wunner.de \
    --to=lukas@wunner.de \
    --cc=airlied@redhat.com \
    --cc=alexander.deucher@amd.com \
    --cc=architt@codeaurora.org \
    --cc=bskeggs@redhat.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hdegoede@redhat.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ismo.toijala@gmail.com \
    --cc=lyude@redhat.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=peter@lekensteyn.nl \
    --cc=pierre.morrow@free.fr \
    /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.