On Fri, Apr 19, 2024 at 5:34 PM Nam Cao 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
On 19/04/24 21:53, Nam Cao wrote:
On 2024-04-19 Harshit Mogalapalli wrote:
+CC stable( heads up as this is a regression affecting 5.15.y and
probably others, Greg: this was reproducible upstream so reported
everything w.r.t upstream code but initially found on 5.15.y)
No worry about this, I
On 2024-04-19 Harshit Mogalapalli wrote:
> +CC stable( heads up as this is a regression affecting 5.15.y and
> probably others, Greg: this was reproducible upstream so reported
> everything w.r.t upstream code but initially found on 5.15.y)
No worry about this, I will add a "Cc: " tag
to the
Hi Nam,
+CC stable( heads up as this is a regression affecting 5.15.y and
probably others, Greg: this was reproducible upstream so reported
everything w.r.t upstream code but initially found on 5.15.y)
On 19/04/24 20:29, Nam Cao wrote:
On 2024-04-18 Harshit Mogalapalli wrote:
While
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
On 2024-04-18 Patrik Jakobsson wrote:
> On Thu, Apr 18, 2024 at 4:05 PM Nam Cao 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()
> > >
On 2024-04-18 Harshit Mogalapalli wrote:
> While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
> bug in fb_deferred_io_work()
I think the problem is because of improper offset address calculation.
The kernel calculate address offset with:
offset = vmf->address -
Hi Takashi,
On 19/04/24 13:15, Takashi Iwai wrote:
On Fri, 19 Apr 2024 09:39:09 +0200,
Then later on, the commit 33cd6ea9c067 changed cancel_*() to
flush_delayed_work() blindly, and the known problem resurfaced again.
I have reverted that commit, but still could see some other task hung
On Fri, Apr 19, 2024 at 9:45 AM Takashi Iwai wrote:
>
> On Fri, 19 Apr 2024 09:39:09 +0200,
> Harshit Mogalapalli wrote:
> >
> > Hi Takashi,
> >
> > On 19/04/24 12:14, Takashi Iwai wrote:
> > > On Thu, 18 Apr 2024 21:29:57 +0200,
> > > Helge Deller wrote:
> > >>
> > >> On 4/18/24 16:26, Takashi
On Fri, 19 Apr 2024 09:39:09 +0200,
Harshit Mogalapalli wrote:
>
> Hi Takashi,
>
> On 19/04/24 12:14, Takashi Iwai wrote:
> > On Thu, 18 Apr 2024 21:29:57 +0200,
> > Helge Deller wrote:
> >>
> >> On 4/18/24 16:26, Takashi Iwai wrote:
> >>> On Thu, 18 Apr 2024 16:06:52 +0200,
> >>> Nam Cao
Hi Takashi,
On 19/04/24 12:14, Takashi Iwai wrote:
On Thu, 18 Apr 2024 21:29:57 +0200,
Helge Deller wrote:
On 4/18/24 16:26, Takashi Iwai wrote:
On Thu, 18 Apr 2024 16:06:52 +0200,
Nam Cao wrote:
On 2024-04-18 Harshit Mogalapalli wrote:
While fuzzing 5.15.y kernel with Syzkaller, we
Hi Nam,
On 18/04/24 19:36, Nam Cao wrote:
On 2024-04-18 Harshit Mogalapalli wrote:
While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
bug in fb_deferred_io_work()
Which framebuffer device are you using exactly? It is possible that
the problem is with the device driver,
Hi Patrik,
On 18/04/24 18:44, Patrik Jakobsson wrote:
On Thu, Apr 18, 2024 at 2:40 PM Harshit Mogalapalli
wrote:
Hi,
While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
bug in fb_deferred_io_work()
This is in 5.15.149 tag, and this is introduced by a set of commits:
On Thu, 18 Apr 2024 21:29:57 +0200,
Helge Deller wrote:
>
> On 4/18/24 16:26, Takashi Iwai wrote:
> > On Thu, 18 Apr 2024 16:06:52 +0200,
> > Nam Cao wrote:
> >>
> >> On 2024-04-18 Harshit Mogalapalli wrote:
> >>> While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
> >>> bug
On 4/18/24 16:26, Takashi Iwai wrote:
On Thu, 18 Apr 2024 16:06:52 +0200,
Nam Cao wrote:
On 2024-04-18 Harshit Mogalapalli wrote:
While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
bug in fb_deferred_io_work()
Which framebuffer device are you using exactly? It is
On Thu, Apr 18, 2024 at 4:05 PM Nam Cao 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
On Thu, 18 Apr 2024 16:06:52 +0200,
Nam Cao wrote:
>
> On 2024-04-18 Harshit Mogalapalli wrote:
> > While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
> > bug in fb_deferred_io_work()
>
> Which framebuffer device are you using exactly? It is possible that
> the problem is
On 2024-04-18 Harshit Mogalapalli wrote:
> While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
> bug in fb_deferred_io_work()
Which framebuffer device are you using exactly? It is possible that
the problem is with the device driver, not core framebuffer.
Best regards,
Nam
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
On Thu, Apr 18, 2024 at 2:40 PM Harshit Mogalapalli
wrote:
>
> Hi,
>
> While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
> bug in fb_deferred_io_work()
>
>
> This is in 5.15.149 tag, and this is introduced by a set of commits:
>
> 2655757a3f10 fbdev: flush deferred IO
Hi,
While fuzzing 5.15.y kernel with Syzkaller, we noticed a INFO: task hung
bug in fb_deferred_io_work()
This is in 5.15.149 tag, and this is introduced by a set of commits:
2655757a3f10 fbdev: flush deferred IO before closing
15492bab7393 fbdev: Fix incorrect page mapping clearance at
21 matches
Mail list logo
