user-mode-linux-user

[uml-user] [PATCH 3.2 148/185] um: add missing declaration of 'getrlimit()' and friends

[Ben H. <be...@de...>]

3.2.54-rc1 review patch.  If anyone has any objections, please let me know.

------------------

From: Sergei Trofimovich <sl...@ge...>

commit fdfa4c952844fce881df8c76de9c7180cbe913ab upstream.

arch/um/os-Linux/start_up.c: In function 'check_coredump_limit':
arch/um/os-Linux/start_up.c:338:16: error: storage size of 'lim' isn't known
arch/um/os-Linux/start_up.c:339:2: error: implicit declaration of function 'getrlimit' [-Werror=implicit-function-declaration]

Signed-off-by: Sergei Trofimovich <sl...@ge...>
CC: Jeff Dike <jd...@ad...>
CC: Richard Weinberger <ri...@no...>
CC: Al Viro <vi...@ze...>
CC: use...@li...
CC: use...@li...
CC: lin...@vg...
Signed-off-by: Richard Weinberger <ri...@no...>
Signed-off-by: Ben Hutchings <be...@de...>
---
 arch/um/os-Linux/start_up.c | 2 ++
 1 file changed, 2 insertions(+)

--- a/arch/um/os-Linux/start_up.c
+++ b/arch/um/os-Linux/start_up.c
@@ -15,6 +15,8 @@
 #include <sys/mman.h>
 #include <sys/stat.h>
 #include <sys/wait.h>
+#include <sys/time.h>
+#include <sys/resource.h>
 #include <asm/unistd.h>
 #include "init.h"
 #include "os.h"

[uml-user] [PATCH 3.5 049/103] um: add missing declaration of 'getrlimit()' and friends

[Luis H. <lui...@ca...>]

3.5.7.28 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Sergei Trofimovich <sl...@ge...>

commit fdfa4c952844fce881df8c76de9c7180cbe913ab upstream.

arch/um/os-Linux/start_up.c: In function 'check_coredump_limit':
arch/um/os-Linux/start_up.c:338:16: error: storage size of 'lim' isn't known
arch/um/os-Linux/start_up.c:339:2: error: implicit declaration of function 'getrlimit' [-Werror=implicit-function-declaration]

Signed-off-by: Sergei Trofimovich <sl...@ge...>
CC: Jeff Dike <jd...@ad...>
CC: Richard Weinberger <ri...@no...>
CC: Al Viro <vi...@ze...>
CC: use...@li...
CC: use...@li...
CC: lin...@vg...
Signed-off-by: Richard Weinberger <ri...@no...>
Signed-off-by: Luis Henriques <lui...@ca...>
---
 arch/um/os-Linux/start_up.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/um/os-Linux/start_up.c b/arch/um/os-Linux/start_up.c
index 425162e..2f53b89 100644
--- a/arch/um/os-Linux/start_up.c
+++ b/arch/um/os-Linux/start_up.c
@@ -15,6 +15,8 @@
 #include <sys/mman.h>
 #include <sys/stat.h>
 #include <sys/wait.h>
+#include <sys/time.h>
+#include <sys/resource.h>
 #include <asm/unistd.h>
 #include "init.h"
 #include "os.h"
-- 
1.8.3.2

[uml-user] [3.5.y.z extended stable] Patch "um: add missing declaration of 'getrlimit()' and friends" has been added to staging queue

[Luis H. <lui...@ca...>]

This is a note to let you know that I have just added a patch titled

    um: add missing declaration of 'getrlimit()' and friends

to the linux-3.5.y-queue branch of the 3.5.y.z extended stable tree 
which can be found at:

 http://kernel.ubuntu.com/git?p=ubuntu/linux.git;a=shortlog;h=refs/heads/linux-3.5.y-queue

If you, or anyone else, feels it should not be added to this tree, please 
reply to this email.

For more information about the 3.5.y.z tree, see
https://wiki.ubuntu.com/Kernel/Dev/ExtendedStable

Thanks.
-Luis

------

>From e79e33d9a4e1a528efc11b7cc3d5eba0871451f8 Mon Sep 17 00:00:00 2001
From: Sergei Trofimovich <sl...@ge...>
Date: Sun, 30 Dec 2012 01:37:30 +0300
Subject: um: add missing declaration of 'getrlimit()' and friends

commit fdfa4c952844fce881df8c76de9c7180cbe913ab upstream.

arch/um/os-Linux/start_up.c: In function 'check_coredump_limit':
arch/um/os-Linux/start_up.c:338:16: error: storage size of 'lim' isn't known
arch/um/os-Linux/start_up.c:339:2: error: implicit declaration of function 'getrlimit' [-Werror=implicit-function-declaration]

Signed-off-by: Sergei Trofimovich <sl...@ge...>
CC: Jeff Dike <jd...@ad...>
CC: Richard Weinberger <ri...@no...>
CC: Al Viro <vi...@ze...>
CC: use...@li...
CC: use...@li...
CC: lin...@vg...
Signed-off-by: Richard Weinberger <ri...@no...>
Signed-off-by: Luis Henriques <lui...@ca...>
---
 arch/um/os-Linux/start_up.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/um/os-Linux/start_up.c b/arch/um/os-Linux/start_up.c
index 425162e..2f53b89 100644
--- a/arch/um/os-Linux/start_up.c
+++ b/arch/um/os-Linux/start_up.c
@@ -15,6 +15,8 @@
 #include <sys/mman.h>
 #include <sys/stat.h>
 #include <sys/wait.h>
+#include <sys/time.h>
+#include <sys/resource.h>
 #include <asm/unistd.h>
 #include "init.h"
 #include "os.h"
--
1.8.3.2

[uml-user] [PATCH 3.4 17/25] um: add missing declaration of getrlimit() and friends

[Greg Kroah-H. <gr...@li...>]

3.4-stable review patch.  If anyone has any objections, please let me know.

------------------

From: Sergei Trofimovich <sl...@ge...>

commit fdfa4c952844fce881df8c76de9c7180cbe913ab upstream.

arch/um/os-Linux/start_up.c: In function 'check_coredump_limit':
arch/um/os-Linux/start_up.c:338:16: error: storage size of 'lim' isn't known
arch/um/os-Linux/start_up.c:339:2: error: implicit declaration of function 'getrlimit' [-Werror=implicit-function-declaration]

Signed-off-by: Sergei Trofimovich <sl...@ge...>
CC: Jeff Dike <jd...@ad...>
CC: Richard Weinberger <ri...@no...>
CC: Al Viro <vi...@ze...>
CC: use...@li...
CC: use...@li...
CC: lin...@vg...
Signed-off-by: Richard Weinberger <ri...@no...>
Signed-off-by: Greg Kroah-Hartman <gr...@li...>

---
 arch/um/os-Linux/start_up.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/arch/um/os-Linux/start_up.c
+++ b/arch/um/os-Linux/start_up.c
@@ -15,6 +15,8 @@
 #include <sys/mman.h>
 #include <sys/stat.h>
 #include <sys/wait.h>
+#include <sys/time.h>
+#include <sys/resource.h>
 #include <asm/unistd.h>
 #include "init.h"
 #include "os.h"

Re: [uml-user] Building UML with busybox as root file system

[Tamil M. <rf....@gm...>]

thank you. got it :)


On Tue, Nov 19, 2013 at 8:58 PM, Teto <mat...@gm...> wrote:

>  [image: Boxbe] <https://www.boxbe.com/overview> mat...@gm... is
> not on your Guest List<https://www.boxbe.com/approved-list?tc_serial=15707547538&tc_rand=1048279160&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&token=yWsAjFQjrbsAoZAUSwuHgHELEJtbdfMW4RREBp7cRGoQbTeOH5ZC52nehnG0RHU2&key=XPajx0UOZ1U4cf%2Fl0578bCIgL04PEhsmMraRj8im7U0%3D>| Approve
> sender<https://www.boxbe.com/anno?tc_serial=15707547538&tc_rand=1048279160&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&token=yWsAjFQjrbsAoZAUSwuHgHELEJtbdfMW4RREBp7cRGoQbTeOH5ZC52nehnG0RHU2&key=XPajx0UOZ1U4cf%2Fl0578bCIgL04PEhsmMraRj8im7U0%3D>| Approve
> domain<https://www.boxbe.com/anno?tc_serial=15707547538&tc_rand=1048279160&utm_source=stf&utm_medium=email&utm_campaign=ANNO_MWTP&utm_content=001&dom&token=yWsAjFQjrbsAoZAUSwuHgHELEJtbdfMW4RREBp7cRGoQbTeOH5ZC52nehnG0RHU2&key=XPajx0UOZ1U4cf%2Fl0578bCIgL04PEhsmMraRj8im7U0%3D>
>
> Have you tried setting your init to the busybox binary ? try adding
> "init=<pathToBusyboxInYourFileSystem>" o nthe command line
>
> 2013/11/19 Tamil Mani <rf....@gm...>:
> > Hi ,
> > I downloaded the latest version of linux-3.11.8 ,configured it as UML and
> > got the statically compiled binary (linux).
> >
> > Then i downloaded the latest busybox 1.21.1 and compiled with default
> > configuration. Then i converted the busybox binary into a  ext4
> filesystem.
> >
> > while running linux as UML,
> >
> > ./linux ubda=./busybox mem=128M
> >
> > i'm getting the following error
> >
> >  EXT4-fs (ubda): mounted filesystem with ordered data mode. Opts: (null)
> > [    1.170000] VFS: Mounted root (ext4 filesystem) readonly on device
> 98:0.
> > [    1.170000] Kernel panic - not syncing: No init found.  Try passing
> init=
> > option to kernel. See Linux Documentation/init.txt for guidance.
> > [    1.170000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.8 #6
> > [    1.170000] 67c3fe78 67c3feb0 60058699 6004c888 60600531 00000000
> > 00000000 67c3fec0
> > [    1.170000]        604f6fe3 67c3ffc0 604f1e3b 00000000 3000000008
> > 67c3ffd0 67c3fef0 657fe900
> > [    1.170000]        6004c888 00000f76 6004c888 00000003 67c3fe40
> 60600529
> > fffffffe 67c3ffa0
> > [    1.170000] Call Trace:
> > [    1.170000] 67c3fe88:  [<60058699>] dump_stack_print_info+0xa5/0xae
> > [    1.170000] 67c3fe90:  [<6004c888>] put_cred_rcu+0x0/0xa4
> > [    1.170000] 67c3feb8:  [<604f6fe3>] dump_stack+0x17/0x19
> > [    1.170000] 67c3fec8:  [<604f1e3b>] panic+0xf7/0x1ee
> > [    1.170000] 67c3fef8:  [<6004c888>] put_cred_rcu+0x0/0xa4
> > [    1.170000] 67c3ff08:  [<6004c888>] put_cred_rcu+0x0/0xa4
> > [    1.170000] 67c3ff38:  [<600ac7ce>] do_execve_common+0x49b/0x4f0
> > [    1.170000] 67c3ff48:  [<6004d600>]
> > async_synchronize_cookie_domain+0x56/0x112
> > [    1.170000] 67c3ffc8:  [<604f0c88>] kernel_init+0xb6/0xba
> > [    1.170000] 67c3ffd8:  [<6001c374>] new_thread_handler+0x7a/0x95
> > [    1.170000]
> > [    1.170000]
> > [    1.170000] Modules linked in:
> > [    1.170000] Pid: 1, comm: swapper Not tainted 3.11.8
> > [    1.170000] RIP: 0033:[<000000006048c0a7>]
> > [    1.170000] RSP: 00007fff11356248  EFLAGS: 00000246
> > [    1.170000] RAX: 0000000000000000 RBX: 00000000000048ec RCX:
> > ffffffffffffffff
> > [    1.170000] RDX: 0000000000000000 RSI: 0000000000000013 RDI:
> > 00000000000048ec
> > [    1.170000] RBP: 00007fff11356270 R08: 0000000000000000 R09:
> > 00007fff11356270
> > [    1.170000] R10: 0000000000000000 R11: 0000000000000246 R12:
> > 00000000000048e8
> > [    1.170000] R13: 00007fff11356458 R14: 00007fff11356e3a R15:
> > 0000000000000007
> > [    1.170000] Call Trace:
> > [    1.170000] 67c3fe38:  [<6001d2f6>] show_trace+0x8e/0x95
> > [    1.170000] 67c3fe48:  [<6001e808>] panic_exit+0x2b/0x41
> > [    1.170000] 67c3fe68:  [<6004c298>] notifier_call_chain+0x32/0x5c
> > [    1.170000] 67c3fea8:  [<6004c2cb>]
> __atomic_notifier_call_chain+0x9/0xb
> > [    1.170000] 67c3feb8:  [<6004c2dc>]
> atomic_notifier_call_chain+0xf/0x11
> > [    1.170000] 67c3fec8:  [<604f1e56>] panic+0x112/0x1ee
> > [    1.170000] 67c3fef8:  [<6004c888>] put_cred_rcu+0x0/0xa4
> > [    1.170000] 67c3ff08:  [<6004c888>] put_cred_rcu+0x0/0xa4
> > [    1.170000] 67c3ff38:  [<600ac7ce>] do_execve_common+0x49b/0x4f0
> > [    1.170000] 67c3ff48:  [<6004d600>]
> > async_synchronize_cookie_domain+0x56/0x112
> > [    1.170000] 67c3ffc8:  [<604f0c88>] kernel_init+0xb6/0xba
> > [    1.170000] 67c3ffd8:  [<6001c374>] new_thread_handler+0x7a/0x95
> > [    1.170000]
> > Aborted
> >
> > To summarize,i'm getting a kernel panic due to the missing of init.
> Please
> > help me in fixing the problem
> >
> > Thanks & regards,
> > Tamil
> >
> >
> ------------------------------------------------------------------------------
> > Shape the Mobile Experience: Free Subscription
> > Software experts and developers: Be at the forefront of tech innovation.
> > Intel(R) Software Adrenaline delivers strategic insight and game-changing
> > conversations that shape the rapidly evolving mobile landscape. Sign up
> now.
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> > _______________________________________________
> > User-mode-linux-user mailing list
> > Use...@li...
> > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
> >
>
>

Re: [uml-user] Building UML with busybox as root file system

[Teto <mat...@gm...>]

Have you tried setting your init to the busybox binary ? try adding
"init=<pathToBusyboxInYourFileSystem>" o nthe command line

2013/11/19 Tamil Mani <rf....@gm...>:
> Hi ,
> I downloaded the latest version of linux-3.11.8 ,configured it as UML and
> got the statically compiled binary (linux).
>
> Then i downloaded the latest busybox 1.21.1 and compiled with default
> configuration. Then i converted the busybox binary into a  ext4 filesystem.
>
> while running linux as UML,
>
> ./linux ubda=./busybox mem=128M
>
> i'm getting the following error
>
>  EXT4-fs (ubda): mounted filesystem with ordered data mode. Opts: (null)
> [    1.170000] VFS: Mounted root (ext4 filesystem) readonly on device 98:0.
> [    1.170000] Kernel panic - not syncing: No init found.  Try passing init=
> option to kernel. See Linux Documentation/init.txt for guidance.
> [    1.170000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.8 #6
> [    1.170000] 67c3fe78 67c3feb0 60058699 6004c888 60600531 00000000
> 00000000 67c3fec0
> [    1.170000]        604f6fe3 67c3ffc0 604f1e3b 00000000 3000000008
> 67c3ffd0 67c3fef0 657fe900
> [    1.170000]        6004c888 00000f76 6004c888 00000003 67c3fe40 60600529
> fffffffe 67c3ffa0
> [    1.170000] Call Trace:
> [    1.170000] 67c3fe88:  [<60058699>] dump_stack_print_info+0xa5/0xae
> [    1.170000] 67c3fe90:  [<6004c888>] put_cred_rcu+0x0/0xa4
> [    1.170000] 67c3feb8:  [<604f6fe3>] dump_stack+0x17/0x19
> [    1.170000] 67c3fec8:  [<604f1e3b>] panic+0xf7/0x1ee
> [    1.170000] 67c3fef8:  [<6004c888>] put_cred_rcu+0x0/0xa4
> [    1.170000] 67c3ff08:  [<6004c888>] put_cred_rcu+0x0/0xa4
> [    1.170000] 67c3ff38:  [<600ac7ce>] do_execve_common+0x49b/0x4f0
> [    1.170000] 67c3ff48:  [<6004d600>]
> async_synchronize_cookie_domain+0x56/0x112
> [    1.170000] 67c3ffc8:  [<604f0c88>] kernel_init+0xb6/0xba
> [    1.170000] 67c3ffd8:  [<6001c374>] new_thread_handler+0x7a/0x95
> [    1.170000]
> [    1.170000]
> [    1.170000] Modules linked in:
> [    1.170000] Pid: 1, comm: swapper Not tainted 3.11.8
> [    1.170000] RIP: 0033:[<000000006048c0a7>]
> [    1.170000] RSP: 00007fff11356248  EFLAGS: 00000246
> [    1.170000] RAX: 0000000000000000 RBX: 00000000000048ec RCX:
> ffffffffffffffff
> [    1.170000] RDX: 0000000000000000 RSI: 0000000000000013 RDI:
> 00000000000048ec
> [    1.170000] RBP: 00007fff11356270 R08: 0000000000000000 R09:
> 00007fff11356270
> [    1.170000] R10: 0000000000000000 R11: 0000000000000246 R12:
> 00000000000048e8
> [    1.170000] R13: 00007fff11356458 R14: 00007fff11356e3a R15:
> 0000000000000007
> [    1.170000] Call Trace:
> [    1.170000] 67c3fe38:  [<6001d2f6>] show_trace+0x8e/0x95
> [    1.170000] 67c3fe48:  [<6001e808>] panic_exit+0x2b/0x41
> [    1.170000] 67c3fe68:  [<6004c298>] notifier_call_chain+0x32/0x5c
> [    1.170000] 67c3fea8:  [<6004c2cb>] __atomic_notifier_call_chain+0x9/0xb
> [    1.170000] 67c3feb8:  [<6004c2dc>] atomic_notifier_call_chain+0xf/0x11
> [    1.170000] 67c3fec8:  [<604f1e56>] panic+0x112/0x1ee
> [    1.170000] 67c3fef8:  [<6004c888>] put_cred_rcu+0x0/0xa4
> [    1.170000] 67c3ff08:  [<6004c888>] put_cred_rcu+0x0/0xa4
> [    1.170000] 67c3ff38:  [<600ac7ce>] do_execve_common+0x49b/0x4f0
> [    1.170000] 67c3ff48:  [<6004d600>]
> async_synchronize_cookie_domain+0x56/0x112
> [    1.170000] 67c3ffc8:  [<604f0c88>] kernel_init+0xb6/0xba
> [    1.170000] 67c3ffd8:  [<6001c374>] new_thread_handler+0x7a/0x95
> [    1.170000]
> Aborted
>
> To summarize,i'm getting a kernel panic due to the missing of init. Please
> help me in fixing the problem
>
> Thanks & regards,
> Tamil
>
> ------------------------------------------------------------------------------
> Shape the Mobile Experience: Free Subscription
> Software experts and developers: Be at the forefront of tech innovation.
> Intel(R) Software Adrenaline delivers strategic insight and game-changing
> conversations that shape the rapidly evolving mobile landscape. Sign up now.
> http://pubads.g.doubleclick.net/gampad/clk?id=63431311&iu=/4140/ostg.clktrk
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
>

[uml-user] Building UML with busybox as root file system

[Tamil M. <rf....@gm...>]

Hi ,
I downloaded the latest version of linux-3.11.8 ,configured it as UML and
got the statically compiled binary (linux).

Then i downloaded the latest busybox 1.21.1 and compiled with default
configuration. Then i converted the busybox binary into a  ext4 filesystem.

while running linux as UML,

./linux ubda=./busybox mem=128M

i'm getting the following error

 EXT4-fs (ubda): mounted filesystem with ordered data mode. Opts: (null)
[    1.170000] VFS: Mounted root (ext4 filesystem) readonly on device 98:0.
[    1.170000] Kernel panic - not syncing: No init found.  Try passing
init= option to kernel. See Linux Documentation/init.txt for guidance.
[    1.170000] CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.8 #6
[    1.170000] 67c3fe78 67c3feb0 60058699 6004c888 60600531 00000000
00000000 67c3fec0
[    1.170000]        604f6fe3 67c3ffc0 604f1e3b 00000000 3000000008
67c3ffd0 67c3fef0 657fe900
[    1.170000]        6004c888 00000f76 6004c888 00000003 67c3fe40 60600529
fffffffe 67c3ffa0
[    1.170000] Call Trace:
[    1.170000] 67c3fe88:  [<60058699>] dump_stack_print_info+0xa5/0xae
[    1.170000] 67c3fe90:  [<6004c888>] put_cred_rcu+0x0/0xa4
[    1.170000] 67c3feb8:  [<604f6fe3>] dump_stack+0x17/0x19
[    1.170000] 67c3fec8:  [<604f1e3b>] panic+0xf7/0x1ee
[    1.170000] 67c3fef8:  [<6004c888>] put_cred_rcu+0x0/0xa4
[    1.170000] 67c3ff08:  [<6004c888>] put_cred_rcu+0x0/0xa4
[    1.170000] 67c3ff38:  [<600ac7ce>] do_execve_common+0x49b/0x4f0
[    1.170000] 67c3ff48:  [<6004d600>]
async_synchronize_cookie_domain+0x56/0x112
[    1.170000] 67c3ffc8:  [<604f0c88>] kernel_init+0xb6/0xba
[    1.170000] 67c3ffd8:  [<6001c374>] new_thread_handler+0x7a/0x95
[    1.170000]
[    1.170000]
[    1.170000] Modules linked in:
[    1.170000] Pid: 1, comm: swapper Not tainted 3.11.8
[    1.170000] RIP: 0033:[<000000006048c0a7>]
[    1.170000] RSP: 00007fff11356248  EFLAGS: 00000246
[    1.170000] RAX: 0000000000000000 RBX: 00000000000048ec RCX:
ffffffffffffffff
[    1.170000] RDX: 0000000000000000 RSI: 0000000000000013 RDI:
00000000000048ec
[    1.170000] RBP: 00007fff11356270 R08: 0000000000000000 R09:
00007fff11356270
[    1.170000] R10: 0000000000000000 R11: 0000000000000246 R12:
00000000000048e8
[    1.170000] R13: 00007fff11356458 R14: 00007fff11356e3a R15:
0000000000000007
[    1.170000] Call Trace:
[    1.170000] 67c3fe38:  [<6001d2f6>] show_trace+0x8e/0x95
[    1.170000] 67c3fe48:  [<6001e808>] panic_exit+0x2b/0x41
[    1.170000] 67c3fe68:  [<6004c298>] notifier_call_chain+0x32/0x5c
[    1.170000] 67c3fea8:  [<6004c2cb>] __atomic_notifier_call_chain+0x9/0xb
[    1.170000] 67c3feb8:  [<6004c2dc>] atomic_notifier_call_chain+0xf/0x11
[    1.170000] 67c3fec8:  [<604f1e56>] panic+0x112/0x1ee
[    1.170000] 67c3fef8:  [<6004c888>] put_cred_rcu+0x0/0xa4
[    1.170000] 67c3ff08:  [<6004c888>] put_cred_rcu+0x0/0xa4
[    1.170000] 67c3ff38:  [<600ac7ce>] do_execve_common+0x49b/0x4f0
[    1.170000] 67c3ff48:  [<6004d600>]
async_synchronize_cookie_domain+0x56/0x112
[    1.170000] 67c3ffc8:  [<604f0c88>] kernel_init+0xb6/0xba
[    1.170000] 67c3ffd8:  [<6001c374>] new_thread_handler+0x7a/0x95
[    1.170000]
Aborted

To summarize,i'm getting a kernel panic due to the missing of init. Please
help me in fixing the problem

Thanks & regards,
Tamil

Re: [uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Chen G. <gan...@as...>]

On 11/14/2013 03:33 PM, Chen Gang wrote:
> On 11/14/2013 02:48 PM, Chen Gang wrote:
>>> >From the look of it, if an error did occur in init_stub_pte(),
>>>> then the special mapping of STUB_CODE and STUB_DATA would not
>>>> be installed, so this area would be invisible to munmap and exit,
>>>> and with your patch then the pages allocated likely to be leaked.
>>>>
>> It sounds reasonable to me: "although 'pgd' related with 'mm', but they
>> are not installed". But just like you said originally: "better get ACK
>> from some mm guys".
>>
>>
>> Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
>> fails, the STUB_CODE will be leaked".
>>
>>
>>>> Which is not to say that the existing code is actually correct:
>>>> you're probably right that it's technically wrong.  But it would
>>>> be very hard to get init_stub_pte() to fail, and has anyone
>>>> reported a problem with it?  My guess is not, and my own
>>>> inclination to dabble here is zero.
>>>>
>> Yeah.
>>
> 
> If we can not get ACK from any mm guys, and we have no enough time
> resource to read related source code, for me, I still recommend to
> remove p?d_free() in failure processing.
> 

Oh, I am very sorry to Hugh and Richard, I make a mistake in common
sense: I recognized incorrect members (I treated Hugh as Richard), Hugh
is "mm guys".

Next time, I should see the mail carefully, not only for contents, but
also for senders.

Sorry again to both of you.

Thanks.

> In the worst cases, we will leak a little memory, and no any other
> negative effect, it is an executable way which is no any risks.
> 
> For current mm implementation, it seems we can not assume any thing,
> although they sounds (or should be) reasonable (include what you said
> about mm).
> 
> 
> Thanks.
> 


-- 
Chen Gang

Re: [uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Chen G. <gan...@as...>]

On 11/14/2013 03:55 PM, Richard Weinberger wrote:
> Am 14.11.2013 08:33, schrieb Chen Gang:
>> > On 11/14/2013 02:48 PM, Chen Gang wrote:
>>>> >>> >From the look of it, if an error did occur in init_stub_pte(),
>>>>> >>>> then the special mapping of STUB_CODE and STUB_DATA would not
>>>>> >>>> be installed, so this area would be invisible to munmap and exit,
>>>>> >>>> and with your patch then the pages allocated likely to be leaked.
>>>>> >>>>
>>> >> It sounds reasonable to me: "although 'pgd' related with 'mm', but they
>>> >> are not installed". But just like you said originally: "better get ACK
>>> >> from some mm guys".
>>> >>
>>> >>
>>> >> Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
>>> >> fails, the STUB_CODE will be leaked".
>>> >>
>>> >>
>>>>> >>>> Which is not to say that the existing code is actually correct:
>>>>> >>>> you're probably right that it's technically wrong.  But it would
>>>>> >>>> be very hard to get init_stub_pte() to fail, and has anyone
>>>>> >>>> reported a problem with it?  My guess is not, and my own
>>>>> >>>> inclination to dabble here is zero.
>>>>> >>>>
>>> >> Yeah.
>>> >>
>> > 
>> > If we can not get ACK from any mm guys, and we have no enough time
>> > resource to read related source code, for me, I still recommend to
>> > remove p?d_free() in failure processing.
> It's rather easy, does your commit fix a real problem you are facing?
> If the answer is "yes" we can talk.
> 

We have met many code which *should* be correct, but in really world it
is incorrect (most of reasons come from related interface definition).
I want to let these code less and less.

Now I want to make clear all p?d_free() related things, and except our
um, also 3 areas use it.

  arch/arm/mm/pgd.c:100:  pud_free(mm, new_pud);
  arch/arm/mm/pgd.c:137:  pud_free(mm, pud);
  arch/arm/mm/pgd.c:155:          pud_free(mm, pud);
  drivers/iommu/arm-smmu.c:947:   pud_free(NULL, pud_base);
  mm/memory.c:3835:               pud_free(mm, new);

I am checking all of them (include um), and now for me, the related
code under um can be improved, so I communicate with you (send the
related patch).


> Chen, If you really want to help us, please investigate into existing/real problems.
> Toralf does a very good job in finding strange issues using trinity.
> You could help him resolving the issue described in that thread:
> "[uml-devel] fuzz tested 32 bit user mode linux image hangs in radix_tree_next_chunk()"

Excuse me, at least now, I have no related plan to analyze issues which
not find by myself. The reasons are:

 - I am not quite familiar with kernel, I need preparing (what I am doing is just familiar kernel step by step).

 - my current/original plan about public kernel is delayed.

 - originally I plan (not declare to outside) to solve the issues from Bugzilla of public kernel in next year (2014).
   it will (of cause) also be delayed (I even can not dare to declare it, now).


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Richard W. <ri...@no...>]

Am 14.11.2013 08:33, schrieb Chen Gang:
> On 11/14/2013 02:48 PM, Chen Gang wrote:
>>> >From the look of it, if an error did occur in init_stub_pte(),
>>>> then the special mapping of STUB_CODE and STUB_DATA would not
>>>> be installed, so this area would be invisible to munmap and exit,
>>>> and with your patch then the pages allocated likely to be leaked.
>>>>
>> It sounds reasonable to me: "although 'pgd' related with 'mm', but they
>> are not installed". But just like you said originally: "better get ACK
>> from some mm guys".
>>
>>
>> Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
>> fails, the STUB_CODE will be leaked".
>>
>>
>>>> Which is not to say that the existing code is actually correct:
>>>> you're probably right that it's technically wrong.  But it would
>>>> be very hard to get init_stub_pte() to fail, and has anyone
>>>> reported a problem with it?  My guess is not, and my own
>>>> inclination to dabble here is zero.
>>>>
>> Yeah.
>>
> 
> If we can not get ACK from any mm guys, and we have no enough time
> resource to read related source code, for me, I still recommend to
> remove p?d_free() in failure processing.

It's rather easy, does your commit fix a real problem you are facing?
If the answer is "yes" we can talk.

Chen, If you really want to help us, please investigate into existing/real problems.
Toralf does a very good job in finding strange issues using trinity.
You could help him resolving the issue described in that thread:
"[uml-devel] fuzz tested 32 bit user mode linux image hangs in radix_tree_next_chunk()"

Thanks,
//richard

Re: [uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Chen G. <gan...@as...>]

On 11/14/2013 02:48 PM, Chen Gang wrote:
>> >From the look of it, if an error did occur in init_stub_pte(),
>> > then the special mapping of STUB_CODE and STUB_DATA would not
>> > be installed, so this area would be invisible to munmap and exit,
>> > and with your patch then the pages allocated likely to be leaked.
>> > 
> It sounds reasonable to me: "although 'pgd' related with 'mm', but they
> are not installed". But just like you said originally: "better get ACK
> from some mm guys".
> 
> 
> Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
> fails, the STUB_CODE will be leaked".
> 
> 
>> > Which is not to say that the existing code is actually correct:
>> > you're probably right that it's technically wrong.  But it would
>> > be very hard to get init_stub_pte() to fail, and has anyone
>> > reported a problem with it?  My guess is not, and my own
>> > inclination to dabble here is zero.
>> > 
> Yeah.
> 

If we can not get ACK from any mm guys, and we have no enough time
resource to read related source code, for me, I still recommend to
remove p?d_free() in failure processing.

In the worst cases, we will leak a little memory, and no any other
negative effect, it is an executable way which is no any risks.

For current mm implementation, it seems we can not assume any thing,
although they sounds (or should be) reasonable (include what you said
about mm).


Thanks.
-- 
Chen Gang

Re: [uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Chen G. <gan...@as...>]

Firstly, thank you for spending your time resources to reply so many
details.


On 11/14/2013 01:20 PM, Hugh Dickins wrote:
> On Wed, 13 Nov 2013, Chen Gang wrote:
> 
>> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
>> succeed, they may be used, so in the next failure, we have to skip them
>> to let exit_mmap() or do_munmap() to process it.
>>
>> According to "Documentation/vm/locking", 'mm->page_table_lock' is for
>> using vma list, so not need it when its related vmas are detached or
>> unmapped from using vma list.
> 
> Hah, don't believe a word of Documentation/vm/locking.  From time to
> time someone or other has updated some part of it, but on the whole
> it represents the state of the art in 1999.  Look at its git history:
> not a lot of activity there.
> 
> And please don't ask me to update it, and please don't try to update
> it yourself.  Delete it?  Maybe.
> 

I agree with you.

> Study the code itself for how mm locking is actually done
> (can you see anywhere we use page_table_lock on the vma list?)
> 

in p?d_alloc() will use page_table_lock, that the reason why I noticed
about it.


>>
>> The related work flow:
>>
>>   exit_mmap() ->
>>     unmap_vmas(); /* so not need mm->page_table_lock */
>>     free_pgtables();
>>
>>   do_munmap()->
>>     detach_vmas_to_be_unmapped(); /* so not need mm->page_table_lock */
>>     unmap_region() ->
>>       free_pgtables();
>>
>>   free_pgtables() ->
>>     free_pgd_range() ->
>>       free_pud_range() ->
>>         free_pmd_range() ->
>>           free_pte_range() ->
>>             pmd_clear();
>>             pte_free_tlb();
>>           pud_clear();
>>           pmd_free_tlb();
>>         pgd_clear(); 
>>         pud_free_tlb();
> 
> I don't think those notes would belong in this patch...
> 

Hmm... maybe what you said above is correct, although it is also the
sample to show how to remove them if pgd is related with real 'mm',
which is not like p?d_free().


>>
>> Signed-off-by: Chen Gang <gan...@as...>
>> ---
>>  arch/um/kernel/skas/mmu.c |    4 ++--
>>  1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/um/kernel/skas/mmu.c b/arch/um/kernel/skas/mmu.c
>> index 007d550..3fd1951 100644
>> --- a/arch/um/kernel/skas/mmu.c
>> +++ b/arch/um/kernel/skas/mmu.c
>> @@ -40,9 +40,9 @@ static int init_stub_pte(struct mm_struct *mm, unsigned long proc,
>>  	return 0;
>>  
>>   out_pte:
>> -	pmd_free(mm, pmd);
>> +	/* used by mm->pgd->pud, will free in do_munmap() or exit_mmap() */
>>   out_pmd:
>> -	pud_free(mm, pud);
>> +	/* used by mm->pgd, will free in do_munmap() or exit_mmap() */
>>   out:
>>  	return -ENOMEM;
>>  }
>> -- 
>> 1.7.7.6
> 
> .. but I'm not going to ack this: I just don't share your zest
> for mucking around with what I don't understand, and don't have
> the time to spare to understand it well enough.
> 

OK, I can understand. It belongs both mm area and um, it seems no one
familiar both of them (for me, I am familiar with neither of them).

But, for me, need continue analyzing and discussing.

>>From the look of it, if an error did occur in init_stub_pte(),
> then the special mapping of STUB_CODE and STUB_DATA would not
> be installed, so this area would be invisible to munmap and exit,
> and with your patch then the pages allocated likely to be leaked.
> 

It sounds reasonable to me: "although 'pgd' related with 'mm', but they
are not installed". But just like you said originally: "better get ACK
from some mm guys".


Hmm... is it another issue: "after STUB_CODE succeeds, but STUB_DATA
fails, the STUB_CODE will be leaked".


> Which is not to say that the existing code is actually correct:
> you're probably right that it's technically wrong.  But it would
> be very hard to get init_stub_pte() to fail, and has anyone
> reported a problem with it?  My guess is not, and my own
> inclination to dabble here is zero.
> 

Yeah.

> Hugh
> 
> 


-- 
Chen Gang

Re: [uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Hugh D. <hu...@go...>]

On Wed, 13 Nov 2013, Chen Gang wrote:

> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
> succeed, they may be used, so in the next failure, we have to skip them
> to let exit_mmap() or do_munmap() to process it.
> 
> According to "Documentation/vm/locking", 'mm->page_table_lock' is for
> using vma list, so not need it when its related vmas are detached or
> unmapped from using vma list.

Hah, don't believe a word of Documentation/vm/locking.  From time to
time someone or other has updated some part of it, but on the whole
it represents the state of the art in 1999.  Look at its git history:
not a lot of activity there.

And please don't ask me to update it, and please don't try to update
it yourself.  Delete it?  Maybe.

Study the code itself for how mm locking is actually done
(can you see anywhere we use page_table_lock on the vma list?)

> 
> The related work flow:
> 
>   exit_mmap() ->
>     unmap_vmas(); /* so not need mm->page_table_lock */
>     free_pgtables();
> 
>   do_munmap()->
>     detach_vmas_to_be_unmapped(); /* so not need mm->page_table_lock */
>     unmap_region() ->
>       free_pgtables();
> 
>   free_pgtables() ->
>     free_pgd_range() ->
>       free_pud_range() ->
>         free_pmd_range() ->
>           free_pte_range() ->
>             pmd_clear();
>             pte_free_tlb();
>           pud_clear();
>           pmd_free_tlb();
>         pgd_clear(); 
>         pud_free_tlb();

I don't think those notes would belong in this patch...

> 
> Signed-off-by: Chen Gang <gan...@as...>
> ---
>  arch/um/kernel/skas/mmu.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/um/kernel/skas/mmu.c b/arch/um/kernel/skas/mmu.c
> index 007d550..3fd1951 100644
> --- a/arch/um/kernel/skas/mmu.c
> +++ b/arch/um/kernel/skas/mmu.c
> @@ -40,9 +40,9 @@ static int init_stub_pte(struct mm_struct *mm, unsigned long proc,
>  	return 0;
>  
>   out_pte:
> -	pmd_free(mm, pmd);
> +	/* used by mm->pgd->pud, will free in do_munmap() or exit_mmap() */
>   out_pmd:
> -	pud_free(mm, pud);
> +	/* used by mm->pgd, will free in do_munmap() or exit_mmap() */
>   out:
>  	return -ENOMEM;
>  }
> -- 
> 1.7.7.6

... but I'm not going to ack this: I just don't share your zest
for mucking around with what I don't understand, and don't have
the time to spare to understand it well enough.

>From the look of it, if an error did occur in init_stub_pte(),
then the special mapping of STUB_CODE and STUB_DATA would not
be installed, so this area would be invisible to munmap and exit,
and with your patch then the pages allocated likely to be leaked.

Which is not to say that the existing code is actually correct:
you're probably right that it's technically wrong.  But it would
be very hard to get init_stub_pte() to fail, and has anyone
reported a problem with it?  My guess is not, and my own
inclination to dabble here is zero.

Hugh

Re: [uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Chen G. <gan...@as...>]

On 11/13/2013 05:07 PM, Richard Weinberger wrote:
> Am 13.11.2013 06:06, schrieb Chen Gang:
>> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
>> succeed, they may be used, so in the next failure, we have to skip them
>> to let exit_mmap() or do_munmap() to process it.
>>
>> According to "Documentation/vm/locking", 'mm->page_table_lock' is for
>> using vma list, so not need it when its related vmas are detached or
>> unmapped from using vma list.
>>
>> The related work flow:
>>
>>   exit_mmap() ->
>>     unmap_vmas(); /* so not need mm->page_table_lock */
>>     free_pgtables();
>>
>>   do_munmap()->
>>     detach_vmas_to_be_unmapped(); /* so not need mm->page_table_lock */
>>     unmap_region() ->
>>       free_pgtables();
>>
>>   free_pgtables() ->
>>     free_pgd_range() ->
>>       free_pud_range() ->
>>         free_pmd_range() ->
>>           free_pte_range() ->
>>             pmd_clear();
>>             pte_free_tlb();
>>           pud_clear();
>>           pmd_free_tlb();
>>         pgd_clear(); 
>>         pud_free_tlb();
>>
>>
>> Signed-off-by: Chen Gang <gan...@as...>
> 
> Sounds reasonable to me.
> *But* there are patches you from out there that tried to fix similar issues and got reverted later.
> Now I'm a bit nervous and want a ACK from mm folks to have this verified.
> It's not that I don't trust you, but I really don't trust you. ;-)
> 

OK, thanks.

> Thanks,
> //richard
> 
> 

-- 
Chen Gang

Re: [uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Richard W. <ri...@no...>]

Am 13.11.2013 06:06, schrieb Chen Gang:
> Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
> succeed, they may be used, so in the next failure, we have to skip them
> to let exit_mmap() or do_munmap() to process it.
> 
> According to "Documentation/vm/locking", 'mm->page_table_lock' is for
> using vma list, so not need it when its related vmas are detached or
> unmapped from using vma list.
> 
> The related work flow:
> 
>   exit_mmap() ->
>     unmap_vmas(); /* so not need mm->page_table_lock */
>     free_pgtables();
> 
>   do_munmap()->
>     detach_vmas_to_be_unmapped(); /* so not need mm->page_table_lock */
>     unmap_region() ->
>       free_pgtables();
> 
>   free_pgtables() ->
>     free_pgd_range() ->
>       free_pud_range() ->
>         free_pmd_range() ->
>           free_pte_range() ->
>             pmd_clear();
>             pte_free_tlb();
>           pud_clear();
>           pmd_free_tlb();
>         pgd_clear(); 
>         pud_free_tlb();
> 
> 
> Signed-off-by: Chen Gang <gan...@as...>

Sounds reasonable to me.
*But* there are patches you from out there that tried to fix similar issues and got reverted later.
Now I'm a bit nervous and want a ACK from mm folks to have this verified.
It's not that I don't trust you, but I really don't trust you. ;-)

Thanks,
//richard

[uml-user] [PATCH] arch: um: kernel: skas: mmu: remove pmd_free() and pud_free() for failure processing in init_stub_pte()

[Chen G. <gan...@as...>]

Unfortunately, p?d_alloc() and p?d_free() are not pair!! If p?d_alloc()
succeed, they may be used, so in the next failure, we have to skip them
to let exit_mmap() or do_munmap() to process it.

According to "Documentation/vm/locking", 'mm->page_table_lock' is for
using vma list, so not need it when its related vmas are detached or
unmapped from using vma list.

The related work flow:

  exit_mmap() ->
    unmap_vmas(); /* so not need mm->page_table_lock */
    free_pgtables();

  do_munmap()->
    detach_vmas_to_be_unmapped(); /* so not need mm->page_table_lock */
    unmap_region() ->
      free_pgtables();

  free_pgtables() ->
    free_pgd_range() ->
      free_pud_range() ->
        free_pmd_range() ->
          free_pte_range() ->
            pmd_clear();
            pte_free_tlb();
          pud_clear();
          pmd_free_tlb();
        pgd_clear(); 
        pud_free_tlb();


Signed-off-by: Chen Gang <gan...@as...>
---
 arch/um/kernel/skas/mmu.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/um/kernel/skas/mmu.c b/arch/um/kernel/skas/mmu.c
index 007d550..3fd1951 100644
--- a/arch/um/kernel/skas/mmu.c
+++ b/arch/um/kernel/skas/mmu.c
@@ -40,9 +40,9 @@ static int init_stub_pte(struct mm_struct *mm, unsigned long proc,
 	return 0;
 
  out_pte:
-	pmd_free(mm, pmd);
+	/* used by mm->pgd->pud, will free in do_munmap() or exit_mmap() */
  out_pmd:
-	pud_free(mm, pud);
+	/* used by mm->pgd, will free in do_munmap() or exit_mmap() */
  out:
 	return -ENOMEM;
 }
-- 
1.7.7.6

Re: [uml-user] UML: Get's stuck

[Thomas M. <th...@m3...>]

Am Mittwoch, den 06.11.2013, 20:59 +0100 schrieb Richard Weinberger:
> Am 06.11.2013 20:52, schrieb Thomas Meyer:
> > Am Mittwoch, den 06.11.2013, 13:40 +0100 schrieb Richard Weinberger:
> >> On Tue, Nov 5, 2013 at 9:21 PM, Thomas Meyer <th...@m3...> wrote:
> >>> Hi,
> >>>
> >>> I'm running Fedora 20 inside a 3.12 UML kernel and the "yum upgrade -y"
> >>> command seems to get stuck after a while/few minutes.
> >>>
> >>> Any ideas what's going one here? How to debug this?
> >>>
> >>> It looks like the process running yum is in state ptrace stopped, but
> >>> doesn't continue.
> >>
> >> Got only yum stuck or the whole UML kernel?
> > 
> > How to tell? It feels like the whole kernel got stuck.
> 
> Login on another shell... :)

oops, yes, of course! I tried that and the getty was able to receive my
username, but after pressing enter nothing happened any more, some
timeout message appeared.

I logged in via mconsole and did an emergency sync and a halt command
and restarted uml. now I'm receiving funny warnings/bad pages:

systemd-udevd[599]: starting version 208
EXT4-fs (ubda): re-mounted. Opts: (null)
systemd-journald[338]: Received request to flush runtime journal from
PID 1
systemd-journald[338]:
File /var/log/journal/8e4cbfea404512ae70096c6202c9a3bf/system.journal
corrupted or uncleanly shut down, renaming and replacing.
------------[ cut here ]------------
WARNING: CPU: 0 PID: 0 at lib/timerqueue.c:74 timerqueue_del+0x57/0x60()
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.12.0-00048-gbe408cd #22
6036d968 60370947 00000000 00000000 00000009 60324f52 0000004a 6036d9b0 
       602972e5 6036da00 60030bc1 6036d9d0 90b153c0 6036da10 603816c0
6037e4e8 
       00000000 00000001 8dccbcf0 6036da10 60030d15 6036da30 601cf007
603816c0 
Call Trace: 
6036d9a8:  [<602972e5>] dump_stack+0x17/0x19
6036d9b8:  [<60030bc1>] warn_slowpath_common+0x71/0x90
6036da08:  [<60030d15>] warn_slowpath_null+0x15/0x20
6036da18:  [<601cf007>] timerqueue_del+0x57/0x60
6036da38:  [<6004dfe6>] __remove_hrtimer+0x46/0xa0
6036da78:  [<6004e548>] __hrtimer_start_range_ns+0xd8/0x1e0
6036dad8:  [<6004e683>] hrtimer_start+0x13/0x20
6036dae8:  [<60067e12>] __tick_nohz_idle_enter.constprop.28+0x2d2/0x360
6036db58:  [<60068329>] tick_nohz_irq_exit+0x19/0x20
6036db68:  [<60034f45>] irq_exit+0x85/0xa0
6036db78:  [<6005dac8>] generic_handle_irq+0x28/0x30
6036db88:  [<60014fa8>] do_IRQ+0x28/0x40
6036dba8:  [<60016af0>] timer_handler+0x20/0x30
6036dbc8:  [<6002834e>] real_alarm_handler+0x3e/0x50
6036dd38:  [<60028b53>] os_nsecs+0x13/0x30
6036dd58:  [<60028b53>] os_nsecs+0x13/0x30
6036dd78:  [<60028a98>] timer_one_shot+0x68/0x80
6036dda8:  [<60016acc>] itimer_next_event+0xc/0x10
6036ddb8:  [<6006704a>] clockevents_program_event+0x6a/0xf0
6036dde8:  [<6006780a>] tick_program_event+0x1a/0x20
6036ddf8:  [<6004df9b>] hrtimer_force_reprogram+0x6b/0x70
6036de08:  [<6004e03c>] __remove_hrtimer+0x9c/0xa0
6036de28:  [<601cef40>] timerqueue_add+0x60/0xb0
6036de48:  [<6004e514>] __hrtimer_start_range_ns+0xa4/0x1e0
6036dea8:  [<6004e683>] hrtimer_start+0x13/0x20
6036deb8:  [<6007c298>] rcu_sched_qs+0x78/0x90
6036dee8:  [<60028224>] unblock_signals+0x64/0x80
6036df08:  [<60015b0a>] arch_cpu_idle+0x3a/0x50
6036df18:  [<6007c3cf>] rcu_idle_enter+0x6f/0xb0
6036df38:  [<6005da4e>] cpu_startup_entry+0x8e/0xe0
6036df48:  [<602991b9>] schedule_preempt_disabled+0x9/0x10
6036df58:  [<60294228>] rest_init+0x68/0x70
6036df68:  [<600027f5>] check_bugs+0xe/0x19
6036df78:  [<60001635>] start_kernel+0x27f/0x286
6036df80:  [<600011c5>] unknown_bootoption+0x0/0x185
6036dfb8:  [<6000289a>] start_kernel_proc+0x31/0x35
6036dfd8:  [<6001561a>] new_thread_handler+0x7a/0xa0

---[ end trace 41ecadffe5cf650c ]---
BUG: Bad page state in process systemd-journal  pfn:2d25c
page:0000000062c97420 count:0 mapcount:1 mapping:          (null)
index:0x2
page flags: 0x80008(uptodate|swapbacked)
Modules linked in:
CPU: 0 PID: 338 Comm: systemd-journal Tainted: G        W
3.12.0-00048-gbe408cd #22
8dc759b8 60370947 60309985 62c97420 00000000 62c97458 60383ac0 8dc75a00 
       602972e5 8dc75a30 60082ce0 ffffffffff0a0210 8dc75adc 8dc75a50
62c97420 8dc75a60 
       60082df0 60309982 62c97420 00080008 00000000 8dc75aa0 60084561
00000000 
Call Trace: 
8dc759f8:  [<602972e5>] dump_stack+0x17/0x19
8dc75a08:  [<60082ce0>] bad_page+0xb0/0x100
8dc75a38:  [<60082df0>] free_pages_prepare+0xc0/0xd0
8dc75a68:  [<60084561>] free_hot_cold_page+0x21/0x130
8dc75aa8:  [<60084ace>] free_hot_cold_page_list+0x3e/0x60
8dc75ad8:  [<60087958>] release_pages+0x158/0x1a0
8dc75b38:  [<60087a62>] pagevec_lru_move_fn+0xc2/0xe0
8dc75b50:  [<60087120>] __pagevec_lru_add_fn+0x0/0xc0
8dc75b98:  [<60087e91>] lru_add_drain_cpu+0x71/0x80
8dc75bb8:  [<60087f6b>] lru_add_drain+0xb/0x10
8dc75bc8:  [<600a0136>] exit_mmap+0x46/0x170
8dc75bf0:  [<60018a50>] copy_chunk_to_user+0x0/0x30
8dc75c28:  [<6002e2a7>] mmput.part.62+0x27/0xc0
8dc75c48:  [<6002e359>] mmput+0x19/0x20
8dc75c58:  [<6003117a>] exit_mm+0x10a/0x150
8dc75ca8:  [<60031de1>] do_exit+0x331/0x4a0
8dc75ce8:  [<600330de>] do_group_exit+0x3e/0xd0
8dc75d18:  [<6003de7b>] get_signal_to_deliver+0x1bb/0x4d0
8dc75d48:  [<600535cb>] wake_up_state+0xb/0x10
8dc75d88:  [<60016757>] kern_do_signal+0x57/0x150
8dc75e08:  [<60028460>] set_signals+0x30/0x40
8dc75e28:  [<6003d175>] force_sig_info+0xb5/0xd0
8dc75e68:  [<60016871>] do_signal+0x21/0x30
8dc75e88:  [<60017d14>] fatal_sigsegv+0x24/0x30
8dc75ea8:  [<6002b2d3>] userspace+0x2c3/0x4d0
8dc75f78:  [<600273d7>] save_registers+0x17/0x30
8dc75f88:  [<6002df20>] arch_prctl+0x150/0x180
8dc75fd8:  [<600156a9>] fork_handler+0x69/0x70

