Jan Beulich
2008-Nov-18 10:19 UTC
[Xen-devel] xenfb issuing notify_remote_via_irq() too early
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@lists.xensource.com http://lists.xensource.com/xen-devel