[uml-user] UML kernel takes 100% CPU

2008-12-08 Thread lanas
Hi,

  Running under Fedora 8 32-bits I started running some UMLs.  At
one point I had 9 of them running.  Then one of the UML Linux
kernel started using 100% CPU (or very, very close to that).
When compared to the others running UML kernels, that one had ps
aux's VSZ and RSS fields in the 150-170 range whereas all the others
had 0 and 0.

  So I've terminated the processes on that note for that day.  I
might or might not see this again, so what I'd like to know are
tips and hints about debugging such an issue.  At least for
providing a complete description here, or even perhaps to solve
the problem.

  Now, the UML kernel is of the 2.6.24.2 variety, running under
stock Fedora 8 32-bit (2.6.23.14).  The host has 1 GB of RAM and
runs a dual core type of CPU. The UMLs have default RAM.  

  Maybe of note, the actual filesystem was taken from a system running
2.6.18.  So at boot there are some warnings about not finding
modules.  The UML boots anyways.  Some functionality is not present
when compared to the original system, but I do not care that much
about that at the moment.  I don't know if that kernel/module
mismatch could be a factor in this problem.

  The virtual setup is made of a virtual router connected on one
side to a tap0 device, and the other side to a 'daemon' eg. a
uml_switch.  To that switch are connected 8 other UMLs.  Is there
a limit to connecting UMLs to a switch ?

  A typical UML )of the ones connected to the uml_switch) is
created like this:

  ./linux ubda=cow1,testfs2 umid=uml1 eth0=daemon

  Others like the following:

  ./linux ubda=cow2,testfs2 umid=uml2 eth0=daemon
  ./linux ubda=cow3,testfs2 umid=uml3 eth0=daemon
  etc...

  What would typically cause a UML kernel to go and consume
steadily close to 100% CPU ?

Thanks for any suggestions !

Cheers.

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user


[uml-user] [PATCH] SKAS3 for 2.6.25

2008-12-08 Thread Ryan Finnie
Well, nobody complained about my 2.6.24 port, so I figured that now, 
11 months later, it was time to release a 2.6.25 SKAS3 patch. :)  I do 
plan on immediately moving to 2.6.26 and 2.6.27, but I figured baby 
steps are the best for getting SKAS3 up to speed.  Please take a look 
and let me know if you find anything wrong.

RF

--

This is a SKAS3 patch for Linux 2.6.25 and 2.6.25.x (last tested
2008-12-08 with 2.6.25.20). If you have any questions or problems,
please ask on the uml-user list (URL below). I may be maintaining
this patch, but I not a C programmer; I just play one on TV.

 --Ryan Finnie <[EMAIL PROTECTED]>

Download location:
 http://www.finnie.org/software/uml/2.6.25-skas3.patch
uml-user list:
 https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

 arch/um/sys-i386/ldt.c   |2 
 arch/x86/Kconfig |   21 ++
 arch/x86/ia32/sys_ia32.c |   16 +-
 arch/x86/kernel/ldt.c|   58 ---
 arch/x86/kernel/ptrace.c |   63 
 arch/x86/kernel/sys_i386_32.c|   27 ++-
 arch/x86/kernel/sys_x86_64.c |   15 +
 arch/x86/mm/Makefile_64  |1 
 arch/x86/mm/proc_mm_64.c |   85 +++
 include/asm-um/compat.h  |9 +
 include/asm-um/proc_mm_32.h  |1 
 include/asm-um/proc_mm_64.h  |1 
 include/asm-um/ptrace-x86_64.h   |1 
 include/asm-x86/desc.h   |3 
 include/asm-x86/mmu_context_32.h |   19 ++
 include/asm-x86/mmu_context_64.h |   20 ++
 include/asm-x86/proc_mm_32.h |   18 ++
 include/asm-x86/proc_mm_64.h |   58 +++
 include/asm-x86/ptrace-abi.h |6 
 include/asm-x86/ptrace.h |   65 
 include/linux/mm.h   |   19 +-
 include/linux/proc_mm.h  |  110 ++
 mm/Makefile  |5 
 mm/fremap.c  |2 
 mm/mmap.c|   17 +-
 mm/mprotect.c|   20 +-
 mm/proc_mm-mod.c |   50 ++
 mm/proc_mm.c |  299 +++
 28 files changed, 949 insertions(+), 62 deletions(-)

diff -ruN linux-2.6.25.orig/arch/um/sys-i386/ldt.c 
linux-2.6.25/arch/um/sys-i386/ldt.c
--- linux-2.6.25.orig/arch/um/sys-i386/ldt.c2008-04-16 19:49:44.0 
-0700
+++ linux-2.6.25/arch/um/sys-i386/ldt.c 2008-12-08 14:58:14.0 -0800
@@ -7,7 +7,7 @@
 #include 
 #include 
 #include "os.h"
-#include "proc_mm.h"
+#include "linux/proc_mm.h"
 #include "skas.h"
 #include "skas_ptrace.h"
 #include "sysdep/tls.h"
diff -ruN linux-2.6.25.orig/arch/x86/ia32/sys_ia32.c 
linux-2.6.25/arch/x86/ia32/sys_ia32.c
--- linux-2.6.25.orig/arch/x86/ia32/sys_ia32.c  2008-04-16 19:49:44.0 
-0700
+++ linux-2.6.25/arch/x86/ia32/sys_ia32.c   2008-12-08 15:01:53.0 
-0800
@@ -695,11 +695,10 @@
return ret;
 }
 
-asmlinkage long sys32_mmap2(unsigned long addr, unsigned long len,
-   unsigned long prot, unsigned long flags,
+long do32_mmap2(struct mm_struct *mm, unsigned long addr,
+   unsigned long len, unsigned long prot, unsigned 
long flags,
unsigned long fd, unsigned long pgoff)
 {
-   struct mm_struct *mm = current->mm;
unsigned long error;
struct file *file = NULL;
 
@@ -711,7 +710,7 @@
}
 
down_write(&mm->mmap_sem);
-   error = do_mmap_pgoff(file, addr, len, prot, flags, pgoff);
+   error = __do_mmap_pgoff(mm, file, addr, len, prot, flags, pgoff);
up_write(&mm->mmap_sem);
 
if (file)
@@ -719,6 +718,15 @@
return error;
 }
 
+/* XXX: this wrapper can be probably removed, we can simply use the 64-bit
+ * version.*/
+asmlinkage long sys32_mmap2(unsigned long addr, unsigned long len,
+   unsigned long prot, unsigned long flags,
+   unsigned long fd, unsigned long pgoff)
+{
+   return do32_mmap2(current->mm, addr, len, prot, flags, fd, pgoff);
+}
+
 asmlinkage long sys32_olduname(struct oldold_utsname __user *name)
 {
char *arch = "x86_64";
diff -ruN linux-2.6.25.orig/arch/x86/Kconfig linux-2.6.25/arch/x86/Kconfig
--- linux-2.6.25.orig/arch/x86/Kconfig  2008-04-16 19:49:44.0 -0700
+++ linux-2.6.25/arch/x86/Kconfig   2008-12-08 14:58:20.0 -0800
@@ -836,6 +836,27 @@
  has the cost of more pagetable lookup overhead, and also
  consumes more pagetable space per process.
 
+config PROC_MM
+   bool "/proc/mm support"
+   default y
+
+config PROC_MM_DUMPABLE
+   bool "Make UML childs /proc/ completely browsable"
+   default n
+   depends on PROC_MM
+   help
+ If in doubt, say N.
+
+ This fiddles with some settings to make sure /proc/ is completely
+ browsable by who started UML, at the expense of some additional
+ locking (maybe this could slow down the runned UMLs of a few percents,
+ I've not tested this).
+
+ Also, if there is a bug