[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240418160526.3b3c385f@namcao>
Date: Thu, 18 Apr 2024 16:05:26 +0200
From: Nam Cao <namcao@...utronix.de>
To: Patrik Jakobsson <patrik.r.jakobsson@...il.com>
Cc: Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
jayalk@...works.biz, Daniel Vetter <daniel@...ll.ch>, deller@....de,
linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
tiwai@...e.de, bigeasy@...utronix.de, LKML <linux-kernel@...r.kernel.org>,
Vegard Nossum <vegard.nossum@...cle.com>, George Kennedy
<george.kennedy@...cle.com>, Darren Kenny <darren.kenny@...cle.com>,
chuansheng.liu@...el.com
Subject: Re: [bug-report] task info hung problem in fb_deferred_io_work()
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.
> 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
Powered by blists - more mailing lists