Thread (21 messages) 21 messages, 5 authors, 2024-04-30

Re: [bug-report] task info hung problem in fb_deferred_io_work()

From: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Date: 2024-04-18 14:34:34
Also in: dri-devel, lkml

On Thu, Apr 18, 2024 at 4:05 PM Nam Cao [off-list ref] wrote:
On 2024-04-18 Patrik Jakobsson wrote:
quoted
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?
quoted
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
quoted

Thanks,
Harshit
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help