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 <[email protected]>
---
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
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 <[email protected]>
> ---
> 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
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 <[email protected]>
---
v2: fix typo and add console log according to Randy's <[email protected]> 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
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 <[email protected]> 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 <[email protected]>
> > ---
> > 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
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 <[email protected]>
> ---
> v2: fix typo and add console log according to Randy's <[email protected]> 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
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 <[email protected]>
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/[email protected]
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 <[email protected]>
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/[email protected]
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 <[email protected]>
---
v3: initialize timeout_fifo to 0, and added comment for WAIT_FIFO_TIMEOUT
v2: fix typo and add console log according to Randy's <[email protected]> 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
On Sat, Feb 20, 2021 at 7:36 PM Randy Dunlap <[email protected]> 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 Tong,
On Sun, Feb 21, 2021 at 1:05 AM Tong Zhang <[email protected]> wrote:
> On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap <[email protected]> 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 -- [email protected]
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 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 <[email protected]> wrote:
>
> Hi Tong,
>
> On Sun, Feb 21, 2021 at 1:05 AM Tong Zhang <[email protected]> wrote:
> > On Sat, Feb 20, 2021 at 6:33 PM Randy Dunlap <[email protected]> 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 -- [email protected]
>
> 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