Rescheduling over the IRQ log syncer is a source of infinite
recursion, via preempt_schedule().

Besides, rescheduling eagerly (if CONFIG_PREEMPT) after a virtual IRQ
has been dispatched directly from the syncer is useless. If such virq
was dispatched over a real IRQ context, the kernel exit code (entry.S)
should notice the opportunity for preemption and reschedule. Likewise,
if the virq was posted from a kernel context
(e.g. ipipe_post_irq_root()), a rescheduling point will certainly be
traversed before the kernel is exited or goes idle.