On Sun, 16 Apr 2023, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxx >> >>>> Signed-off-by: Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> >> >>>> Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> >> >>>> Cc: Jani Nikula <jani.nikula@xxxxxxxxx> >> >>>> Cc: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> >> >>>> --- >> >>>> 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@xxxxxxxx> > > [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