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 more quoted lines
/* return 1 for timeout, otherwise 0 */
quoted hunk
+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:
quoted hunk
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