On 30/06/2022 09:06, Tetsuo Handa wrote:
On 2022/06/30 16:46, Tvrtko Ursulin wrote:
Hi,
On 10/06/2022 15:57, Tetsuo Handa wrote:
Hello.
Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using
a macro") explains, we are removing flush_scheduled_work() calls. And now
drivers/gpu/drm/i915/display/intel_display.c
drivers/gpu/drm/i915/gt/selftest_execlists.c
are the last flush_scheduled_work() callers which have no patch proposed.
I want to make a patch like
https://lkml.kernel.org/r/e9b95132-89cd-5cfc-1a09-966393c5ecb0@xxxxxxxxxxxxxxxxxxx
but I couldn't understand how to interpret drivers/gpu/drm/i915/ part.
Could you provide some more context please? I did not immediately understand
whether the goal is remove flush_schedule_work helper with no arguments, or
actually stop drivers using the system work queues.
The goal is to remove flush_schedule_work().
Any kernel module is expected to stop using system workqueues if that module
needs to call flush_scheduled_work() or flush_workqueue(system_*_wq).
Continuing use of system workqueues is OK as long as that module does not
need to call flush_scheduled_work() nor flush_workqueue(system_*_wq).
Could you give more context on reasoning here please? What is the
difference between using the system_wq and flushing it from a random
context? Or concern is about flushing from specific contexts?
All in-tree kernel modules stopped calling flush_workqueue(system_*_wq) in 5.19.
Many of in-tree kernel modules already have patches for stop calling
flush_scheduled_work(). But gpu/drm/i915 is one of in-tree kernel modules
which do not have patches for stop calling flush_scheduled_work().
I want help from those who are familiar with this module.
On the i915 specifics, the caller in
drivers/gpu/drm/i915/gt/selftest_execlists.c I am pretty sure can be
removed. It is synchronized with the error capture side of things which
is not required for the test to work.
I can send a patch for that or you can, as you prefer?
The drivers/gpu/drm/i915/display/intel_display.c one will have to be
looked at by Jani or someone familiar with display code paths.
Regards,
Tvrtko
