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: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>

Changed files
+8 -1
drivers
video
console
+8 -1
drivers/video/console/fbcon.c
··· 372 372 struct vc_data *vc = NULL; 373 373 int c; 374 374 int mode; 375 + int ret; 375 376 376 - console_lock(); 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; 383 + 377 384 if (ops && ops->currcon != -1) 378 385 vc = vc_cons[ops->currcon].d; 379 386