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
