linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync
@ 2021-02-20 23:02 Tong Zhang
  2021-02-20 23:32 ` Randy Dunlap
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Tong Zhang @ 2021-02-20 23:02 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Sam Ravnborg, Randy Dunlap,
	Bartlomiej Zolnierkiewicz, Tong Zhang, dri-devel, linux-fbdev,
	linux-kernel

pm2fb_sync is called when doing /dev/fb read or write.
The original pm2fb_sync wait indefinitely on hardware flags which can
possibly stall kernel and make everything unresponsive.
Instead of waiting indefinitely, we can timeout to give user a chance to
get back control.

Signed-off-by: Tong Zhang <ztong0001@gmail.com>
---
 drivers/video/fbdev/pm2fb.c | 29 ++++++++++++++++++++++++++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 27893fa139b0..8578c64a0c54 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 idx, u32 v)
 
 #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
 #define WAIT_FIFO(p, a)
+#define WAIT_FIFO_TIMEOUT(p, a) (0)
 #else
 static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
 {
 	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
 		cpu_relax();
 }
+static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
+{
+	int timeout = 10000;
+	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
+		cpu_relax();
+		if (--timeout==0)
+			return 1;
+	}
+	return 0;
+}
 #endif
 
 /*
@@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info *info)
 static int pm2fb_sync(struct fb_info *info)
 {
 	struct pm2fb_par *par = info->par;
+	int timeout_sync = 10000;
+	int timeout_fifo;
 
-	WAIT_FIFO(par, 1);
+	if (WAIT_FIFO_TIMEOUT(par, 1))
+		goto end;
 	pm2_WR(par, PM2R_SYNC, 0);
 	mb();
 	do {
-		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
+		timeout_fifo = 10000;
+		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
 			cpu_relax();
-	} while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
+			if (--timeout_fifo==0)
+				goto end;
+		}
+		if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
+			break;
+	} while (--timeout_sync>0);
 
+end:
+	if ((!timeout_sync) || (!timeout_fifo))
+		printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
 	return 0;
 }
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-20 23:02 [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync Tong Zhang
@ 2021-02-20 23:32 ` Randy Dunlap
  2021-02-21  0:00   ` [PATCH v2] " Tong Zhang
  2021-02-21  0:00   ` [PATCH] " Tong Zhang
  2021-02-21  0:51 ` kernel test robot
  2021-02-21  2:02 ` kernel test robot
  2 siblings, 2 replies; 11+ messages in thread
From: Randy Dunlap @ 2021-02-20 23:32 UTC (permalink / raw)
  To: Tong Zhang, Gustavo A. R. Silva, Sam Ravnborg,
	Bartlomiej Zolnierkiewicz, dri-devel, linux-fbdev, linux-kernel

Hi--

On 2/20/21 3:02 PM, Tong Zhang wrote:
> pm2fb_sync is called when doing /dev/fb read or write.
> The original pm2fb_sync wait indefinitely on hardware flags which can
> possibly stall kernel and make everything unresponsive.
> Instead of waiting indefinitely, we can timeout to give user a chance to
> get back control.

Is this a real problem or theoretical?
Does someone still use this driver?


> Signed-off-by: Tong Zhang <ztong0001@gmail.com>
> ---
>  drivers/video/fbdev/pm2fb.c | 29 ++++++++++++++++++++++++++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
> index 27893fa139b0..8578c64a0c54 100644
> --- a/drivers/video/fbdev/pm2fb.c
> +++ b/drivers/video/fbdev/pm2fb.c
> @@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 idx, u32 v)
>  
>  #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
>  #define WAIT_FIFO(p, a)
> +#define WAIT_FIFO_TIMEOUT(p, a) (0)
>  #else
>  static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
>  {
>  	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
>  		cpu_relax();
>  }
> +static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)

drop      void       ^^^
It's already "int".
Did you compile this?

