[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAMeQTsZJdiyLZvY07gup0ib4SvTQ83p36mLDMRv4C6BH5M69XA@mail.gmail.com>
Date: Tue, 30 Apr 2024 13:45:25 +0200
From: Patrik Jakobsson <patrik.r.jakobsson@...il.com>
To: Nam Cao <namcao@...utronix.de>
Cc: Takashi Iwai <tiwai@...e.de>, Harshit Mogalapalli <harshit.m.mogalapalli@...cle.com>,
Helge Deller <deller@....de>, Thomas Zimmermann <tzimmermann@...e.de>, Daniel Vetter <daniel@...ll.ch>,
linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
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 Fri, Apr 19, 2024 at 5:34 PM Nam Cao <namcao@...utronix.de> wrote:
>
> 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().
Yes, nothing should write after the device is closed but the events
are asynchronous so in theory the order is not guaranteed. I also find
it unlikely but I have no other theory at this point.
>
> > 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.
Trying to figure out when the page goes away in relation to when the
work is triggered might be a good place to start.
>
> Best regards,
> Nam
Powered by blists - more mailing lists