On PPC I''m having a race with do_softirq, so I''m trying to figure out how x86 calls it. As far as I can tell, it looks like this: apic_timer_interrupt <interrupts disabled> smp_apic_timer_interrupt [raise TIMER_SOFTIRQ)] ret_from_intr test_all_events [sees TIMER_SOFTIRQ] <interrupts enabled> do_softirq() *** pending = softirq_pending(cpu); ASSERT(pending != 0); ... <interrupts disabled> iret What confuses me is that any other interrupt could come in at point *** above, right? That interrupt will follow a very similar path, calling do_softirq again, and handle TIMER_SOFTIRQ. Then when the first do_softirq resumes, the ASSERT will trip. What am I missing? -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On 2 Sep 2005, at 00:14, Hollis Blanchard wrote:> What confuses me is that any other interrupt could come in at point > *** above, > right? That interrupt will follow a very similar path, calling > do_softirq > again, and handle TIMER_SOFTIRQ. Then when the first do_softirq > resumes, the > ASSERT will trip. > > What am I missing?You shouldn''t call do_softirq() from nested Xen activations (this is unlike Linux, which is happy to do softirq work from arbitrary interrupt contexts). For example, the main places where arch/x86 calls do_softirq are from within the idle loop, and in our code that exits a Xen activation we have code along the lines of: if (softirq_pending() and returning to guest context) do_softirq(); If you do softirq work in nested interrupt contexts in Xen you will find all kinds of bad races, because the locking strategies assume you don;t do this (most spinlocks are acquired without disabling interrupts, for example). -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
On Sep 2, 2005, at 3:20 AM, Keir Fraser wrote:> > On 2 Sep 2005, at 00:14, Hollis Blanchard wrote: > >> What confuses me is that any other interrupt could come in at point >> *** above, >> right? That interrupt will follow a very similar path, calling >> do_softirq >> again, and handle TIMER_SOFTIRQ. Then when the first do_softirq >> resumes, the >> ASSERT will trip. > > You shouldn''t call do_softirq() from nested Xen activations (this is > unlike Linux, which is happy to do softirq work from arbitrary > interrupt contexts).Ah ha, this was the tip I needed. The test I had overlooked in ret_from_intr was this: movl UREGS_eflags(%esp),%eax movb UREGS_cs(%esp),%al testl $(3|X86_EFLAGS_VM),%eax jnz test_all_events I guess that is cleverly testing both the privilege level being returned to and the virtual 8086 mode bit. Thanks! -- Hollis Blanchard IBM Linux Technology Center _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel