On 2024-04-18 Patrik Jakobsson wrote: > On Thu, Apr 18, 2024 at 4:05 PM Nam Cao <namcao@xxxxxxxxxxxxx> wrote: > > > > On 2024-04-18 Patrik Jakobsson wrote: > > > This sounds similar to the SUSE bug [1]. We fixed it by reverting [2] > > > in the SUSE kernel. The problem seems to be that flush_delayed_work() > > > kills the timer and re-queues the work but doesn't guarantee that it > > > is finished when returning. So when the device is closed, the > > > fb_deferred_io_work() function can still be queued and tries to access > > > memory that's been freed. > > > > flush_delayed_work() *does* guarantee the work is finished before > > returning. > > Right, flush_work() does guarantee that the work is finished, but it > doesn't guarantee that the queue is idle if work has been requeued > since flush started. So fb_deferred_io_work() should be able to happen > after the device is closed. Or am I missing something? I'm confused: how is it possible for fb_deferred_io_work() to run after the device is closed? The workqueue is flushed during closing of device. If more work is queued during/after the flushing, then someone must be writing to the device during/after the closing of the device. How can that happen? Best regards, Nam > > > > > Patch [2] tries to solve the problem of not throwing away pending data > > > when closing the device. Perhaps calling cancel_delayed_work_sync() > > > and then follow up with a manual call to fb_deferred_io_work() would > > > be enough to flush the remaining data? > > > > > > -Patrik > > > > > > [1] https://bugzilla.suse.com/show_bug.cgi?id=1221814 > > > [2] 33cd6ea9c067 fbdev: flush deferred IO before closing > > > > > > > > > > > > > > > Thanks, > > > > Harshit > >