> +{
> +	int timeout = 10000;
> +	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
> +		cpu_relax();
> +		if (--timeout==0)

spaces around ==

> +			return 1;
> +	}
> +	return 0;
> +}
>  #endif
>  
>  /*
> @@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info *info)
>  static int pm2fb_sync(struct fb_info *info)
>  {
>  	struct pm2fb_par *par = info->par;
> +	int timeout_sync = 10000;
> +	int timeout_fifo;
>  
> -	WAIT_FIFO(par, 1);
> +	if (WAIT_FIFO_TIMEOUT(par, 1))
> +		goto end;
>  	pm2_WR(par, PM2R_SYNC, 0);
>  	mb();
>  	do {
> -		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
> +		timeout_fifo = 10000;
> +		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
>  			cpu_relax();
> -	} while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
> +			if (--timeout_fifo==0)

spaces around ==

> +				goto end;
> +		}
> +		if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
> +			break;
> +	} while (--timeout_sync>0);

spaces around >

>  
> +end:
> +	if ((!timeout_sync) || (!timeout_fifo))
> +		printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
>  	return 0;
>  }
>  
> 


thanks.
-- 
~Randy

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v2] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-20 23:32 ` Randy Dunlap
@ 2021-02-21  0:00   ` Tong Zhang
  2021-02-21  0:35     ` Randy Dunlap
  2021-02-21  0:00   ` [PATCH] " Tong Zhang
  1 sibling, 1 reply; 11+ messages in thread
From: Tong Zhang @ 2021-02-21  0:00 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Sam Ravnborg, Bartlomiej Zolnierkiewicz,
	Randy Dunlap, Tong Zhang, dri-devel, linux-fbdev, linux-kernel

pm2fb_sync is called when doing /dev/fb read or write.
The original pm2fb_sync wait indefinitely on hardware flags which can
possibly stall kernel and make everything unresponsive.
Instead of waiting indefinitely, we can timeout to give user a chance to
get back control.

[   39.503356] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda5194
[   39.503947] Call Trace:
[   39.504081]  <IRQ>
[   39.504193]  dump_stack+0x7d/0xa3
[   39.504377]  nmi_cpu_backtrace.cold+0x32/0x7e
[   39.504613]  ? lapic_can_unplug_cpu+0x70/0x70
[   39.504850]  nmi_trigger_cpumask_backtrace+0xdf/0x100
[   39.505121]  rcu_dump_cpu_stacks+0xed/0x130
[   39.505349]  rcu_sched_clock_irq.cold+0x3b1/0x61d
[   39.505602]  ? hrtimer_run_queues+0x2c/0x1b0
[   39.505833]  ? __acct_update_integrals+0x136/0x160
[   39.506091]  update_process_times+0xb9/0xf0
[   39.506317]  tick_sched_handle.isra.0+0x5c/0x80
[   39.506562]  tick_sched_timer+0x70/0x90
[   39.506770]  __hrtimer_run_queues+0x1c6/0x3e0
[   39.517095]  ? tick_sched_handle.isra.0+0x80/0x80
[   39.517349]  ? enqueue_hrtimer+0xd0/0xd0
[   39.517561]  ? _raw_write_lock_irqsave+0xd0/0xd0
[   39.517812]  ? ktime_get+0x45/0xb0
[   39.517997]  ? ktime_get_update_offsets_now+0x96/0x150
[   39.518273]  hrtimer_interrupt+0x1a0/0x340
[   39.518496]  __sysvec_apic_timer_interrupt+0x7f/0x160
[   39.518768]  asm_call_irq_on_stack+0xf/0x20
[   39.518997]  </IRQ>
[   39.519114]  sysvec_apic_timer_interrupt+0x6f/0x80
[   39.519372]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[   39.519647] RIP: 0010:pm2fb_sync+0x47/0x70 [pm2fb]
[   39.519907] Code: 89 ef e8 0c 87 2c c1 48 8b 53 08 31 c0 89 82 40 8c 00 00 0f ae f0 48 8b 53 08 1
[   39.520885] RSP: 0018:ffff88810a1f7df8 EFLAGS: 00000202
[   39.521165] RAX: 0000000072d5d49f RBX: ffff88810a034418 RCX: ffffc900000b0020
[   39.521542] RDX: ffffc900000b0000 RSI: 0000000000000246 RDI: ffff88810a034420
[   39.521920] RBP: ffff88810a034420 R08: 0000000000000000 R09: ffffed102143ef64
[   39.522297] R10: 0000000000000003 R11: ffffed102143ef63 R12: ffff88810a1f7ed0
[   39.522673] R13: ffff88810a034000 R14: ffffc90002800000 R15: ffff888109e5e000
[   39.523053]  ? pm2fb_sync+0x24/0x70 [pm2fb]
[   39.523280]  fb_write+0x1c2/0x2d0
[   39.523461]  vfs_write+0x108/0x380
[   39.523647]  ksys_write+0xb4/0x150
[   39.523832]  ? __ia32_sys_read+0x40/0x40
[   39.524043]  ? fpregs_assert_state_consistent+0x4d/0x60
[   39.524322]  do_syscall_64+0x33/0x40
[   39.524517]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   39.524788] RIP: 0033:0x7f5e50097970
[   39.524981] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 4
[   39.525952] RSP: 002b:00007ffec6895b38 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[   39.526352] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5e50097970
[   39.526726] RDX: 0000000000000200 RSI: 000056491a6ad000 RDI: 0000000000000001
[   39.537261] RBP: 0000000000000200 R08: 0000000000000000 R09: 000056491a6ad030
[   39.537633] R10: 0000000000000871 R11: 0000000000000246 R12: 0000000000000800
[   39.538008] R13: 000056491a6ad000 R14: 0000000000000200 R15: 0000000000000000

Signed-off-by: Tong Zhang <ztong0001@gmail.com>
---
 v2: fix typo and add console log according to Randy's <rdunlap@infradead.org> comment

 drivers/video/fbdev/pm2fb.c | 29 ++++++++++++++++++++++++++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 27893fa139b0..d6731e04252f 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 idx, u32 v)
 
 #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
 #define WAIT_FIFO(p, a)
+#define WAIT_FIFO_TIMEOUT(p, a) (0)
 #else
 static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
 {
 	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
 		cpu_relax();
 }
+static inline int WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
+{
+	int timeout = 10000;
+	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
+		cpu_relax();
+		if (--timeout == 0)
+			return 1;
+	}
+	return 0;
+}
 #endif
 
 /*
@@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info *info)
 static int pm2fb_sync(struct fb_info *info)
 {
 	struct pm2fb_par *par = info->par;
+	int timeout_sync = 10000;
+	int timeout_fifo;
 
-	WAIT_FIFO(par, 1);
+	if (WAIT_FIFO_TIMEOUT(par, 1))
+		goto end;
 	pm2_WR(par, PM2R_SYNC, 0);
 	mb();
 	do {
-		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
+		timeout_fifo = 10000;
+		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
 			cpu_relax();
-	} while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
+			if (--timeout_fifo == 0)
+				goto end;
+		}
+		if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
+			break;
+	} while (--timeout_sync > 0);
 
+end:
+	if ((!timeout_sync) || (!timeout_fifo))
+		printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
 	return 0;
 }
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-20 23:32 ` Randy Dunlap
  2021-02-21  0:00   ` [PATCH v2] " Tong Zhang
@ 2021-02-21  0:00   ` Tong Zhang
  2021-02-24 11:35     ` Geert Uytterhoeven
  1 sibling, 1 reply; 11+ messages in thread
From: Tong Zhang @ 2021-02-21  0:00 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Gustavo A. R. Silva, Sam Ravnborg, Bartlomiej Zolnierkiewicz,
	dri-devel, linux-fbdev, open list

Hi Randy,
Thanks for the comment.
I currently have this problem on my machine.
I have submitted a revised patch -- which includes the console log.
Thanks!
- Tong

On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Hi--
>
> On 2/20/21 3:02 PM, Tong Zhang wrote:
> > pm2fb_sync is called when doing /dev/fb read or write.
> > The original pm2fb_sync wait indefinitely on hardware flags which can
> > possibly stall kernel and make everything unresponsive.
> > Instead of waiting indefinitely, we can timeout to give user a chance to
> > get back control.
>
> Is this a real problem or theoretical?
> Does someone still use this driver?
>
>
> > Signed-off-by: Tong Zhang <ztong0001@gmail.com>
> > ---
> >  drivers/video/fbdev/pm2fb.c | 29 ++++++++++++++++++++++++++---
> >  1 file changed, 26 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
> > index 27893fa139b0..8578c64a0c54 100644
> > --- a/drivers/video/fbdev/pm2fb.c
> > +++ b/drivers/video/fbdev/pm2fb.c
> > @@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 idx, u32 v)
> >
> >  #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
> >  #define WAIT_FIFO(p, a)
> > +#define WAIT_FIFO_TIMEOUT(p, a) (0)
> >  #else
> >  static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
> >  {
> >       while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
> >               cpu_relax();
> >  }
> > +static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
>
> drop      void       ^^^
> It's already "int".
> Did you compile this?
>
> > +{
> > +     int timeout = 10000;
> > +     while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
> > +             cpu_relax();
> > +             if (--timeout==0)
>
> spaces around ==
>
> > +                     return 1;
> > +     }
> > +     return 0;
> > +}
> >  #endif
> >
> >  /*
> > @@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info *info)
> >  static int pm2fb_sync(struct fb_info *info)
> >  {
> >       struct pm2fb_par *par = info->par;
> > +     int timeout_sync = 10000;
> > +     int timeout_fifo;
> >
> > -     WAIT_FIFO(par, 1);
> > +     if (WAIT_FIFO_TIMEOUT(par, 1))
> > +             goto end;
> >       pm2_WR(par, PM2R_SYNC, 0);
> >       mb();
> >       do {
> > -             while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
> > +             timeout_fifo = 10000;
> > +             while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
> >                       cpu_relax();
> > -     } while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
> > +                     if (--timeout_fifo==0)
>
> spaces around ==
>
> > +                             goto end;
> > +             }
> > +             if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
> > +                     break;
> > +     } while (--timeout_sync>0);
>
> spaces around >
>
> >
> > +end:
> > +     if ((!timeout_sync) || (!timeout_fifo))
> > +             printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
> >       return 0;
> >  }
> >
> >
>
>
> thanks.
> --
> ~Randy

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-21  0:00   ` [PATCH v2] " Tong Zhang
@ 2021-02-21  0:35     ` Randy Dunlap
  2021-02-21  2:28       ` [PATCH v3] " Tong Zhang
  2021-02-21  2:34       ` [PATCH v2] " Tong Zhang
  0 siblings, 2 replies; 11+ messages in thread
From: Randy Dunlap @ 2021-02-21  0:35 UTC (permalink / raw)
  To: Tong Zhang, Gustavo A. R. Silva, Sam Ravnborg,
	Bartlomiej Zolnierkiewicz, dri-devel, linux-fbdev, linux-kernel

On 2/20/21 4:00 PM, Tong Zhang wrote:
> pm2fb_sync is called when doing /dev/fb read or write.
> The original pm2fb_sync wait indefinitely on hardware flags which can
> possibly stall kernel and make everything unresponsive.
> Instead of waiting indefinitely, we can timeout to give user a chance to
> get back control.
> 
> [   39.503356] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda5194
> [   39.503947] Call Trace:
> [   39.504081]  <IRQ>
> [   39.504193]  dump_stack+0x7d/0xa3
> [   39.504377]  nmi_cpu_backtrace.cold+0x32/0x7e
> [   39.504613]  ? lapic_can_unplug_cpu+0x70/0x70
> [   39.504850]  nmi_trigger_cpumask_backtrace+0xdf/0x100
> [   39.505121]  rcu_dump_cpu_stacks+0xed/0x130
> [   39.505349]  rcu_sched_clock_irq.cold+0x3b1/0x61d
> [   39.505602]  ? hrtimer_run_queues+0x2c/0x1b0
> [   39.505833]  ? __acct_update_integrals+0x136/0x160
> [   39.506091]  update_process_times+0xb9/0xf0
> [   39.506317]  tick_sched_handle.isra.0+0x5c/0x80
> [   39.506562]  tick_sched_timer+0x70/0x90
> [   39.506770]  __hrtimer_run_queues+0x1c6/0x3e0
> [   39.517095]  ? tick_sched_handle.isra.0+0x80/0x80
> [   39.517349]  ? enqueue_hrtimer+0xd0/0xd0
> [   39.517561]  ? _raw_write_lock_irqsave+0xd0/0xd0
> [   39.517812]  ? ktime_get+0x45/0xb0
> [   39.517997]  ? ktime_get_update_offsets_now+0x96/0x150
> [   39.518273]  hrtimer_interrupt+0x1a0/0x340
> [   39.518496]  __sysvec_apic_timer_interrupt+0x7f/0x160
> [   39.518768]  asm_call_irq_on_stack+0xf/0x20
> [   39.518997]  </IRQ>
> [   39.519114]  sysvec_apic_timer_interrupt+0x6f/0x80
> [   39.519372]  asm_sysvec_apic_timer_interrupt+0x12/0x20
> [   39.519647] RIP: 0010:pm2fb_sync+0x47/0x70 [pm2fb]
> [   39.519907] Code: 89 ef e8 0c 87 2c c1 48 8b 53 08 31 c0 89 82 40 8c 00 00 0f ae f0 48 8b 53 08 1
> [   39.520885] RSP: 0018:ffff88810a1f7df8 EFLAGS: 00000202
> [   39.521165] RAX: 0000000072d5d49f RBX: ffff88810a034418 RCX: ffffc900000b0020
> [   39.521542] RDX: ffffc900000b0000 RSI: 0000000000000246 RDI: ffff88810a034420
> [   39.521920] RBP: ffff88810a034420 R08: 0000000000000000 R09: ffffed102143ef64
> [   39.522297] R10: 0000000000000003 R11: ffffed102143ef63 R12: ffff88810a1f7ed0
> [   39.522673] R13: ffff88810a034000 R14: ffffc90002800000 R15: ffff888109e5e000
> [   39.523053]  ? pm2fb_sync+0x24/0x70 [pm2fb]
> [   39.523280]  fb_write+0x1c2/0x2d0
> [   39.523461]  vfs_write+0x108/0x380
> [   39.523647]  ksys_write+0xb4/0x150
> [   39.523832]  ? __ia32_sys_read+0x40/0x40
> [   39.524043]  ? fpregs_assert_state_consistent+0x4d/0x60
> [   39.524322]  do_syscall_64+0x33/0x40
> [   39.524517]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [   39.524788] RIP: 0033:0x7f5e50097970
> [   39.524981] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 4
> [   39.525952] RSP: 002b:00007ffec6895b38 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
> [   39.526352] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5e50097970
> [   39.526726] RDX: 0000000000000200 RSI: 000056491a6ad000 RDI: 0000000000000001
> [   39.537261] RBP: 0000000000000200 R08: 0000000000000000 R09: 000056491a6ad030
> [   39.537633] R10: 0000000000000871 R11: 0000000000000246 R12: 0000000000000800
> [   39.538008] R13: 000056491a6ad000 R14: 0000000000000200 R15: 0000000000000000
> 
> Signed-off-by: Tong Zhang <ztong0001@gmail.com>
> ---
>  v2: fix typo and add console log according to Randy's <rdunlap@infradead.org> comment
> 
>  drivers/video/fbdev/pm2fb.c | 29 ++++++++++++++++++++++++++---
>  1 file changed, 26 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
> index 27893fa139b0..d6731e04252f 100644
> --- a/drivers/video/fbdev/pm2fb.c
> +++ b/drivers/video/fbdev/pm2fb.c
> @@ -183,12 +183,23 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 idx, u32 v)
>  
>  #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
>  #define WAIT_FIFO(p, a)
> +#define WAIT_FIFO_TIMEOUT(p, a) (0)
>  #else
>  static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
>  {
>  	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
>  		cpu_relax();
>  }

/* return 1 for timeout, otherwise 0 */
> +static inline int WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
> +{
> +	int timeout = 10000;
> +	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
> +		cpu_relax();
> +		if (--timeout == 0)
> +			return 1;
> +	}
> +	return 0;
> +}
>  #endif
>  
>  /*
> @@ -1031,15 +1042,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info *info)
>  static int pm2fb_sync(struct fb_info *info)
>  {
>  	struct pm2fb_par *par = info->par;
> +	int timeout_sync = 10000;
> +	int timeout_fifo;
>  
> -	WAIT_FIFO(par, 1);
> +	if (WAIT_FIFO_TIMEOUT(par, 1))
> +		goto end;

if the above goto happens, timeout_fifo is used but not initialized
at label end:

>  	pm2_WR(par, PM2R_SYNC, 0);
>  	mb();
>  	do {
> -		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
> +		timeout_fifo = 10000;
> +		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
>  			cpu_relax();
> -	} while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
> +			if (--timeout_fifo == 0)
> +				goto end;
> +		}
> +		if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
> +			break;
> +	} while (--timeout_sync > 0);
>  
> +end:
> +	if ((!timeout_sync) || (!timeout_fifo))
> +		printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
>  	return 0;
>  }
>  
> 

I suppose the rest of the patch is OK since it works for you.

I don't know any of this code. It would be nice to know what some
of those pm2_RD(par, SOME_REG) mean so that I could sort of
understand what it is doing, but don't go spending time on it
just for me. It's not worth doing that IMO.


-- 
~Randy


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-20 23:02 [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync Tong Zhang
  2021-02-20 23:32 ` Randy Dunlap
@ 2021-02-21  0:51 ` kernel test robot
  2021-02-21  2:02 ` kernel test robot
  2 siblings, 0 replies; 11+ messages in thread
From: kernel test robot @ 2021-02-21  0:51 UTC (permalink / raw)
  To: Tong Zhang, Gustavo A. R. Silva, Sam Ravnborg, Randy Dunlap,
	Bartlomiej Zolnierkiewicz, dri-devel, linux-fbdev, linux-kernel
  Cc: kbuild-all

[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]

Hi Tong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.11 next-20210219]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Tong-Zhang/video-fbdev-pm2fb-avoid-stall-on-fb_sync/20210221-070421
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git f40ddce88593482919761f74910f42f4b84c004b
config: i386-randconfig-s002-20210221 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.3-229-g60c1f270-dirty
        # https://github.com/0day-ci/linux/commit/77b85e0ba17f78b0335bf283901691ec3942dec3
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Tong-Zhang/video-fbdev-pm2fb-avoid-stall-on-fb_sync/20210221-070421
        git checkout 77b85e0ba17f78b0335bf283901691ec3942dec3
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=i386 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All error/warnings (new ones prefixed by >>):

>> drivers/video/fbdev/pm2fb.c:193:1: warning: 'inline' is not at beginning of declaration [-Wold-style-declaration]
     193 | static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
         | ^~~~~~
>> drivers/video/fbdev/pm2fb.c:193:19: error: two or more data types in declaration specifiers
     193 | static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
         |                   ^~~~


vim +193 drivers/video/fbdev/pm2fb.c

   183	
   184	#ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
   185	#define WAIT_FIFO(p, a)
   186	#define WAIT_FIFO_TIMEOUT(p, a) (0)
   187	#else
   188	static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
   189	{
   190		while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
   191			cpu_relax();
   192	}
 > 193	static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
   194	{
   195		int timeout = 10000;
   196		while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
   197			cpu_relax();
   198			if (--timeout==0)
   199				return 1;
   200		}
   201		return 0;
   202	}
   203	#endif
   204	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 31380 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-20 23:02 [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync Tong Zhang
  2021-02-20 23:32 ` Randy Dunlap
  2021-02-21  0:51 ` kernel test robot
@ 2021-02-21  2:02 ` kernel test robot
  2 siblings, 0 replies; 11+ messages in thread
From: kernel test robot @ 2021-02-21  2:02 UTC (permalink / raw)
  To: Tong Zhang, Gustavo A. R. Silva, Sam Ravnborg, Randy Dunlap,
	Bartlomiej Zolnierkiewicz, dri-devel, linux-fbdev, linux-kernel
  Cc: kbuild-all, clang-built-linux

[-- Attachment #1: Type: text/plain, Size: 2613 bytes --]

Hi Tong,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v5.11 next-20210219]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Tong-Zhang/video-fbdev-pm2fb-avoid-stall-on-fb_sync/20210221-070421
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git f40ddce88593482919761f74910f42f4b84c004b
config: x86_64-randconfig-a003-20210221 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # install x86_64 cross compiling tool for clang build
        # apt-get install binutils-x86-64-linux-gnu
        # https://github.com/0day-ci/linux/commit/77b85e0ba17f78b0335bf283901691ec3942dec3
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Tong-Zhang/video-fbdev-pm2fb-avoid-stall-on-fb_sync/20210221-070421
        git checkout 77b85e0ba17f78b0335bf283901691ec3942dec3
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

>> drivers/video/fbdev/pm2fb.c:193:19: error: cannot combine with previous 'int' declaration specifier
   static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
                     ^
   1 error generated.


vim +/int +193 drivers/video/fbdev/pm2fb.c

   183	
   184	#ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
   185	#define WAIT_FIFO(p, a)
   186	#define WAIT_FIFO_TIMEOUT(p, a) (0)
   187	#else
   188	static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
   189	{
   190		while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
   191			cpu_relax();
   192	}
 > 193	static int inline void WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
   194	{
   195		int timeout = 10000;
   196		while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
   197			cpu_relax();
   198			if (--timeout==0)
   199				return 1;
   200		}
   201		return 0;
   202	}
   203	#endif
   204	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 31388 bytes --]

^ permalink raw reply	[flat|nested] 11+ messages in thread

* [PATCH v3] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-21  0:35     ` Randy Dunlap
@ 2021-02-21  2:28       ` Tong Zhang
  2021-02-21  2:34       ` [PATCH v2] " Tong Zhang
  1 sibling, 0 replies; 11+ messages in thread
From: Tong Zhang @ 2021-02-21  2:28 UTC (permalink / raw)
  To: Gustavo A. R. Silva, Sam Ravnborg, Tong Zhang, Randy Dunlap,
	Bartlomiej Zolnierkiewicz, dri-devel, linux-fbdev, linux-kernel

pm2fb_sync is called when doing /dev/fb read or write.
The original pm2fb_sync wait indefinitely on hardware flags which can
possibly stall kernel and make everything unresponsive.
Instead of waiting indefinitely, we can timeout to give user a chance to
get back control.

[   39.503356] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda5194
[   39.503947] Call Trace:
[   39.504081]  <IRQ>
[   39.504193]  dump_stack+0x7d/0xa3
[   39.504377]  nmi_cpu_backtrace.cold+0x32/0x7e
[   39.504613]  ? lapic_can_unplug_cpu+0x70/0x70
[   39.504850]  nmi_trigger_cpumask_backtrace+0xdf/0x100
[   39.505121]  rcu_dump_cpu_stacks+0xed/0x130
[   39.505349]  rcu_sched_clock_irq.cold+0x3b1/0x61d
[   39.505602]  ? hrtimer_run_queues+0x2c/0x1b0
[   39.505833]  ? __acct_update_integrals+0x136/0x160
[   39.506091]  update_process_times+0xb9/0xf0
[   39.506317]  tick_sched_handle.isra.0+0x5c/0x80
[   39.506562]  tick_sched_timer+0x70/0x90
[   39.506770]  __hrtimer_run_queues+0x1c6/0x3e0
[   39.517095]  ? tick_sched_handle.isra.0+0x80/0x80
[   39.517349]  ? enqueue_hrtimer+0xd0/0xd0
[   39.517561]  ? _raw_write_lock_irqsave+0xd0/0xd0
[   39.517812]  ? ktime_get+0x45/0xb0
[   39.517997]  ? ktime_get_update_offsets_now+0x96/0x150
[   39.518273]  hrtimer_interrupt+0x1a0/0x340
[   39.518496]  __sysvec_apic_timer_interrupt+0x7f/0x160
[   39.518768]  asm_call_irq_on_stack+0xf/0x20
[   39.518997]  </IRQ>
[   39.519114]  sysvec_apic_timer_interrupt+0x6f/0x80
[   39.519372]  asm_sysvec_apic_timer_interrupt+0x12/0x20
[   39.519647] RIP: 0010:pm2fb_sync+0x47/0x70 [pm2fb]
[   39.519907] Code: 89 ef e8 0c 87 2c c1 48 8b 53 08 31 c0 89 82 40 8c 00 00 0f ae f0 48 8b 53 08 1
[   39.520885] RSP: 0018:ffff88810a1f7df8 EFLAGS: 00000202
[   39.521165] RAX: 0000000072d5d49f RBX: ffff88810a034418 RCX: ffffc900000b0020
[   39.521542] RDX: ffffc900000b0000 RSI: 0000000000000246 RDI: ffff88810a034420
[   39.521920] RBP: ffff88810a034420 R08: 0000000000000000 R09: ffffed102143ef64
[   39.522297] R10: 0000000000000003 R11: ffffed102143ef63 R12: ffff88810a1f7ed0
[   39.522673] R13: ffff88810a034000 R14: ffffc90002800000 R15: ffff888109e5e000
[   39.523053]  ? pm2fb_sync+0x24/0x70 [pm2fb]
[   39.523280]  fb_write+0x1c2/0x2d0
[   39.523461]  vfs_write+0x108/0x380
[   39.523647]  ksys_write+0xb4/0x150
[   39.523832]  ? __ia32_sys_read+0x40/0x40
[   39.524043]  ? fpregs_assert_state_consistent+0x4d/0x60
[   39.524322]  do_syscall_64+0x33/0x40
[   39.524517]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[   39.524788] RIP: 0033:0x7f5e50097970
[   39.524981] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 4
[   39.525952] RSP: 002b:00007ffec6895b38 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[   39.526352] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5e50097970
[   39.526726] RDX: 0000000000000200 RSI: 000056491a6ad000 RDI: 0000000000000001
[   39.537261] RBP: 0000000000000200 R08: 0000000000000000 R09: 000056491a6ad030
[   39.537633] R10: 0000000000000871 R11: 0000000000000246 R12: 0000000000000800
[   39.538008] R13: 000056491a6ad000 R14: 0000000000000200 R15: 0000000000000000

Signed-off-by: Tong Zhang <ztong0001@gmail.com>
---
 v3: initialize timeout_fifo to 0, and added comment for WAIT_FIFO_TIMEOUT
 v2: fix typo and add console log according to Randy's <rdunlap@infradead.org> comment
 drivers/video/fbdev/pm2fb.c | 30 +++++++++++++++++++++++++++---
 1 file changed, 27 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/pm2fb.c b/drivers/video/fbdev/pm2fb.c
index 27893fa139b0..37db7e740221 100644
--- a/drivers/video/fbdev/pm2fb.c
+++ b/drivers/video/fbdev/pm2fb.c
@@ -183,12 +183,24 @@ static inline void pm2v_RDAC_WR(struct pm2fb_par *p, s32 idx, u32 v)
 
 #ifdef CONFIG_FB_PM2_FIFO_DISCONNECT
 #define WAIT_FIFO(p, a)
+#define WAIT_FIFO_TIMEOUT(p, a) (0)
 #else
 static inline void WAIT_FIFO(struct pm2fb_par *p, u32 a)
 {
 	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a)
 		cpu_relax();
 }
+/* return 1 for timeout, otherwise 0 */
+static inline int WAIT_FIFO_TIMEOUT(struct pm2fb_par *p, u32 a)
+{
+	int timeout = 10000;
+	while (pm2_RD(p, PM2R_IN_FIFO_SPACE) < a) {
+		cpu_relax();
+		if (--timeout == 0)
+			return 1;
+	}
+	return 0;
+}
 #endif
 
 /*
@@ -1031,15 +1043,27 @@ static int pm2fb_blank(int blank_mode, struct fb_info *info)
 static int pm2fb_sync(struct fb_info *info)
 {
 	struct pm2fb_par *par = info->par;
+	int timeout_sync = 10000;
+	int timeout_fifo = 0;
 
-	WAIT_FIFO(par, 1);
+	if (WAIT_FIFO_TIMEOUT(par, 1))
+		goto end;
 	pm2_WR(par, PM2R_SYNC, 0);
 	mb();
 	do {
-		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0)
+		timeout_fifo = 10000;
+		while (pm2_RD(par, PM2R_OUT_FIFO_WORDS) == 0) {
 			cpu_relax();
-	} while (pm2_RD(par, PM2R_OUT_FIFO) != PM2TAG(PM2R_SYNC));
+			if (--timeout_fifo == 0)
+				goto end;
+		}
+		if (pm2_RD(par, PM2R_OUT_FIFO) == PM2TAG(PM2R_SYNC))
+			break;
+	} while (--timeout_sync > 0);
 
+end:
+	if ((!timeout_sync) || (!timeout_fifo))
+		printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
 	return 0;
 }
 
-- 
2.25.1


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH v2] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-21  0:35     ` Randy Dunlap
  2021-02-21  2:28       ` [PATCH v3] " Tong Zhang
@ 2021-02-21  2:34       ` Tong Zhang
  1 sibling, 0 replies; 11+ messages in thread
From: Tong Zhang @ 2021-02-21  2:34 UTC (permalink / raw)
  To: Randy Dunlap
  Cc: Gustavo A. R. Silva, Sam Ravnborg, Bartlomiej Zolnierkiewicz,
	dri-devel, linux-fbdev, open list

On Sat, Feb 20, 2021 at 7:36 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> I suppose the rest of the patch is OK since it works for you.
>
> I don't know any of this code. It would be nice to know what some
> of those pm2_RD(par, SOME_REG) mean so that I could sort of
> understand what it is doing, but don't go spending time on it
> just for me. It's not worth doing that IMO.
>
>
> --
> ~Randy

Thank you Randy. I have sent another revision.
I am also curious about those registers -- but it is hard to
accurately figure it out without datasheet --
my speculation is that it calls the device to do some sort of frame
buffer synchronizations here
Thanks,
- Tong

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-21  0:00   ` [PATCH] " Tong Zhang
@ 2021-02-24 11:35     ` Geert Uytterhoeven
  2021-02-24 12:24       ` Tong Zhang
  0 siblings, 1 reply; 11+ messages in thread
From: Geert Uytterhoeven @ 2021-02-24 11:35 UTC (permalink / raw)
  To: Tong Zhang
  Cc: Randy Dunlap, Gustavo A. R. Silva, Sam Ravnborg,
	Bartlomiej Zolnierkiewicz, DRI Development,
	Linux Fbdev development list, open list

Hi Tong,

On Sun, Feb 21, 2021 at 1:05 AM Tong Zhang <ztong0001@gmail.com> wrote:
> On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> > On 2/20/21 3:02 PM, Tong Zhang wrote:
> > > pm2fb_sync is called when doing /dev/fb read or write.
> > > The original pm2fb_sync wait indefinitely on hardware flags which can
> > > possibly stall kernel and make everything unresponsive.
> > > Instead of waiting indefinitely, we can timeout to give user a chance to
> > > get back control.
> >
> > Is this a real problem or theoretical?
> > Does someone still use this driver?
>
> I currently have this problem on my machine.
> I have submitted a revised patch -- which includes the console log.

Your machine is "QEMU Standard"?
Can this happen on real hardware, too, or is this a deficiency in QEMU,
which should be fixed there?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync
  2021-02-24 11:35     ` Geert Uytterhoeven
@ 2021-02-24 12:24       ` Tong Zhang
  0 siblings, 0 replies; 11+ messages in thread
From: Tong Zhang @ 2021-02-24 12:24 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Randy Dunlap, Gustavo A. R. Silva, Sam Ravnborg,
	Bartlomiej Zolnierkiewicz, DRI Development,
	Linux Fbdev development list, open list

Hi Geert,
IMHO - QEMU is irrelevant here. since I can do passthrough --
in fact -- many drivers do use timeout in .fb_sync
e.g. i810fb_sync(), nouveau_fbcon_sync(), sm501fb_sync() etc..
I believe the correct behaviour should be a timeout wait instead of
waiting indefinitely.
- Tong

On Wed, Feb 24, 2021 at 6:35 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Tong,
>
> On Sun, Feb 21, 2021 at 1:05 AM Tong Zhang <ztong0001@gmail.com> wrote:
> > On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap <rdunlap@infradead.org> wrote:
> > > On 2/20/21 3:02 PM, Tong Zhang wrote:
> > > > pm2fb_sync is called when doing /dev/fb read or write.
> > > > The original pm2fb_sync wait indefinitely on hardware flags which can
> > > > possibly stall kernel and make everything unresponsive.
> > > > Instead of waiting indefinitely, we can timeout to give user a chance to
> > > > get back control.
> > >
> > > Is this a real problem or theoretical?
> > > Does someone still use this driver?
> >
> > I currently have this problem on my machine.
> > I have submitted a revised patch -- which includes the console log.
>
> Your machine is "QEMU Standard"?
> Can this happen on real hardware, too, or is this a deficiency in QEMU,
> which should be fixed there?
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2021-02-24 12:25 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-20 23:02 [PATCH] video: fbdev: pm2fb: avoid stall on fb_sync Tong Zhang
2021-02-20 23:32 ` Randy Dunlap
2021-02-21  0:00   ` [PATCH v2] " Tong Zhang
2021-02-21  0:35     ` Randy Dunlap
2021-02-21  2:28       ` [PATCH v3] " Tong Zhang
2021-02-21  2:34       ` [PATCH v2] " Tong Zhang
2021-02-21  0:00   ` [PATCH] " Tong Zhang
2021-02-24 11:35     ` Geert Uytterhoeven
2021-02-24 12:24       ` Tong Zhang
2021-02-21  0:51 ` kernel test robot
2021-02-21  2:02 ` kernel test robot

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).