Disabling lock debugging due to kernel taint
BUG: Bad page state in process systemd-journal  pfn:2cc8c
page:0000000062c82ea0 count:0 mapcount:1 mapping:          (null)
index:0x3
page flags: 0x80008(uptodate|swapbacked)
Modules linked in:
CPU: 0 PID: 338 Comm: systemd-journal Tainted: G    B   W
3.12.0-00048-gbe408cd #22
8dc759b8 60370947 60309985 62c82ea0 00000000 62c82ed8 60383ac0 8dc75a00 
       602972e5 8dc75a30 60082ce0 ffffffffff0a0210 8dc75adc 8dc75a50
62c82ea0 8dc75a60 
       60082df0 60309982 62c82ea0 00080008 00000000 8dc75aa0 60084561
00000000 
Call Trace: 
8dc759f8:  [<602972e5>] dump_stack+0x17/0x19
8dc75a08:  [<60082ce0>] bad_page+0xb0/0x100
8dc75a38:  [<60082df0>] free_pages_prepare+0xc0/0xd0
8dc75a68:  [<60084561>] free_hot_cold_page+0x21/0x130
8dc75aa8:  [<60084ace>] free_hot_cold_page_list+0x3e/0x60
8dc75ad8:  [<60087958>] release_pages+0x158/0x1a0
8dc75b38:  [<60087a62>] pagevec_lru_move_fn+0xc2/0xe0
8dc75b50:  [<60087120>] __pagevec_lru_add_fn+0x0/0xc0
8dc75b98:  [<60087e91>] lru_add_drain_cpu+0x71/0x80
8dc75bb8:  [<60087f6b>] lru_add_drain+0xb/0x10
8dc75bc8:  [<600a0136>] exit_mmap+0x46/0x170
8dc75bf0:  [<60018a50>] copy_chunk_to_user+0x0/0x30
8dc75c28:  [<6002e2a7>] mmput.part.62+0x27/0xc0
8dc75c48:  [<6002e359>] mmput+0x19/0x20
8dc75c58:  [<6003117a>] exit_mm+0x10a/0x150
8dc75ca8:  [<60031de1>] do_exit+0x331/0x4a0
8dc75ce8:  [<600330de>] do_group_exit+0x3e/0xd0
8dc75d18:  [<6003de7b>] get_signal_to_deliver+0x1bb/0x4d0
8dc75d48:  [<600535cb>] wake_up_state+0xb/0x10
8dc75d88:  [<60016757>] kern_do_signal+0x57/0x150
8dc75e08:  [<60028460>] set_signals+0x30/0x40
8dc75e28:  [<6003d175>] force_sig_info+0xb5/0xd0
8dc75e68:  [<60016871>] do_signal+0x21/0x30
8dc75e88:  [<60017d14>] fatal_sigsegv+0x24/0x30
8dc75ea8:  [<6002b2d3>] userspace+0x2c3/0x4d0
8dc75f78:  [<600273d7>] save_registers+0x17/0x30
8dc75f88:  [<6002df20>] arch_prctl+0x150/0x180
8dc75fd8:  [<600156a9>] fork_handler+0x69/0x70

