WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

[Xen-ia64-devel] Re: [PATCH][MCA] avoid allocating memory in interrupt c

Hi Alex,

Sorry, I made a patch to take out vfree() outside of IRQ disabled.
I checked that the call trace did not come out on the SMP Dom0.

Thanks,
KAZ

Signed-off-by: Kazuhiro Suzuki <kaz@xxxxxxxxxxxxxx>


From: Alex Williamson <alex.williamson@xxxxxx>
Subject: Re: [PATCH][MCA] avoid allocating memory in interrupt context (was Re: 
[Xen-ia64-devel] [PATCH 2/3] xencomm consolidation: linux side)
Date: Tue, 04 Sep 2007 10:37:06 -0600

> On Sun, 2007-09-02 at 16:04 -0600, Alex Williamson wrote:
> > On Tue, 2007-08-28 at 20:48 +0900, SUZUKI Kazuhiro wrote:
> > > Hi,
> > > 
> > > The attached patch fixes to avoid allocating memory in interrupt
> > > context.
> > > I tried to allocate xencomm_handle in IA64_LOG_ALLOCATE instead of
> > > allocating each time.
> > 
> >    Applied.  Thanks,
> 
>    Oops, looks like this introduced another problem:
> 
> BUG: warning at 
> /home/awilliam/xen/20070902-patches/linux-2.6.18-xen.hg/arch/ia64/kernel/smp.c:341/smp_call_function()
> 
> Call Trace:
>  [<a00000010001d520>] show_stack+0x40/0xa0
>                                 sp=e0000001b51cfb70 bsp=e0000001b51c9588
>  [<a00000010001d5b0>] dump_stack+0x30/0x60
>                                 sp=e0000001b51cfd40 bsp=e0000001b51c9570
>  [<a000000100061b40>] smp_call_function+0x180/0x440
>                                 sp=e0000001b51cfd40 bsp=e0000001b51c9528
>  [<a000000100094fe0>] on_each_cpu+0x40/0x1c0
>                                 sp=e0000001b51cfd60 bsp=e0000001b51c94f0
>  [<a000000100060ed0>] smp_flush_tlb_all+0x30/0x60
>                                 sp=e0000001b51cfd60 bsp=e0000001b51c94d8
>  [<a000000100115250>] unmap_vm_area+0x390/0x440
>                                 sp=e0000001b51cfd60 bsp=e0000001b51c9490
>  [<a000000100115390>] __remove_vm_area+0x90/0x100
>                                 sp=e0000001b51cfd70 bsp=e0000001b51c9458
>  [<a000000100115430>] remove_vm_area+0x30/0x80
>                                 sp=e0000001b51cfd70 bsp=e0000001b51c9430
>  [<a0000001001154f0>] __vunmap+0x70/0x280
>                                 sp=e0000001b51cfd70 bsp=e0000001b51c9400
>  [<a000000100115950>] vfree+0x90/0xc0
>                                 sp=e0000001b51cfd70 bsp=e0000001b51c93d8
>  [<a00000010003ba40>] salinfo_log_release+0x140/0x260
>                                 sp=e0000001b51cfd70 bsp=e0000001b51c93a8
>  ...
> 
>    We can't vfree() with IRQs disabled.  Can you please find an
> alternate algorithm for freeing the log area and submit a follow up
> patch?  Thanks,
> 
>       Alex
> 
> -- 
> Alex Williamson                             HP Open Source & Linux Org.
> 
diff -r df2d73ab847a arch/ia64/kernel/salinfo.c
--- a/arch/ia64/kernel/salinfo.c        Tue Aug 28 12:44:22 2007 -0600
+++ b/arch/ia64/kernel/salinfo.c        Thu Sep 06 12:29:32 2007 +0900
@@ -408,6 +408,7 @@ salinfo_log_release(struct inode *inode,
 #ifdef CONFIG_XEN
                if (is_running_on_xen()) {
                        struct list_head *pos, *n;
+                       ia64_mca_xencomm_t *found_entry = NULL;
                        unsigned long flags;
 
                        spin_lock_irqsave(&ia64_mca_xencomm_lock, flags);
@@ -417,10 +418,15 @@ salinfo_log_release(struct inode *inode,
                                entry = list_entry(pos, ia64_mca_xencomm_t, 
list);
                                if (entry->record == data->log_buffer) {
                                        list_del(&entry->list);
-                                       vfree(entry);
+                                       found_entry = entry;
+                                       break;
                                }
                        }
                        spin_unlock_irqrestore(&ia64_mca_xencomm_lock, flags);
+                       if (found_entry) {
+                               xencomm_free(found_entry->handle);
+                               vfree(found_entry);
+                       }
                }
 #endif
                vfree(data->log_buffer);
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel