On 2024-04-19 Patrik Jakobsson wrote: > Neither cancel_delayed_work_sync() or flush_delayed_work() prevent new > work from being scheduled after they return. flush_delayed_work() is called during device closing. And because no writes are performed after the device has been closed, no new work should be queued after flush_delayed_work(). > But > cancel_delayed_work_sync() at least makes sure the queue is empty so > the problem becomes less apparent. > > Could this explain what we're seeing? I suspect that cancel_delayed_work_sync() is only treating the symptoms by preventing the deferred work from running. The real bug is "someone" giving fb_deferred_io_work() invalid pages to work with. But that's just a blind guess. Best regards, Nam