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; }
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))
pm2_WR(par, PM2R_SYNC, 0); mb(); do {goto end;
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))
return 0;printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
}
thanks.
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; }
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))
return 0;printk_ratelimited(KERN_WARNING "pm2fb: sync timeout!\n");
}
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.
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; }
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
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
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
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
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-... 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/77b85e0ba17f78b0335bf283901691ec3942... 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
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-... 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/77b85e0ba17f78b0335bf283901691ec3942... 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
dri-devel@lists.freedesktop.org