BUG: failure at mm/slab.c:1813/kmem_freepages()!
Kernel panic - not syncing: BUG!
CPU: 0 PID: 338 Comm: systemd-journal Tainted: G    B   W
3.12.0-00048-gbe408cd #22
8dc75988 60370947 00000000 602ffc6e 8de9a000 9080cdf0 00000000 8dc759d0 
       602972e5 8dc75ad0 60294a4a 00000000 3000000008 8dc75ae0 8dc75a00
8dc75a30 
       60423e00 00000007 00000006 8dc75720 000000f7 00000715 602a4944
ffffffffffffffff 
Call Trace: 
8dc759c8:  [<602972e5>] dump_stack+0x17/0x19
8dc759d8:  [<60294a4a>] panic+0xf4/0x1e2
8dc75a68:  [<60084619>] free_hot_cold_page+0xd9/0x130
8dc75aa8:  [<60087362>] __put_single_page+0x22/0x30
8dc75ad8:  [<600ae4a5>] kmem_freepages.isra.69+0x135/0x140
8dc75af8:  [<600aedb9>] slab_destroy+0x29/0x60
8dc75b18:  [<600aef2c>] free_block+0x13c/0x150
8dc75b48:  [<60296210>] cache_flusharray+0x60/0x84
8dc75b78:  [<600aed87>] kmem_cache_free+0xa7/0xb0
8dc75ba8:  [<6009d1f5>] remove_vma+0x45/0x50
8dc75bc8:  [<600a01b4>] exit_mmap+0xc4/0x170
8dc75c28:  [<6002e2a7>] mmput.part.62+0x27/0xc0
8dc75c48:  [<6002e359>] mmput+0x19/0x20
8dc75c58:  [<6003117a>] exit_mm+0x10a/0x150
8dc75ca8:  [<60031de1>] do_exit+0x331/0x4a0
8dc75ce8:  [<600330de>] do_group_exit+0x3e/0xd0
8dc75d18:  [<6003de7b>] get_signal_to_deliver+0x1bb/0x4d0
8dc75d48:  [<600535cb>] wake_up_state+0xb/0x10
8dc75d88:  [<60016757>] kern_do_signal+0x57/0x150
8dc75e08:  [<60028460>] set_signals+0x30/0x40
8dc75e28:  [<6003d175>] force_sig_info+0xb5/0xd0
8dc75e68:  [<60016871>] do_signal+0x21/0x30
8dc75e88:  [<60017d14>] fatal_sigsegv+0x24/0x30
8dc75ea8:  [<6002b2d3>] userspace+0x2c3/0x4d0
8dc75f78:  [<600273d7>] save_registers+0x17/0x30
8dc75f88:  [<6002df20>] arch_prctl+0x150/0x180
8dc75fd8:  [<600156a9>] fork_handler+0x69/0x70


Modules linked in:
Pid: 338, comm: systemd-journal Tainted: G    B   W
3.12.0-00048-gbe408cd
RIP: 0033:[<0000000041621463>]
RSP: 0000007fbfe99b28  EFLAGS: 00000246
RAX: 0000000000000001 RBX: 0000007fbfe99b40 RCX: ffffffffffffffff
RDX: 0000000000000001 RSI: 0000007fbfe99b30 RDI: 0000000000000007
RBP: 00000000ffffffff R08: 0000000000000001 R09: 000000552ace5943
R10: 00000000ffffffff R11: 0000000000000246 R12: 0000007fbfe99b30
R13: 00000000000003e8 R14: 0004ea87f4e0a28c R15: 0000000000000000
Call Trace: 
8dc75968:  [<6001837b>] panic_exit+0x2b/0x50
8dc75978:  [<60016990>] show_stack+0x40/0xe0
8dc75988:  [<6004fb2c>] notifier_call_chain+0x4c/0x70
8dc759c8:  [<6004fb71>] atomic_notifier_call_chain+0x11/0x20
8dc759d8:  [<60294a5b>] panic+0x105/0x1e2
8dc75a68:  [<60084619>] free_hot_cold_page+0xd9/0x130
8dc75aa8:  [<60087362>] __put_single_page+0x22/0x30
8dc75ad8:  [<600ae4a5>] kmem_freepages.isra.69+0x135/0x140
8dc75af8:  [<600aedb9>] slab_destroy+0x29/0x60
8dc75b18:  [<600aef2c>] free_block+0x13c/0x150
8dc75b48:  [<60296210>] cache_flusharray+0x60/0x84
8dc75b78:  [<600aed87>] kmem_cache_free+0xa7/0xb0
8dc75ba8:  [<6009d1f5>] remove_vma+0x45/0x50
8dc75bc8:  [<600a01b4>] exit_mmap+0xc4/0x170
8dc75c28:  [<6002e2a7>] mmput.part.62+0x27/0xc0
8dc75c48:  [<6002e359>] mmput+0x19/0x20
8dc75c58:  [<6003117a>] exit_mm+0x10a/0x150
8dc75ca8:  [<60031de1>] do_exit+0x331/0x4a0
8dc75ce8:  [<600330de>] do_group_exit+0x3e/0xd0
8dc75d18:  [<6003de7b>] get_signal_to_deliver+0x1bb/0x4d0
8dc75d48:  [<600535cb>] wake_up_state+0xb/0x10
8dc75d88:  [<60016757>] kern_do_signal+0x57/0x150
8dc75e08:  [<60028460>] set_signals+0x30/0x40
8dc75e28:  [<6003d175>] force_sig_info+0xb5/0xd0
8dc75e68:  [<60016871>] do_signal+0x21/0x30
8dc75e88:  [<60017d14>] fatal_sigsegv+0x24/0x30
8dc75ea8:  [<6002b2d3>] userspace+0x2c3/0x4d0
8dc75f78:  [<600273d7>] save_registers+0x17/0x30
8dc75f88:  [<6002df20>] arch_prctl+0x150/0x180
8dc75fd8:  [<600156a9>] fork_handler+0x69/0x70

------------[ cut here ]------------
WARNING: CPU: 0 PID: 618 at lib/timerqueue.c:74 timerqueue_del
+0x57/0x60()
Modules linked in:
CPU: 0 PID: 618 Comm: plymouthd Not tainted 3.12.0-00048-gbe408cd #22
6036f5b8 60370947 6004fc41 00000000 00000009 60324f52 0000004a 6036f600 
       602972e5 6036f650 60030bc1 6036f830 6036f630 00000000 603816c0
6037e4e8 
       00000002 00000000 603816c0 6036f660 60030d15 6036f680 601cf007
603816c0 
Call Trace: 
6036f5c8:  [<6004fc41>] raw_notifier_call_chain+0x11/0x20
6036f5f8:  [<602972e5>] dump_stack+0x17/0x19
6036f608:  [<60030bc1>] warn_slowpath_common+0x71/0x90
6036f658:  [<60030d15>] warn_slowpath_null+0x15/0x20
6036f668:  [<601cf007>] timerqueue_del+0x57/0x60
6036f688:  [<6004dfe6>] __remove_hrtimer+0x46/0xa0
6036f6c8:  [<6004e2fd>] __run_hrtimer.isra.35+0x2d/0xf0
6036f6e8:  [<6004e7c7>] hrtimer_interrupt+0xb7/0x210
6036f738:  [<60016a3f>] um_timer+0xf/0x20
6036f748:  [<6005e0f1>] handle_irq_event_percpu+0x31/0x130
6036f798:  [<6005e213>] handle_irq_event+0x23/0x40
6036f7b8:  [<60060287>] handle_edge_irq+0x67/0x120
6036f7d8:  [<6005dac8>] generic_handle_irq+0x28/0x30
6036f7e8:  [<60014fa3>] do_IRQ+0x23/0x40
6036f808:  [<60016af0>] timer_handler+0x20/0x30
6036f828:  [<6002834e>] real_alarm_handler+0x3e/0x50
6036f838:  [<6001a400>] winch_thread+0x0/0x1b0
6036f8b0:  [<6003f612>] sigsuspend+0x22/0x90
6036fb48:  [<6002840a>] alarm_handler+0x3a/0x50
6036fb68:  [<60027f7d>] hard_handler+0x7d/0xc0
6036fba0:  [<6001a400>] winch_thread+0x0/0x1b0
6036fc18:  [<6001a400>] winch_thread+0x0/0x1b0
6036fc68:  [<6003f612>] sigsuspend+0x22/0x90

---[ end trace 41ecadffe5cf650c ]---


> 
> >> Does yum a ptrace() within UML or did you observe that from the outside?
> > 
> > I saw it from outside in below process listing.
> 
> Okay. All UML childs do ptrace() as UML uses ptrace() for system call emulation.
> 
> >>
> >>> The process tree looks also strange:
> >>>
> >>> 20330 pts/3    S+     1:18  |   \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20337 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20338 pts/3    S+     0:03  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20339 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20347 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20405 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20469 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20615 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #1 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeiW6d5k
> >>> 20625 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeiW6d5k
> >>> 20626 ?        Zs     0:00  |       \_ [linux] <defunct>
> >>> 20630 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20642 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20650 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20651 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20663 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20681 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20684 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20690 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20691 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20699 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20709 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20722 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20754 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #2 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipetxRIbS
> >>> 20757 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipetxRIbS
> >>> 20755 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #6 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipedhXmGp
> >>> 20762 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipedhXmGp
> >>> 20758 ?        Zs     0:00  |       \_ [linux] <defunct>
> >>> 20760 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20763 ?        Zs     0:00  |       \_ [linux] <defunct>
> >>> 20797 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #3 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeULItXd
> >>> 20812 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeULItXd
> >>> 20813 ?        Zs     0:00  |       \_ [linux] <defunct>
> >>> 20815 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #5 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeaKUbD3
> >>> 20876 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeaKUbD3
> >>> 20877 ?        Zs     0:00  |       \_ [linux] <defunct>
> >>> 20896 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 20909 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 21005 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 21007 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
> >>> 21019 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 21112 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 21125 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
> >>> 22164 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 22211 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 22224 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 22380 pts/3    t+     0:51  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 21965 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 21968 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 21983 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 22053 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 22058 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>> 22887 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> >>
> >> Remain the tasks in state Z or are they fipping around?
> > 
> > All process remain in thier state. nothing seems to happen any more.
> 
> Ok. The it would be nice to find out what the UML main thread does.
> gdb can tell you.
> 
> >> Maybe the UML userspace creates many threads and on the host side UML
> >> didn't call wait() jet...
> > 
> > I don't think so. yum is probably not a big thread user, I guess.
> 
> Isn't it a huge chunk of python? ;-)
> 
> Thanks,
> //richard

Re: [uml-user] UML: Get's stuck

[Richard W. <ri...@no...>]

Am 06.11.2013 20:52, schrieb Thomas Meyer:
> Am Mittwoch, den 06.11.2013, 13:40 +0100 schrieb Richard Weinberger:
>> On Tue, Nov 5, 2013 at 9:21 PM, Thomas Meyer <th...@m3...> wrote:
>>> Hi,
>>>
>>> I'm running Fedora 20 inside a 3.12 UML kernel and the "yum upgrade -y"
>>> command seems to get stuck after a while/few minutes.
>>>
>>> Any ideas what's going one here? How to debug this?
>>>
>>> It looks like the process running yum is in state ptrace stopped, but
>>> doesn't continue.
>>
>> Got only yum stuck or the whole UML kernel?
> 
> How to tell? It feels like the whole kernel got stuck.

Login on another shell... :)

>> Does yum a ptrace() within UML or did you observe that from the outside?
> 
> I saw it from outside in below process listing.

Okay. All UML childs do ptrace() as UML uses ptrace() for system call emulation.

>>
>>> The process tree looks also strange:
>>>
>>> 20330 pts/3    S+     1:18  |   \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20337 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20338 pts/3    S+     0:03  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20339 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20347 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20405 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20469 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20615 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #1 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeiW6d5k
>>> 20625 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeiW6d5k
>>> 20626 ?        Zs     0:00  |       \_ [linux] <defunct>
>>> 20630 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20642 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20650 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20651 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20663 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20681 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20684 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20690 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20691 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20699 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20709 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20722 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20754 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #2 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipetxRIbS
>>> 20757 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipetxRIbS
>>> 20755 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #6 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipedhXmGp
>>> 20762 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipedhXmGp
>>> 20758 ?        Zs     0:00  |       \_ [linux] <defunct>
>>> 20760 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20763 ?        Zs     0:00  |       \_ [linux] <defunct>
>>> 20797 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #3 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeULItXd
>>> 20812 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeULItXd
>>> 20813 ?        Zs     0:00  |       \_ [linux] <defunct>
>>> 20815 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #5 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeaKUbD3
>>> 20876 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeaKUbD3
>>> 20877 ?        Zs     0:00  |       \_ [linux] <defunct>
>>> 20896 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 20909 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 21005 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 21007 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
>>> 21019 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 21112 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 21125 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
>>> 22164 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 22211 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 22224 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 22380 pts/3    t+     0:51  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 21965 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 21968 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 21983 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 22053 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 22058 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>> 22887 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
>>
>> Remain the tasks in state Z or are they fipping around?
> 
> All process remain in thier state. nothing seems to happen any more.

Ok. The it would be nice to find out what the UML main thread does.
gdb can tell you.

>> Maybe the UML userspace creates many threads and on the host side UML
>> didn't call wait() jet...
> 
> I don't think so. yum is probably not a big thread user, I guess.

Isn't it a huge chunk of python? ;-)

Thanks,
//richard

Re: [uml-user] UML: Get's stuck

[Thomas M. <th...@m3...>]

Am Mittwoch, den 06.11.2013, 13:40 +0100 schrieb Richard Weinberger:
> On Tue, Nov 5, 2013 at 9:21 PM, Thomas Meyer <th...@m3...> wrote:
> > Hi,
> >
> > I'm running Fedora 20 inside a 3.12 UML kernel and the "yum upgrade -y"
> > command seems to get stuck after a while/few minutes.
> >
> > Any ideas what's going one here? How to debug this?
> >
> > It looks like the process running yum is in state ptrace stopped, but
> > doesn't continue.
> 
> Got only yum stuck or the whole UML kernel?

How to tell? It feels like the whole kernel got stuck.

> Does yum a ptrace() within UML or did you observe that from the outside?

I saw it from outside in below process listing.

> 
> > The process tree looks also strange:
> >
> > 20330 pts/3    S+     1:18  |   \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20337 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20338 pts/3    S+     0:03  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20339 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20347 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20405 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20469 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20615 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #1 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeiW6d5k
> > 20625 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeiW6d5k
> > 20626 ?        Zs     0:00  |       \_ [linux] <defunct>
> > 20630 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20642 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20650 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20651 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20663 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20681 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20684 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20690 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20691 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20699 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20709 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20722 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20754 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #2 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipetxRIbS
> > 20757 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipetxRIbS
> > 20755 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #6 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipedhXmGp
> > 20762 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipedhXmGp
> > 20758 ?        Zs     0:00  |       \_ [linux] <defunct>
> > 20760 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20763 ?        Zs     0:00  |       \_ [linux] <defunct>
> > 20797 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #3 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeULItXd
> > 20812 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeULItXd
> > 20813 ?        Zs     0:00  |       \_ [linux] <defunct>
> > 20815 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #5 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeaKUbD3
> > 20876 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeaKUbD3
> > 20877 ?        Zs     0:00  |       \_ [linux] <defunct>
> > 20896 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 20909 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 21005 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 21007 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
> > 21019 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 21112 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 21125 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
> > 22164 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 22211 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 22224 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 22380 pts/3    t+     0:51  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 21965 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 21968 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 21983 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 22053 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 22058 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> > 22887 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 
> Remain the tasks in state Z or are they fipping around?

