Re: Kernel Panic with latest patch from git repo

Ansgar Esztermann <[email protected]>
Newsgroups gmane.linux.cluster.openmosix.devel
Message-ID <[email protected]>
On Tue, Feb 21, 2006 at 09:07:48PM +0100, Matthieu Pérotin wrote:
> When migrating a process from a node A to a node B, the node B crashes
> on a kernel panic.

I think I've finally figured out what really happens. When I wrote
earlier (to the list) that Node B receives the process at interrupt
time, I was wrong. It only looks that way (and the kernel actually
thinks that way) because the preempt counter overflows. (Note that
that counter is kept even on a kernel with CONFIG_PREEMPT off.)

The counter overflows because there is an unbalanced call to
pte_alloc_map() in mig_do_receive_page(). Now, if CONFIG_HIGHPTE is
set, user space PTEs are allocated in high memory. pte_alloc_map()
will atomically map the PTE so that it can be used; however, that map
is never released.
If CONFIG_HIGHPTE is off, the mapping is #defined away, so the problem
does not surface.

I've created a patch that enables migration even with CONFIG_HIGHPTE
on. I've tested it here, and it seems to work OK, so I'd like to
submit it for inclusion with openMosix.

A.

=======================================================================

diff -ruN linux-2.6-om/hpc/migrecv.c linux-2.6-om-work/hpc/migrecv.c
--- linux-2.6-om/hpc/migrecv.c	2006-02-07 16:51:58.000000000 +0100
+++ linux-2.6-om-work/hpc/migrecv.c	2006-02-24 21:13:35.000000000 +0100
@@ -183,6 +183,7 @@
 		OMBUG("double page at addr %p\n", (void *) addr);
 
 	set_pte(pte, pte_mkdirty(mk_pte(recv_page, vma->vm_page_prot)));
+	pte_unmap(pte);
 	page_dup_rmap(recv_page);
 	inc_mm_counter(mm, file_rss);
 	
-- 
Ansgar Esztermann
Researcher & Sysadmin
http://www2.thphy.uni-duesseldorf.de/~ansgar
signature.asc (application/pgp-signature, 191 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iD8DBQFD/2/jwAkt8h1/xRgRAhOmAJ48HiKQEfyQ++OcPob49ivpgqs0+gCgggoj
7Rz4MQVYzEJdpLy6lSYnky4=
=Y9Gs
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.