Skip to content

Commit d8636a2

Browse files
committed
fbcon: fix race condition between console lock and cursor timer (v1.1)
So we've had a fair few reports of fbcon handover breakage between efi/vesafb and i915 surface recently, so I dedicated a couple of days to finding the problem. Essentially the last thing we saw was the conflicting framebuffer message and that was all. So after much tracing with direct netconsole writes (printks under console_lock not so useful), I think I found the race. Thread A (driver load) Thread B (timer thread) unbind_con_driver -> | bind_con_driver -> | vc->vc_sw->con_deinit -> | fbcon_deinit -> | console_lock() | | | | fbcon_flashcursor timer fires | console_lock() <- blocked for A | | fbcon_del_cursor_timer -> del_timer_sync (BOOM) Of course because all of this is under the console lock, we never see anything, also since we also just unbound the active console guess what we never see anything. Hopefully this fixes the problem for anyone seeing vesafb->kms driver handoff. v1.1: add comment suggestion from Alan. Cc: [email protected] Signed-off-by: Dave Airlie <[email protected]>
1 parent 27fc4f1 commit d8636a2

File tree

1 file changed

+8
-1
lines changed

1 file changed

+8
-1
lines changed

drivers/video/console/fbcon.c

Lines changed: 8 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -372,8 +372,15 @@ static void fb_flashcursor(struct work_struct *work)
372372
struct vc_data *vc = NULL;
373373
int c;
374374
int mode;
375+
int ret;
376+
377+
/* FIXME: we should sort out the unbind locking instead */
378+
/* instead we just fail to flash the cursor if we can't get
379+
* the lock instead of blocking fbcon deinit */
380+
ret = console_trylock();
381+
if (ret == 0)
382+
return;
375383

376-
console_lock();
377384
if (ops && ops->currcon != -1)
378385
vc = vc_cons[ops->currcon].d;
379386

0 commit comments

Comments
 (0)