All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jani Nikula <jani.nikula@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	DRI <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: avoid flush_scheduled_work() usage
Date: Wed, 03 May 2023 13:06:45 +0300	[thread overview]
Message-ID: <87sfcdzq2y.fsf@intel.com> (raw)
In-Reply-To: <ZDuntOkUeh0Eve8a@phenom.ffwll.local>

On Sun, 16 Apr 2023, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Apr 14, 2023 at 07:52:12PM +0900, Tetsuo Handa wrote:
>> On 2023/04/14 19:13, Jani Nikula wrote:
>> > On Fri, 14 Apr 2023, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>> >> On 2023/03/15 19:47, Luca Coelho wrote:
>> >>> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
>> >>>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
>> >>>> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
>> >>>>
>> >>>> Now that i915 is the last flush_scheduled_work() user, for now let's
>> >>>> start with blind conversion inside the whole drivers/gpu/drm/i915/
>> >>>> directory. Jani Nikula wants to use two workqueues in order to avoid
>> >>>> adding new module globals, but I'm not familiar enough to audit and
>> >>>> split into two workqueues.
>> >>>>
>> >>>> Link: https://lkml.kernel.org/r/87sfeita1p.fsf@intel.com
>> >>>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>> >>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> >>>> Cc: Jani Nikula <jani.nikula@intel.com>
>> >>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> >>>> ---
>> >>>> Changes in v2:
>> >>>>   Add missing alloc_workqueue() failure check.
>> >>>
>> >>> Hi,
>> >>>
>> >>> Thanks for your patch! But it seems that you only fixed that failure
>> >>> check, without making the other change Jani proposed, namely, move the
>> >>> work to the i915 struct instead of making it a global.
>> >>>
>> >>> I'm working on that now.
>> >>
>> >> What is estimated time of arrival on this?
>> >> Can we expect your work in Linux 6.4 ?
>> > 
>> > I'm afraid that ship has sailed. Sorry. :(
>> 
>> Well, then, can we temporarily apply "[PATCH v2] drm/i915: avoid flush_scheduled_work() usage" ?
>> This patch is a mechanical conversion which unlikely causes regressions. This patch eliminates
>> interference from work items outside of i915, which is small but an improvement for i915 users.
>
> I think if someone from i915 team triple-checks that i915 really doesn't
> use any of the drm workers (hotplug handling, atomic commit, ...) then I
> think we should be fine. The one that's unavoidable is the rmfb work
> (which really only exists to avoid signal interruptions when doing this in
> userspace process context, it's entirely synchronous otherwise), but I
> think that's safe.
>
> With that tripled checked I think the mechanical conversion is ok to land
> late for 6.4 and has my
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> [Dropped this on irc already, here just for the record]

The patch conflicts already, I was out sick for a week, and nobody
picked this up in the mean time. I just don't see a way to rush it to
v6.4 anymore, with mere days remaining in the merge window. I'm sorry.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

WARNING: multiple messages have this Message-ID (diff)
From: Jani Nikula <jani.nikula@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>,
	Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Luca Coelho <luca@coelho.fi>,
	DRI <dri-devel@lists.freedesktop.org>,
	Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: avoid flush_scheduled_work() usage
Date: Wed, 03 May 2023 13:06:45 +0300	[thread overview]
Message-ID: <87sfcdzq2y.fsf@intel.com> (raw)
In-Reply-To: <ZDuntOkUeh0Eve8a@phenom.ffwll.local>

On Sun, 16 Apr 2023, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Fri, Apr 14, 2023 at 07:52:12PM +0900, Tetsuo Handa wrote:
>> On 2023/04/14 19:13, Jani Nikula wrote:
>> > On Fri, 14 Apr 2023, Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> wrote:
>> >> On 2023/03/15 19:47, Luca Coelho wrote:
>> >>> On Tue, 2023-03-14 at 20:21 +0900, Tetsuo Handa wrote:
>> >>>> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
>> >>>> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
>> >>>>
>> >>>> Now that i915 is the last flush_scheduled_work() user, for now let's
>> >>>> start with blind conversion inside the whole drivers/gpu/drm/i915/
>> >>>> directory. Jani Nikula wants to use two workqueues in order to avoid
>> >>>> adding new module globals, but I'm not familiar enough to audit and
>> >>>> split into two workqueues.
>> >>>>
>> >>>> Link: https://lkml.kernel.org/r/87sfeita1p.fsf@intel.com
>> >>>> Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
>> >>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
>> >>>> Cc: Jani Nikula <jani.nikula@intel.com>
>> >>>> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
>> >>>> ---
>> >>>> Changes in v2:
>> >>>>   Add missing alloc_workqueue() failure check.
>> >>>
>> >>> Hi,
>> >>>
>> >>> Thanks for your patch! But it seems that you only fixed that failure
>> >>> check, without making the other change Jani proposed, namely, move the
>> >>> work to the i915 struct instead of making it a global.
>> >>>
>> >>> I'm working on that now.
>> >>
>> >> What is estimated time of arrival on this?
>> >> Can we expect your work in Linux 6.4 ?
>> > 
>> > I'm afraid that ship has sailed. Sorry. :(
>> 
>> Well, then, can we temporarily apply "[PATCH v2] drm/i915: avoid flush_scheduled_work() usage" ?
>> This patch is a mechanical conversion which unlikely causes regressions. This patch eliminates
>> interference from work items outside of i915, which is small but an improvement for i915 users.
>
> I think if someone from i915 team triple-checks that i915 really doesn't
> use any of the drm workers (hotplug handling, atomic commit, ...) then I
> think we should be fine. The one that's unavoidable is the rmfb work
> (which really only exists to avoid signal interruptions when doing this in
> userspace process context, it's entirely synchronous otherwise), but I
> think that's safe.
>
> With that tripled checked I think the mechanical conversion is ok to land
> late for 6.4 and has my
>
> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> [Dropped this on irc already, here just for the record]

The patch conflicts already, I was out sick for a week, and nobody
picked this up in the mean time. I just don't see a way to rush it to
v6.4 anymore, with mere days remaining in the merge window. I'm sorry.

BR,
Jani.


-- 
Jani Nikula, Intel Open Source Graphics Center

  reply	other threads:[~2023-05-03 10:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-03 10:11 [Intel-gfx] [PATCH] drm/i915: avoid flush_scheduled_work() usage Tetsuo Handa
2023-03-03 10:11 ` Tetsuo Handa
2023-03-03 10:44 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2023-03-03 11:22 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-03-03 12:49 ` [Intel-gfx] [PATCH] " Tetsuo Handa
2023-03-03 12:49   ` Tetsuo Handa
2023-03-06 11:05   ` [Intel-gfx] " Jani Nikula
2023-03-06 11:05     ` Jani Nikula
2023-03-06 11:17     ` [Intel-gfx] " Tetsuo Handa
2023-03-06 11:17       ` Tetsuo Handa
2023-03-06 18:56 ` [Intel-gfx] ✓ Fi.CI.IGT: success for " Patchwork
2023-03-14 11:21 ` [Intel-gfx] [PATCH v2] " Tetsuo Handa
2023-03-14 11:21   ` Tetsuo Handa
2023-03-15 10:47   ` [Intel-gfx] " Luca Coelho
2023-04-14 10:01     ` Tetsuo Handa
2023-04-14 10:13       ` Jani Nikula
2023-04-14 10:52         ` Tetsuo Handa
2023-04-16  7:45           ` Daniel Vetter
2023-04-16  7:45             ` Daniel Vetter
2023-05-03 10:06             ` Jani Nikula [this message]
2023-05-03 10:06               ` Jani Nikula
2023-05-03 14:00   ` [Intel-gfx] [PATCH v3] " Tetsuo Handa
2023-05-03 14:00     ` Tetsuo Handa
2023-05-18 14:44     ` [Intel-gfx] [PATCH v4] " Tetsuo Handa
2023-05-18 14:44       ` Tetsuo Handa
2023-05-19  8:02       ` [Intel-gfx] " Tvrtko Ursulin
2023-05-22 10:59       ` [Intel-gfx] [PATCH v5] " Tetsuo Handa
2023-05-22 10:59         ` Tetsuo Handa
2023-06-10  7:01         ` [Intel-gfx] " Jani Nikula
2023-06-10  7:01           ` Jani Nikula
2023-05-03 14:34 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: avoid flush_scheduled_work() usage (rev3) Patchwork
2023-05-03 14:46 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-05-04 19:49 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: avoid flush_scheduled_work() usage (rev4) Patchwork
2023-05-04 20:14 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-05-05  6:33 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-05-18 15:22 ` [Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: avoid flush_scheduled_work() usage (rev5) Patchwork
2023-05-18 15:39 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2023-05-22 13:54 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning for drm/i915: avoid flush_scheduled_work() usage (rev6) Patchwork
2023-05-22 13:55 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: " Patchwork
2023-05-22 13:55 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2023-05-22 13:55 ` [Intel-gfx] ✗ Fi.CI.DOCS: " Patchwork
2023-05-22 14:18 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2023-05-22 20:19 ` [Intel-gfx] ✓ Fi.CI.IGT: " 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=87sfcdzq2y.fsf@intel.com \
    --to=jani.nikula@intel.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    /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.