All process remain in thier state. nothing seems to happen any more.

> Maybe the UML userspace creates many threads and on the host side UML
> didn't call wait() jet...

I don't think so. yum is probably not a big thread user, I guess.

> 
> >
> >
> > ------------------------------------------------------------------------------
> > November Webinars for C, C++, Fortran Developers
> > Accelerate application performance with scalable programming models. Explore
> > techniques for threading, error checking, porting, and tuning. Get the most
> > from the latest Intel processors and coprocessors. See abstracts and register
> > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> > _______________________________________________
> > User-mode-linux-user mailing list
> > Use...@li...
> > https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
> 
> 
> 

Re: [uml-user] UML: Get's stuck

[Richard W. <ric...@gm...>]

On Tue, Nov 5, 2013 at 9:21 PM, Thomas Meyer <th...@m3...> wrote:
> Hi,
>
> I'm running Fedora 20 inside a 3.12 UML kernel and the "yum upgrade -y"
> command seems to get stuck after a while/few minutes.
>
> Any ideas what's going one here? How to debug this?
>
> It looks like the process running yum is in state ptrace stopped, but
> doesn't continue.

Got only yum stuck or the whole UML kernel?
Does yum a ptrace() within UML or did you observe that from the outside?

> The process tree looks also strange:
>
> 20330 pts/3    S+     1:18  |   \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20337 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20338 pts/3    S+     0:03  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20339 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20347 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20405 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20469 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20615 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #1 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeiW6d5k
> 20625 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeiW6d5k
> 20626 ?        Zs     0:00  |       \_ [linux] <defunct>
> 20630 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20642 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20650 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20651 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20663 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20681 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20684 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20690 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20691 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20699 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20709 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20722 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20754 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #2 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipetxRIbS
> 20757 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipetxRIbS
> 20755 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #6 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipedhXmGp
> 20762 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipedhXmGp
> 20758 ?        Zs     0:00  |       \_ [linux] <defunct>
> 20760 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20763 ?        Zs     0:00  |       \_ [linux] <defunct>
> 20797 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #3 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeULItXd
> 20812 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeULItXd
> 20813 ?        Zs     0:00  |       \_ [linux] <defunct>
> 20815 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #5 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeaKUbD3
> 20876 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeaKUbD3
> 20877 ?        Zs     0:00  |       \_ [linux] <defunct>
> 20896 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 20909 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 21005 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 21007 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
> 21019 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 21112 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 21125 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
> 22164 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 22211 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 22224 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 22380 pts/3    t+     0:51  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 21965 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 21968 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 21983 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 22053 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 22058 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
> 22887 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20

Remain the tasks in state Z or are they fipping around?
Maybe the UML userspace creates many threads and on the host side UML
didn't call wait() jet...

>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user



-- 
Thanks,
//richard

[uml-user] UML: Get's stuck

[Thomas M. <th...@m3...>]

Hi,

I'm running Fedora 20 inside a 3.12 UML kernel and the "yum upgrade -y"
command seems to get stuck after a while/few minutes.

Any ideas what's going one here? How to debug this?

It looks like the process running yum is in state ptrace stopped, but
doesn't continue.

The process tree looks also strange:

20330 pts/3    S+     1:18  |   \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
20337 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20
20338 pts/3    S+     0:03  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20339 pts/3    S+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20347 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20405 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20469 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20615 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #1 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeiW6d5k
20625 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeiW6d5k
20626 ?        Zs     0:00  |       \_ [linux] <defunct>
20630 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20642 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20650 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20651 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20663 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20681 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20684 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20690 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20691 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20699 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20709 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20722 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20754 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #2 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipetxRIbS
20757 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipetxRIbS
20755 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #6 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipedhXmGp
20762 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipedhXmGp
20758 ?        Zs     0:00  |       \_ [linux] <defunct>
20760 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20763 ?        Zs     0:00  |       \_ [linux] <defunct>
20797 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #3 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeULItXd
20812 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeULItXd
20813 ?        Zs     0:00  |       \_ [linux] <defunct>
20815 pts/3    S+     0:00  |       \_ xterm -T Virtual Console #5 (fedora20) -e port-helper -uml-socket /tmp/xterm-pipeaKUbD3
20876 ?        Ss     0:00  |       |   \_ port-helper -uml-socket /tmp/xterm-pipeaKUbD3
20877 ?        Zs     0:00  |       \_ [linux] <defunct>
20896 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
20909 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
21005 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
21007 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
21019 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
21112 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
21125 pts/3    Z+     0:00  |       \_ [uml_net] <defunct>
22164 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
22211 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
22224 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
22380 pts/3    t+     0:51  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
21965 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
21968 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
21983 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
22053 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
22058 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 
22887 pts/3    t+     0:00  |       \_ ./linux ubd0=ext3fs.img mem=768M systemd.unit=multi-user.target umid=fedora20 

with kind regards
thomas

Re: [uml-user] [patch] uml: check length in exitcode_proc_write()

[Richard W. <ri...@no...>]

Am 29.10.2013 20:06, schrieb Dan Carpenter:
> We don't cap the size of buffer from the user so we could write past
> the end of the array here.  Only root can write to this file.
> 
> Reported-by: Nico Golde <ni...@ng...>
> Reported-by: Fabian Yamaguchi <fa...@go...>
> Signed-off-by: Dan Carpenter <dan...@or...>

Thanks everyone!
Patch applied and an it's way to Linus' tree.

Thanks,
//richard

> diff --git a/arch/um/kernel/exitcode.c b/arch/um/kernel/exitcode.c
> index 829df49..41ebbfe 100644
> --- a/arch/um/kernel/exitcode.c
> +++ b/arch/um/kernel/exitcode.c
> @@ -40,9 +40,11 @@ static ssize_t exitcode_proc_write(struct file *file,
>  		const char __user *buffer, size_t count, loff_t *pos)
>  {
>  	char *end, buf[sizeof("nnnnn\0")];
> +	size_t size;
>  	int tmp;
>  
> -	if (copy_from_user(buf, buffer, count))
> +	size = min(count, sizeof(buf));
> +	if (copy_from_user(buf, buffer, size))
>  		return -EFAULT;
>  
>  	tmp = simple_strtol(buf, &end, 0);
> 

[uml-user] [patch] uml: check length in exitcode_proc_write()

[Dan C. <dan...@or...>]

We don't cap the size of buffer from the user so we could write past
the end of the array here.  Only root can write to this file.

Reported-by: Nico Golde <ni...@ng...>
Reported-by: Fabian Yamaguchi <fa...@go...>
Signed-off-by: Dan Carpenter <dan...@or...>

diff --git a/arch/um/kernel/exitcode.c b/arch/um/kernel/exitcode.c
index 829df49..41ebbfe 100644
--- a/arch/um/kernel/exitcode.c
+++ b/arch/um/kernel/exitcode.c
@@ -40,9 +40,11 @@ static ssize_t exitcode_proc_write(struct file *file,
 		const char __user *buffer, size_t count, loff_t *pos)
 {
 	char *end, buf[sizeof("nnnnn\0")];
+	size_t size;
 	int tmp;
 
-	if (copy_from_user(buf, buffer, count))
+	size = min(count, sizeof(buf));
+	if (copy_from_user(buf, buffer, size))
 		return -EFAULT;
 
 	tmp = simple_strtol(buf, &end, 0);

Re: [uml-user] [PATCH] um: remove used STDIO_CONSOLE Kconfig param

[Richard W. <ri...@no...>]

Am 27.10.2013 08:06, schrieb Michael Opdenacker:
> This removes the STDIO_CONSOLE Kconfig parameter which
> is defined but no longer used anywhere in the makefiles and source code.
> 
> Signed-off-by: Michael Opdenacker <mic...@fr...>

Looks good.
Queued for 3.13.

Thanks,
//richard

> ---
>  arch/um/Kconfig.char | 4 ----
>  1 file changed, 4 deletions(-)
> 
> diff --git a/arch/um/Kconfig.char b/arch/um/Kconfig.char
> index b9d7c42..f10738d 100644
> --- a/arch/um/Kconfig.char
> +++ b/arch/um/Kconfig.char
> @@ -6,10 +6,6 @@ config STDERR_CONSOLE
>  	help
>  	  console driver which dumps all printk messages to stderr.
>  
> -config STDIO_CONSOLE
> -	bool
> -	default y
> -
>  config SSL
>  	bool "Virtual serial line"
>  	help
> 

[uml-user] [PATCH] um: remove used STDIO_CONSOLE Kconfig param

[Michael O. <mic...@fr...>]

This removes the STDIO_CONSOLE Kconfig parameter which
is defined but no longer used anywhere in the makefiles and source code.

Signed-off-by: Michael Opdenacker <mic...@fr...>
---
 arch/um/Kconfig.char | 4 ----
 1 file changed, 4 deletions(-)

diff --git a/arch/um/Kconfig.char b/arch/um/Kconfig.char
index b9d7c42..f10738d 100644
--- a/arch/um/Kconfig.char
+++ b/arch/um/Kconfig.char
@@ -6,10 +6,6 @@ config STDERR_CONSOLE
 	help
 	  console driver which dumps all printk messages to stderr.
 
-config STDIO_CONSOLE
-	bool
-	default y
-
 config SSL
 	bool "Virtual serial line"
 	help
-- 
1.8.1.2