lkml.org 
[lkml]   [2008]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subjectvm_unmap_aliases and Xen
I've been having a few problems with Xen, I suspect as a result of the 
lazy unmapping in vmalloc.c.

One immediate one is that vm_unmap_aliases() will oops if you call it
before vmalloc_init() is called, which can happen in the Xen case. RFC
patch below.

But the bigger problem I'm seeing is that despite calling
vm_unmap_aliases() at the pertinent places, I'm still seeing errors
resulting from stray aliases. Is it possible that vm_unmap_aliases()
could be missing some, or not completely synchronous?

Subject: vmap: cope with vm_unmap_aliases before vmalloc_init()

Xen can end up calling vm_unmap_aliases() before vmalloc_init() has
been called. In this case its safe to make it a simple no-op.

Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
diff -r 42c8b29f7ccf mm/vmalloc.c
--- a/mm/vmalloc.c Wed Oct 22 12:43:39 2008 -0700
+++ b/mm/vmalloc.c Wed Oct 22 21:39:00 2008 -0700
@@ -591,6 +591,8 @@

#define VMAP_BLOCK_SIZE (VMAP_BBMAP_BITS * PAGE_SIZE)

+static bool vmap_initialized = false;
+
struct vmap_block_queue {
spinlock_t lock;
struct list_head free;
@@ -827,6 +829,9 @@
int cpu;
int flush = 0;

+ if (!vmap_initialized)
+ return;
+
for_each_possible_cpu(cpu) {
struct vmap_block_queue *vbq = &per_cpu(vmap_block_queue, cpu);
struct vmap_block *vb;
@@ -940,6 +945,8 @@
INIT_LIST_HEAD(&vbq->dirty);
vbq->nr_dirty = 0;
}
+
+ vmap_initialized = true;
}

void unmap_kernel_range(unsigned long addr, unsigned long size)



\
 
 \ /
  Last update: 2008-10-24 01:51    [W:0.135 / U:0.128 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site