Keir Fraser <keir@xxxxxxxxxxxxx> writes:
> On 14/12/06 10:58, "Atsushi SAKAI" <sakaia@xxxxxxxxxxxxxx> wrote:
>
>> I searched the code and found
>> the code in smp_call_function line337@linux/arch/ia64/kernel/smp.c
>> WARN_ON(irqs_disabled());
>> 
>> The call trace problem caused by spin_lock_irqsave()
>> in xenfb_update_screen@linux/drivers/xen/fbfront/xenfb.c
Thanks for debugging this, Atsushi!
>> Why you need to use spin_lock_irqsave in xenfb_update()?
>> I understand the locking but why irqsave is required at this point?
>
> The lock is used in fb_ops, vm_ops and kthread contexts. None of these are
> executed in IRQ context so irqsave is not needed. I'll remove it. I'm not
> sure whether you can call zap_page_range() even with a spinlock held
> though...
>
> -- Keir
You can't. This was spotted just yesterday in our internal review.
I'm working on a fix. If you could hold the removal of irqsave for a
bit, that would avoid merge conflicts.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel