[Xen-devel] xenfb issuing notify_remote_via_irq() too early

["Jan Beulich" <jbeulich@xxxxxxxxxx>]

After some changes resulting in the irq (since used as an array index) to
be converted to unsigned int, we're observing oopses resulting from xenfb
calling notify_remote_via_irq() with -1 as the irq argument. Clearly, the
two possible simple work-arounds would be to either make the event
channel code always tolerate and ignore invalid irq inputs or to prevent
the call to notify_remote_via_irq() in xenfb in that case. Neither would
fix the root issue here, though. (The reason this usually doesn't cause
any problems in the 2.6.18 tree is that the irq_info array apparently
always ends up being immediately preceded by a 32-bit padding field,
which has the nice effect of EVTCHN_VALID() yielding false for irq -1.)

The call tree which we could (and actually always should) get into that
state is xenfb_probe() -> register_framebuffer() -> fbcon_event_notify()
-> fbcon_fb_registered() -> fbcon_takeover() -> take_over_console()
-> bind_con_driver() -> visual_init() -> fbcon_init() -> xenfb_set_par().
Since xenfb_probe() calls register_framebuffer() before kthread_run()
and xenfb_connect_backend(), xenfb_thread() should find
info->resize_dpy always set to 1, and hence always go into
xenfb_do_resize() right away (which, depending on the timing, would
perhaps find info->irq still being -1).

There also is a comment right before the creation of the thread: "FIXME
should this be delayed until backend XenbusStateConnected?", but I'm
in particular not certain how to handle the error case if this indeed was
moved to the suggested place. An alternative would be to just swap
thread creation with the call to xenfb_connect_backend().

Otoh, the pv-ops fbfront gets away without a thread altogether (but
also differs in other ways from the 2.6.18 tree's variant), so it'd also
be interesting to understand what benefit (not) using a thread here
has.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel