user-mode-linux-user

Re: [uml-user] understanding child process

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

On Sun, Apr 30, 2017 at 8:46 AM, Lakshmipathi.G
<lak...@gm...> wrote:
> Hi Russ,
>
> Thanks for the response. I tried with Slackware root file system with
> same kernel, now it doesn't spawn as many child process. Its possibly
> related to root file system i guess (may be something like getty
> process?).

UML creates for every process within UML a stub process on the host side.

-- 
Thanks,
//richard

Re: [uml-user] [PATCH] um: Fix _print_addr()

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

On Sun, Dec 25, 2016 at 11:11 PM, Richard Weinberger <ri...@no...> wrote:
> Recent changes to printk() broke UML's stack trace
> output. Kill the root of the problem by using a single
> printk() statement.
>
> Signed-off-by: Richard Weinberger <ri...@no...>
> ---
>  arch/um/kernel/sysrq.c | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
> index aa1b56f5ac68..18eddf677ec6 100644
> --- a/arch/um/kernel/sysrq.c
> +++ b/arch/um/kernel/sysrq.c
> @@ -17,10 +17,8 @@
>
>  static void _print_addr(void *data, unsigned long address, int reliable)
>  {
> -       pr_info(" [<%08lx>]", address);
> -       pr_cont(" %s", reliable ? "" : "? ");
> -       print_symbol("%s", address);
> -       pr_cont("\n");
> +       pr_info(" [<%08lx>] %s%pF\n", address, reliable ? "" : "? ",
> +               (void *)address);
>  }
>
>  static const struct stacktrace_ops stackops = {

Applied.

-- 
Thanks,
//richard

Re: [uml-user] [PATCH] um: Include kbuild.h instead of duplicating its macros

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

On Mon, Apr 3, 2017 at 9:54 PM, Matthias Kaehlcke <mk...@ch...> wrote:
> Signed-off-by: Matthias Kaehlcke <mk...@ch...>
> ---
>  arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +--------
>  1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/arch/x86/um/shared/sysdep/kernel-offsets.h b/arch/x86/um/shared/sysdep/kernel-offsets.h
> index 46a9df99f3c5..7e1d35b6ad5c 100644
> --- a/arch/x86/um/shared/sysdep/kernel-offsets.h
> +++ b/arch/x86/um/shared/sysdep/kernel-offsets.h
> @@ -2,16 +2,9 @@
>  #include <linux/sched.h>
>  #include <linux/elf.h>
>  #include <linux/crypto.h>
> +#include <linux/kbuild.h>
>  #include <asm/mman.h>
>
> -#define DEFINE(sym, val) \
> -       asm volatile("\n->" #sym " %0 " #val : : "i" (val))
> -
> -#define BLANK() asm volatile("\n->" : : )
> -
> -#define OFFSET(sym, str, mem) \
> -       DEFINE(sym, offsetof(struct str, mem));
> -
>  void foo(void)
>  {
>  #include <common-offsets.h>
> --
> 2.12.2.564.g063fe858b8-goog
>

Applied.

-- 
Thanks,
//richard

Re: [uml-user] understanding child process

[Lakshmipathi.G <lak...@gm...>]

Hi Russ,

Thanks for the response. I tried with Slackware root file system with
same kernel, now it doesn't spawn as many child process. Its possibly
related to root file system i guess (may be something like getty
process?).

Cheers.

On 4/30/17, Russell Lewis <rus...@gm...> wrote:
> I'm certainly no UML expert!  But I suspect that these are the various
> kernel processes that Linux creates when it boots up.  I would assume that
> you cannot disable these without breaking the Linux kernel.
>
> Russ
>
> On Sat, Apr 29, 2017 at 7:57 PM, Lakshmipathi.G <lak...@gm...>
> wrote:
>
>> Hi,
>>
>> When I launch single UML instance as: ./kernel64-4.3.5
>> ubda="cow,./CentOS6.x-AMD64-root_fs" mem=512m umid="uml"
>> I see quite few child process with pstree:
>>
>> ───kernel64-4.3.5(4084)─┬─kernel64-4.3.5(4089)
>>            │            │
>>                                            ├─kernel64-4.3.5(4090)
>>            │            │
>>                                            ├─kernel64-4.3.5(4091)
>>            │            │
>>                                            ├─kernel64-4.3.5(4092)
>>            │            │
>>                                            ├─kernel64-4.3.5(4093)
>>            │            │
>>                                            ├─kernel64-4.3.5(4207)
>>            │            │
>>                                            ├─kernel64-4.3.5(4464)
>>            │            │
>>                                            ├─kernel64-4.3.5(4790)
>>            │            │
>>                                            └─kernel64-4.3.5(4813)
>>
>>
>>
>> Any thoughts on these process are 4090,4091,4092,4093 etc? Are the needed
>> or we can disable them? thanks for any help/pointers.
>>
>> ----
>> Cheers,
>> Lakshmipathi.G
>> http://www.giis.co.in
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> User-mode-linux-user mailing list
>> Use...@li...
>> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
>>
>>
>


-- 
----
Cheers,
Lakshmipathi.G
http://www.giis.co.in http://www.webminal.org

[uml-user] understanding child process

[Lakshmipathi.G <lak...@gm...>]

Hi,

When I launch single UML instance as: ./kernel64-4.3.5
ubda="cow,./CentOS6.x-AMD64-root_fs" mem=512m umid="uml"
I see quite few child process with pstree:

───kernel64-4.3.5(4084)─┬─kernel64-4.3.5(4089)
           │
│
├─kernel64-4.3.5(4090)
           │
│
├─kernel64-4.3.5(4091)
           │
│
├─kernel64-4.3.5(4092)
           │
│
├─kernel64-4.3.5(4093)
           │
│
├─kernel64-4.3.5(4207)
           │
│
├─kernel64-4.3.5(4464)
           │
│
├─kernel64-4.3.5(4790)
           │
│
└─kernel64-4.3.5(4813)



Any thoughts on these process are 4090,4091,4092,4093 etc? Are the needed
or we can disable them? thanks for any help/pointers.

----
Cheers,
Lakshmipathi.G
http://www.giis.co.in

Re: [uml-user] [PATCH] um: Include kbuild.h instead of duplicating its macros

[Masahiro Y. <yam...@so...>]

2017-04-18 16:44 GMT+09:00 Richard Weinberger <ri...@no...>:
> Matthias,
>
> Am 17.04.2017 um 22:37 schrieb Matthias Kaehlcke:
>> El Mon, Apr 03, 2017 at 12:54:58PM -0700 Matthias Kaehlcke ha dit:
>>
>>> Signed-off-by: Matthias Kaehlcke <mk...@ch...>
>>> ---
>>>  arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +--------
>>>  1 file changed, 1 insertion(+), 8 deletions(-)
>>>
>>> diff --git a/arch/x86/um/shared/sysdep/kernel-offsets.h b/arch/x86/um/shared/sysdep/kernel-offsets.h
>>> index 46a9df99f3c5..7e1d35b6ad5c 100644
>>> --- a/arch/x86/um/shared/sysdep/kernel-offsets.h
>>> +++ b/arch/x86/um/shared/sysdep/kernel-offsets.h
>>> @@ -2,16 +2,9 @@
>>>  #include <linux/sched.h>
>>>  #include <linux/elf.h>
>>>  #include <linux/crypto.h>
>>> +#include <linux/kbuild.h>
>>>  #include <asm/mman.h>
>>>
>>> -#define DEFINE(sym, val) \
>>> -    asm volatile("\n->" #sym " %0 " #val : : "i" (val))
>>> -
>>> -#define BLANK() asm volatile("\n->" : : )
>>> -
>>> -#define OFFSET(sym, str, mem) \
>>> -    DEFINE(sym, offsetof(struct str, mem));
>>> -
>>>  void foo(void)
>>>  {
>>>  #include <common-offsets.h>
>>> --
>>
>> Ping, any comment on this patch?
>
> Looks good, nothing exploded while a quick test.
> I'll queue it for the next merge window. :-)
>
> Thanks,
> //richard


If not too late, please feel free to add my

Reviewed-by: Masahiro Yamada <yam...@so...>




-- 
Best Regards
Masahiro Yamada

Re: [uml-user] [PATCH] um: Include kbuild.h instead of duplicating its macros

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

Matthias,

Am 17.04.2017 um 22:37 schrieb Matthias Kaehlcke:
> El Mon, Apr 03, 2017 at 12:54:58PM -0700 Matthias Kaehlcke ha dit:
> 
>> Signed-off-by: Matthias Kaehlcke <mk...@ch...>
>> ---
>>  arch/x86/um/shared/sysdep/kernel-offsets.h | 9 +--------
>>  1 file changed, 1 insertion(+), 8 deletions(-)
>>
>> diff --git a/arch/x86/um/shared/sysdep/kernel-offsets.h b/arch/x86/um/shared/sysdep/kernel-offsets.h
>> index 46a9df99f3c5..7e1d35b6ad5c 100644
>> --- a/arch/x86/um/shared/sysdep/kernel-offsets.h
>> +++ b/arch/x86/um/shared/sysdep/kernel-offsets.h
>> @@ -2,16 +2,9 @@
>>  #include <linux/sched.h>
>>  #include <linux/elf.h>
>>  #include <linux/crypto.h>
>> +#include <linux/kbuild.h>
>>  #include <asm/mman.h>
>>  
>> -#define DEFINE(sym, val) \
>> -	asm volatile("\n->" #sym " %0 " #val : : "i" (val))
>> -
>> -#define BLANK() asm volatile("\n->" : : )
>> -
>> -#define OFFSET(sym, str, mem) \
>> -	DEFINE(sym, offsetof(struct str, mem));
>> -
>>  void foo(void)
>>  {
>>  #include <common-offsets.h>
>> -- 
> 
> Ping, any comment on this patch?

Looks good, nothing exploded while a quick test.
I'll queue it for the next merge window. :-)

Thanks,
//richard

Re: [uml-user] UML not maintained anymore?

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

On Fri, Mar 17, 2017 at 4:46 PM, Pavel Machek <pa...@uc...> wrote:
> On Tue 2017-02-28 16:28:11, Natale Patriciello wrote:
>> It seems there is no interest in fixing bugs (such as [1]). Moreover,
>> same guest filesystem (same host os, distribution, etc.) on two
>> different machines (i7-2630 the first, i7-7700HQ the second) yield
>> different results, with crashes and corruption of filesystem in the
>> modern computer.  So, can I consider UML as a legacy thing in the Linux
>> kernel? With what I can replace it (I'm doing TCP research, and I focus
>> on the networking stack)?
>
> Well.. if it worked before and does not work now, that's a regression
> and will be fixed. Bisect would be useful.
>
> If it never worked on new CPUs, that's different situation...

Yep, a bisect would be good.
Regressions are rather easy to fix.

UML is more or less in legacy mode an I work on it purely in my very limited
spare time. That's why I don't have time to track down and solve every
single bug.

-- 
Thanks,
//richard

[uml-user] UML not maintained anymore?

[Natale P. <nat...@gm...>]

It seems there is no interest in fixing bugs (such as [1]). Moreover,
same guest filesystem (same host os, distribution, etc.) on two
different machines (i7-2630 the first, i7-7700HQ the second) yield
different results, with crashes and corruption of filesystem in the
modern computer.  So, can I consider UML as a legacy thing in the Linux
kernel? With what I can replace it (I'm doing TCP research, and I focus
on the networking stack)?

Thank you

[1] https://sourceforge.net/p/user-mode-linux/mailman/message/35663374/ 

Re: [uml-user] PC change, and errors in have_xstate_support

[Natale P. <nat...@gm...>]

On 13/02/17 at 03:47, Dan Milon wrote:
> Yes, CPU matters apparently. I got hit by this badly.
> 
> I traced the chain of calls into the kernel, and apparently this has to
> do with fpu related features.
> you have to set eagerfpu=off in your kernel boot options. Also note that
> there is a 6 options limit. Any option after the 6th will be ignored.

This is a sad news. Anyway, with this option I have the same problem. To
make everything worse, I though my system was running with my patch, but
in reality no xterm is opened and the guest systemd is reporting a lot
of errors.

Proof of eagerfpu disabled in the host:

[    0.000000] Linux version 4.9.8-1-ARCH (builduser@tobias) (gcc version 6.3.1 20170109 (GCC) ) #1 SMP PREEMPT Mon Feb 6 12:59:40 CET 2017
[    0.000000] Command line: BOOT_IMAGE=/vmlinuz-linux eagerfpu=off root=UUID=ba5db090-54da-4c66-b75d-51e7047f38f7 rw quiet
[    0.000000] x86/fpu: eagerfpu switching disabled, disabling the following xstate features: 0x18.
[    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[    0.000000] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[    0.000000] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[    0.000000] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'compacted' format.
[    0.000000] x86/fpu: Using 'lazy' FPU context switches.

My patch leads to the following:

Core dump limits :
	soft - NONE
	hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking environment variables for a tempdir.../tmp/nat
Checking if /tmp/nat is on tmpfs...OK
Checking PROT_EXEC mmap in /tmp/nat...OK
Adding 26710016 bytes to physical memory to account for exec-shield gap
Linux version 4.10.0-rc8-uml-00205-g7089db84e356-dirty (nat@judith) (gcc version 6.3.1 20170109 (GCC) ) #19 Mon Feb 13 16:32:53 CET 2017
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 135443
Kernel command line: mem=512M ubd0=/home/nat/Work/Linux_UML/fs/fs.ext4 root=98:0
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 509592K/550372K available (2647K kernel code, 697K rwdata, 772K rodata, 111K init, 171K bss, 40780K reserved, 0K cma-reserved)
NR_IRQS:15
clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns
Calibrating delay loop... 6955.82 BogoMIPS (lpj=34779136)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
Checking that host ptys support output SIGIO...Yes
Checking that host ptys support SIGIO on close...No, enabling workaround
devtmpfs: initialized
Using 2.6 host AIO
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
NET: Registered protocol family 16
clocksource: Switched to clocksource timer
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
console [stderr0] disabled
mconsole (version 2) initialized on /home/nat/.uml/cbj73V/mconsole
Checking host MADV_REMOVE support...OK
futex hash table entries: 256 (order: 0, 6144 bytes)
workingset: timestamp_bits=46 max_order=17 bucket_order=0
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
NET: Registered protocol family 17
Initialized stdio console driver
Console initialized on /dev/tty0
console [tty0] enabled
Initializing software serial port version 1
console [mc-1] enabled
EXT4-fs (ubda): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (ubda): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (ubda): INFO: recovery required on readonly filesystem
EXT4-fs (ubda): write access will be enabled during recovery
EXT4-fs (ubda): recovery complete
EXT4-fs (ubda): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 98:0.
devtmpfs: mounted
This architecture does not have kernel memory protection.
random: fast init done
systemd[1]: systemd 232 running in system mode. (+PAM -AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN)
systemd[1]: Detected virtualization uml.
systemd[1]: Detected architecture x86-64.

Welcome to Arch Linux!

systemd[1]: No hostname configured.
systemd[1]: Set hostname to <localhost>.
systemd[1]: Failed to enable kbrequest handling: Inappropriate ioctl for device
systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[  OK  ] Started Forward Password Requests to Wall Directory Watch.
systemd[1]: Reached target Remote File Systems.
[  OK  ] Reached target Remote File Systems.
systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[  OK  ] Started Dispatch Password Requests to Console Directory Watch.
systemd[1]: Reached target Paths.
[  OK  ] Reached target Paths.
[  OK  ] Listening on udev Kernel Socket.
[  OK  ] Reached target Swap.
[  OK  ] Created slice System Slice.
         Mounting Temporary Directory...
[  OK  ] Listening on Journal Socket (/dev/log).
[  OK  ] Set up automount Arbitrary Executable File Formats File System Automount Point.
[  OK  ] Listening on Process Core Dump Socket.
[  OK  ] Created slice system-getty.slice.
         Mounting POSIX Message Queue File System...
[  OK  ] Listening on LVM2 metadata daemon socket.
[  OK  ] Listening on Journal Socket.
         Starting Apply Kernel Variables...
         Starting Journal Service...
         Starting Remount Root and Kernel File Systems...
[  OK  ] Listening on Device-mapper event daemon FIFOs.
[  OK  ] Created slice User and Session Slice.
[  OK  ] Reached target Slices.
[  OK  ] Listening on udev Control Socket.
[  OK  ] Reached target Encrypted Volumes.
[  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
[  OK  ] Mounted Temporary Directory.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started Remount Root and Kernel File Systems.
         Starting udev Coldplug all Devices...
         Starting Load/Save Random Seed...
         Starting Create Static Device Nodes in /dev...
[  OK  ] Started Journal Service.
         Starting Flush Journal to Persistent Storage...
[  OK  ] Started Create Static Device Nodes in /dev.
[  OK  ] Reached target Local File Systems (Pre).
[  OK  ] Reached target Local File Systems.
         Starting udev Kernel Device Manager...
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started udev Kernel Device Manager.
systemd-journald[42]: Received request to flush runtime journal from PID 1
[  OK  ] Started Flush Journal to Persistent Storage.
         Starting Create Volatile Files and Directories...
[  OK  ] Started udev Coldplug all Devices.
[FAILED] Failed to start Create Volatile Files and Directories.
See 'systemctl status systemd-tmpfiles-setup.service' for details.
         Starting Update UTMP about System Boot/Shutdown...
[FAILED] Failed to start Update UTMP about System Boot/Shutdown.
See 'systemctl status systemd-update-utmp.service' for details.
[  OK  ] Reached target System Initialization.
[  OK  ] Started Daily verification of password and group files.
[  OK  ] Started Daily rotation of log files.
[  OK  ] Started Daily man-db cache update.
[  OK  ] Started Daily Cleanup of Temporary Directories.
[  OK  ] Reached target Timers.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Basic System.
         Starting Permit User Sessions...
         Starting Login Service...
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Started Permit User Sessions.
[  OK  ] Started Getty on tty1.
[  OK  ] Reached target Login Prompts.
[  OK  ] Started Login Service.
[  OK  ] Reached target Multi-User System.
Virtual console 1 assigned device '/dev/pts/4'
Virtual console 6 assigned device '/dev/pts/5'


.. and then nothing more, I need to close the console and to manually kill the
processes.

Nat

Re: [uml-user] PC change, and errors in have_xstate_support

[Dan M. <i...@da...>]

Yes, CPU matters apparently. I got hit by this badly.

I traced the chain of calls into the kernel, and apparently this has to
do with fpu related features.
you have to set eagerfpu=off in your kernel boot options. Also note that
there is a 6 options limit. Any option after the 6th will be ignored.

On 02/13/2017 04:40 PM, Natale Patriciello wrote:
> Hello,
>
> I have a UML configuration that worked fine with the 4.10.0-rc8 version
> in my previous laptop (i7-2740 cpu, blabla.. does it really matters?).
> With "worked fine" I mean that I was able to boot in my custom Archlinux
> image (on an Archlinux host perfectly updated).
>
> I then copied the image and the config in a new laptop (new i7-7700),
> run the make for the kernel, got the kernel binary. 
> When trying to start, I get the following message: (Sorry for the long message!)
>
> $ ./linux mem=512M ubd0=/home/nat/Work/Linux_UML/fs/fs.ext4
> Core dump limits :
> 	soft - NONE
> 	hard - NONE
> Checking that ptrace can change system call numbers...OK
> Checking syscall emulation patch for ptrace...OK
> Checking advanced syscall emulation patch for ptrace...OK
> Checking environment variables for a tempdir.../tmp/nat
> Checking if /tmp/nat is on tmpfs...OK
> Checking PROT_EXEC mmap in /tmp/nat...OK
> Adding 11587584 bytes to physical memory to account for exec-shield gap
> Linux version 4.10.0-rc8-uml-00205-g7089db84e356-dirty (nat@judith) (gcc version 6.3.1 20170109 (GCC) ) #16 Mon Feb 13 15:35:51 CET 2017
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 131808
> Kernel command line: mem=512M ubd0=/home/nat/Work/Linux_UML/fs/fs.ext4 root=98:0
> PID hash table entries: 4096 (order: 3, 32768 bytes)
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
> Memory: 509848K/535604K available (2647K kernel code, 697K rwdata, 772K rodata, 111K init, 171K bss, 25756K reserved, 0K cma-reserved)
> NR_IRQS:15
> clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns
> Calibrating delay loop... 6889.47 BogoMIPS (lpj=34447360)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
> Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
> Checking that host ptys support output SIGIO...Yes
> Checking that host ptys support SIGIO on close...No, enabling workaround
> devtmpfs: initialized
> Using 2.6 host AIO
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
> NET: Registered protocol family 16
> clocksource: Switched to clocksource timer
> VFS: Disk quotas dquot_6.6.0
> VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> NET: Registered protocol family 2
> TCP established hash table entries: 8192 (order: 4, 65536 bytes)
> TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
> TCP: Hash tables configured (established 8192 bind 8192)
> UDP hash table entries: 512 (order: 2, 16384 bytes)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
> NET: Registered protocol family 1
> console [stderr0] disabled
> mconsole (version 2) initialized on /home/nat/.uml/FdImtj/mconsole
> Checking host MADV_REMOVE support...OK
> futex hash table entries: 256 (order: 0, 6144 bytes)
> workingset: timestamp_bits=46 max_order=17 bucket_order=0
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> io scheduler noop registered
> io scheduler deadline registered (default)
> NET: Registered protocol family 17
> Initialized stdio console driver
> Console initialized on /dev/tty0
> console [tty0] enabled
> Initializing software serial port version 1
> console [mc-1] enabled
> EXT4-fs (ubda): couldn't mount as ext3 due to feature incompatibilities
> EXT4-fs (ubda): couldn't mount as ext2 due to feature incompatibilities
> EXT4-fs (ubda): mounted filesystem with ordered data mode. Opts: (null)
> VFS: Mounted root (ext4 filesystem) readonly on device 98:0.
> devtmpfs: mounted
> This architecture does not have kernel memory protection.
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> CPU: 0 PID: 1 Comm: init Not tainted 4.10.0-rc8-uml-00205-g7089db84e356-dirty #16
> Stack:
>  80433ba0 60064332 80430b00 6031bae8
>  600905cc 601d4673 80433bb0 601c9a41
>  80433cd0 60090332 80433be0 6002d3b1
> Call Trace:
>  [<600905cc>] ? 
> printk+0x0/0x94
>  [<6001af21>] 
> show_stack+0x108/0x15e
>  [<60064332>] ? 
> dump_stack_print_info+0xe4/0xed
>  [<600905cc>] ? 
> printk+0x0/0x94
>  [<601d4673>] ? 
> bust_spinlocks+0x0/0x3b
>  [<601c9a41>] 
> dump_stack+0x2a/0x2c
>  [<60090332>] 
> panic+0x170/0x311
>  [<6002d3b1>] ? 
> set_signals+0x28/0x40
>  [<600f2c29>] ? 
> mntput+0x2f/0x31
>  [<600d723f>] ? 
> __fput+0x1d3/0x1e2
>  [<602aa6ec>] ? 
> _cond_resched+0x0/0x42
>  [<600d7292>] ? 
> ____fput+0x10/0x12
>  [<60089c12>] ? 
> cgroup_exit+0x8c/0xcb
>  [<600901c2>] ? 
> panic+0x0/0x311
>  [<60038a29>] 
> do_exit+0x3c3/0x89d
>  [<60038fd7>] 
> do_group_exit+0x8f/0x106
>  [<6002d1ac>] ? 
> block_signals+0x0/0x16
>  [<6002d1ac>] ? 
> block_signals+0x0/0x16
>  [<600423ae>] 
> get_signal+0x4af/0x4e3
>  [<6001ac75>] 
> do_signal+0x27/0x121
>  [<6002d3b1>] ? 
> set_signals+0x28/0x40
>  [<6002d389>] ? 
> set_signals+0x0/0x40
>  [<6004131d>] ? 
> force_sig+0x18/0x1a
>  [<60041932>] ? 
> force_sigsegv+0x5f/0x69
>  [<6001c2d8>] 
> fatal_sigsegv+0x46/0x52
>  [<60032a5f>] ? 
> put_fp_registers+0x10/0x12
>  [<6002fed5>] 
> userspace+0x12b/0x447
>  [<60019d6f>] ? 
> interrupt_end+0x0/0xa0
>  [<600dca10>] ? 
> do_execveat_common+0x519/0x649
>  [<600c9ce1>] ? 
> kmem_cache_alloc+0x0/0x103
>  [<600dcb61>] ? 
> do_execve+0x21/0x23
>  [<600183e4>] ? 
> run_init_process+0x3e/0x42
>  [<600183e8>] ? 
> try_to_run_init_process+0x0/0x44
>  [<600183fe>] ? 
> try_to_run_init_process+0x16/0x44
>  [<600183e8>] ? 
> try_to_run_init_process+0x0/0x44
>  [<60019b98>] 
> new_thread_handler+0xa1/0xa3
>
> I have investigated it, and the problem is in arch/x86/um/os-Linux/registers.c :
>
>  49 int restore_fp_registers(int pid, unsigned long *fp_regs)
>  50 {
>  51   struct iovec iov;
>  52 
>  53   if (have_xstate_support) {
>  54     iov.iov_base = fp_regs;
>  55     iov.iov_len = sizeof(struct _xstate);
>  56     if (ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, &iov) < 0)
>  57       return -errno;
>  58     return 0;
>  59   } else {
>  60     return restore_i387_registers(pid, fp_regs);
>  61   }
>  62 }
>
> At line 56, there is a ptrace call. This call exits with -14. The 14
> number means EFAULT. Well, after some tries, I patched the function to
> always enter the else branch, and then calling restore_i387_registers .
> With my big surprise, using this function allows me to boot correctly
> the system.
>
> Why I can't successfully boot with the stock kernel, with
> have_xstate_support ?
>
> Thank you
> N.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

[uml-user] PC change, and errors in have_xstate_support

[Natale P. <nat...@gm...>]

Hello,

I have a UML configuration that worked fine with the 4.10.0-rc8 version
in my previous laptop (i7-2740 cpu, blabla.. does it really matters?).
With "worked fine" I mean that I was able to boot in my custom Archlinux
image (on an Archlinux host perfectly updated).

I then copied the image and the config in a new laptop (new i7-7700),
run the make for the kernel, got the kernel binary. 
When trying to start, I get the following message: (Sorry for the long message!)

$ ./linux mem=512M ubd0=/home/nat/Work/Linux_UML/fs/fs.ext4
Core dump limits :
	soft - NONE
	hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Checking environment variables for a tempdir.../tmp/nat
Checking if /tmp/nat is on tmpfs...OK
Checking PROT_EXEC mmap in /tmp/nat...OK
Adding 11587584 bytes to physical memory to account for exec-shield gap
Linux version 4.10.0-rc8-uml-00205-g7089db84e356-dirty (nat@judith) (gcc version 6.3.1 20170109 (GCC) ) #16 Mon Feb 13 15:35:51 CET 2017
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 131808
Kernel command line: mem=512M ubd0=/home/nat/Work/Linux_UML/fs/fs.ext4 root=98:0
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
Memory: 509848K/535604K available (2647K kernel code, 697K rwdata, 772K rodata, 111K init, 171K bss, 25756K reserved, 0K cma-reserved)
NR_IRQS:15
clocksource: timer: mask: 0xffffffffffffffff max_cycles: 0x1cd42e205, max_idle_ns: 881590404426 ns
Calibrating delay loop... 6889.47 BogoMIPS (lpj=34447360)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes)
Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes)
Checking that host ptys support output SIGIO...Yes
Checking that host ptys support SIGIO on close...No, enabling workaround
devtmpfs: initialized
Using 2.6 host AIO
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
NET: Registered protocol family 16
clocksource: Switched to clocksource timer
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
console [stderr0] disabled
mconsole (version 2) initialized on /home/nat/.uml/FdImtj/mconsole
Checking host MADV_REMOVE support...OK
futex hash table entries: 256 (order: 0, 6144 bytes)
workingset: timestamp_bits=46 max_order=17 bucket_order=0
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
io scheduler noop registered
io scheduler deadline registered (default)
NET: Registered protocol family 17
Initialized stdio console driver
Console initialized on /dev/tty0
console [tty0] enabled
Initializing software serial port version 1
console [mc-1] enabled
EXT4-fs (ubda): couldn't mount as ext3 due to feature incompatibilities
EXT4-fs (ubda): couldn't mount as ext2 due to feature incompatibilities
EXT4-fs (ubda): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) readonly on device 98:0.
devtmpfs: mounted
This architecture does not have kernel memory protection.
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

CPU: 0 PID: 1 Comm: init Not tainted 4.10.0-rc8-uml-00205-g7089db84e356-dirty #16
Stack:
 80433ba0 60064332 80430b00 6031bae8
 600905cc 601d4673 80433bb0 601c9a41
 80433cd0 60090332 80433be0 6002d3b1
Call Trace:
 [<600905cc>] ? 
printk+0x0/0x94
 [<6001af21>] 
show_stack+0x108/0x15e
 [<60064332>] ? 
dump_stack_print_info+0xe4/0xed
 [<600905cc>] ? 
printk+0x0/0x94
 [<601d4673>] ? 
bust_spinlocks+0x0/0x3b
 [<601c9a41>] 
dump_stack+0x2a/0x2c
 [<60090332>] 
panic+0x170/0x311
 [<6002d3b1>] ? 
set_signals+0x28/0x40
 [<600f2c29>] ? 
mntput+0x2f/0x31
 [<600d723f>] ? 
__fput+0x1d3/0x1e2
 [<602aa6ec>] ? 
_cond_resched+0x0/0x42
 [<600d7292>] ? 
____fput+0x10/0x12
 [<60089c12>] ? 
cgroup_exit+0x8c/0xcb
 [<600901c2>] ? 
panic+0x0/0x311
 [<60038a29>] 
do_exit+0x3c3/0x89d
 [<60038fd7>] 
do_group_exit+0x8f/0x106
 [<6002d1ac>] ? 
block_signals+0x0/0x16
 [<6002d1ac>] ? 
block_signals+0x0/0x16
 [<600423ae>] 
get_signal+0x4af/0x4e3
 [<6001ac75>] 
do_signal+0x27/0x121
 [<6002d3b1>] ? 
set_signals+0x28/0x40
 [<6002d389>] ? 
set_signals+0x0/0x40
 [<6004131d>] ? 
force_sig+0x18/0x1a
 [<60041932>] ? 
force_sigsegv+0x5f/0x69
 [<6001c2d8>] 
fatal_sigsegv+0x46/0x52
 [<60032a5f>] ? 
put_fp_registers+0x10/0x12
 [<6002fed5>] 
userspace+0x12b/0x447
 [<60019d6f>] ? 
interrupt_end+0x0/0xa0
 [<600dca10>] ? 
do_execveat_common+0x519/0x649
 [<600c9ce1>] ? 
kmem_cache_alloc+0x0/0x103
 [<600dcb61>] ? 
do_execve+0x21/0x23
 [<600183e4>] ? 
run_init_process+0x3e/0x42
 [<600183e8>] ? 
try_to_run_init_process+0x0/0x44
 [<600183fe>] ? 
try_to_run_init_process+0x16/0x44
 [<600183e8>] ? 
try_to_run_init_process+0x0/0x44
 [<60019b98>] 
new_thread_handler+0xa1/0xa3

I have investigated it, and the problem is in arch/x86/um/os-Linux/registers.c :

 49 int restore_fp_registers(int pid, unsigned long *fp_regs)
 50 {
 51   struct iovec iov;
 52 
 53   if (have_xstate_support) {
 54     iov.iov_base = fp_regs;
 55     iov.iov_len = sizeof(struct _xstate);
 56     if (ptrace(PTRACE_SETREGSET, pid, NT_X86_XSTATE, &iov) < 0)
 57       return -errno;
 58     return 0;
 59   } else {
 60     return restore_i387_registers(pid, fp_regs);
 61   }
 62 }

At line 56, there is a ptrace call. This call exits with -14. The 14
number means EFAULT. Well, after some tries, I patched the function to
always enter the else branch, and then calling restore_i387_registers .
With my big surprise, using this function allows me to boot correctly
the system.

Why I can't successfully boot with the stock kernel, with
have_xstate_support ?

Thank you
N.

Re: [uml-user] Archive of UML mailing list

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

On Wed, Jan 4, 2017 at 2:54 PM, Enjoy Mindful <enj...@gm...> wrote:
> Hi,
>
> https://marc.info/?l=user-mode-linux-devel
> https://marc.info/?l=user-mode-linux-user
> https://sourceforge.net/p/user-mode-linux/mailman/user-mode-linux-user/
>
> I'm looking for archive tar balls for user-mode-linux-devel and
> user-mode-linux-user mailing
> list. Unfortunately, those three web pages do not provide archive for
> download. It is really
> painful and annoying to search in those pages. I'd prefer to have a
> copy of the archives on my
> computer, so I can read and search with text editor and grep.
>
> Reading the *ancient* mails since 1999, should be a good way for
> understanding how
> UML works.

You can also just ask here questions on UML.

-- 
Thanks,
//richard

[uml-user] Archive of UML mailing list

[Enjoy M. <enj...@gm...>]

Hi,

https://marc.info/?l=user-mode-linux-devel
https://marc.info/?l=user-mode-linux-user
https://sourceforge.net/p/user-mode-linux/mailman/user-mode-linux-user/

I'm looking for archive tar balls for user-mode-linux-devel and
user-mode-linux-user mailing
list. Unfortunately, those three web pages do not provide archive for
download. It is really
painful and annoying to search in those pages. I'd prefer to have a
copy of the archives on my
computer, so I can read and search with text editor and grep.

Reading the *ancient* mails since 1999, should be a good way for
understanding how
UML works.

Thanks

[uml-user] [PATCH] um: Fix _print_addr()

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

Recent changes to printk() broke UML's stack trace
output. Kill the root of the problem by using a single
printk() statement.

Signed-off-by: Richard Weinberger <ri...@no...>
---
 arch/um/kernel/sysrq.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index aa1b56f5ac68..18eddf677ec6 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -17,10 +17,8 @@
 
 static void _print_addr(void *data, unsigned long address, int reliable)
 {
-	pr_info(" [<%08lx>]", address);
-	pr_cont(" %s", reliable ? "" : "? ");
-	print_symbol("%s", address);
-	pr_cont("\n");
+	pr_info(" [<%08lx>] %s%pF\n", address, reliable ? "" : "? ",
+		(void *)address);
 }
 
 static const struct stacktrace_ops stackops = {
-- 
2.10.2

[uml-user] Strange (but reproduceable) crashes inside UML - garbled link URL

[Massimo R. <rim...@in...>]

Reposting the systemd bug report link because it was garbled (likely because it embeds an e-mail address):

>     systemd-journald[58]: Failed to write entry (25 items, 576 bytes), ignoring: Invalid argument
> Please consider that the latter symptom has nothing to do with the problem discussed at this URL (which, however, I have also been experiencing in certain experimental settings): http://tinyurl.com/jrncsxu. Indeed, I am *not*using systemd as init in the tests I am reporting about below.
>

Regards,
Massimo

Re: [uml-user] Mailing list posts subject to approval?

[Massimo R. <rim...@in...>]

Ok. Thank you very much for the feedback.

I have just tried to re-post my original message, this time without attachments, and apparently it got through.

Thank you again,
Massimo


On 10/09/2016 19:57, Thomas Meyer wrote:
> Am 10. September 2016 18:51:02 MESZ, schrieb Massimo Rimondini <rim...@in...>:
>> Hi,
>>
>> I have posted 2 messages to this list more than one month ago, and
>> still they do not show up in the mailing list archives.
>> Considering that the last publicly documented messages date back to
>> last June, I wonder whether there is some kind of background approval
>> process going on.
>>
>> Otherwise, I am a bit prone to thinking that the mailing list is
>> experiencing problems or (worst case) is dead.
>>
>> Thank you and regards,
>> Massimo
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> User-mode-linux-user mailing list
>> Use...@li...
>> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
> Hi,
>
> Mhh, Strange! At least this one came through!
>
> With kind regards
> Thomas
>

[uml-user] Strange (but reproduceable) crashes inside UML

[Massimo R. <rim...@in...>]

Hi,

this is my first appearance on this mailing list, therefore I apologize for writing a problem report as first post.

I am experiencing a rather strange process crash problem inside UML. In short: processes started inside an UML instance randomly (but reproduceably) crash when UML is running on a specific host. Everything works perfectly when the *same*filesystem image and UML kernel are used on other hosts.
The filesystem image has been created using debootstrap (detailed commands in the report below).
Examples of reproduceable problems that I have been observing:
* The following command always segfaults:
    localedef -i en_US -A /usr/share/locale/locale.alias -f UTF-8 en_US.UTF-8
A line similar to the following is correspondingly logged by the kernel:
    localedef[49]: segfault at 0 ip 00000000004079fd sp 0000007fbfce84e0 error 4 in localedef[400000+47000]
* After clearing /var/lib/apt/lists, 'apt-get update' successfully downloads some index files, then hangs forever with a message "[Connecting to]" (yes, without a host name). It is not just the output that misses the server name: a sniffer reveals attempts by apt-get to resolve exactly one more server name than those listed in /etc/apt/sources.list, but this excess server has an empty name (a SRV query is sent for '_http._tcp', which instead should be followed by a valid name as in '_http._tcp.httpredir.debian.org'). Of course, the DNS replies with a failure.
* When systemd is used as init, from time to time I have observed crashes of the udev service or failures to write the journal. Errors similar to the following are logged by the UML kernel:
    systemd-journald[58]: Failed to write entry (25 items, 576 bytes), ignoring: Invalid argument
Please consider that the latter symptom has nothing to do with the problem discussed at this URL (which, however, I have also been experiencing in certain experimental settings): https://www.mail-archive.com/deb...@li.../msg1440903.html. Indeed, I am *not*using systemd as init in the tests I am reporting about below.

I have performed tests with several host/UML/filesystem/configuration combinations, as explained in the following.

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

To document test outcomes, I am using the following abbreviations:

- Host A: Intel i7-6700 3.4GHz, 32GB RAM, running Debian GNU/Linux testing (stretch) with kernel 4.6.0-1-amd64 (supplied by Debian, no modifications)
- Host B: VirtualBox 5.1.0r108711 VM with 1 (virtual CPU), PIIX3 chipset, no execution cap, 7GB RAM, running Ubuntu 16.04.1 LTS (xenial) with kernel 4.4.0-31-generic (supplied by Ubuntu, no modifications), on top of Host A
- Host C: VirtualBox 5.1.0r108711 VM with 4 (virtual) CPUs, PIIX3 chipset, no execution cap, 2GB RAM, running Ubuntu 16.04 LTS (xenial) with kernel 4.4.0-28-generic (supplied by Ubuntu, no modifications), on top of a host with an Intel i7 2.2GHz CPU, 8GB RAM running Mac OS X 10.11.6 (El Capitan)

- UML 1: 4.3.2 64-bit UML kernel, custom compiled into a static executable from vanilla, with a few patches of little relevance applied (https://github.com/maxonthegit/netkit/tree/master/devel/kernel-patches). For reference, the configuration file is https://github.com/maxonthegit/netkit/blob/master/devel/netkit-kernel-config-4.2.1-x86_64
- UML 2: 4.3.5 64-bit UML kernel, obtained from http://uml.devloop.org.uk

- Network SLIRP: using slirp as transport, compiled from the Debian source package (https://packages.debian.org/source/stretch/slirp) with Debian patches applied (by 'apt-get source') and FULL_BOLT enabled.
UML command line argument: eth0=slirp,,/path/to/slirp
- Network NAT: using tuntap as transport, and enabling netfilter's masquerading on the host. Set up on the host using the following commands:
  tunctl -u user -g user -t tun
  ifconfig tun 10.0.0.1 up
  echo 1 >/proc/sys/net/ipv4/ip_forward
  iptables -t nat -A POSTROUTING -j MASQUERADE
A corresponding default route is set up inside UML.
UML command line argument: eth0=tuntap,tun

- Suite: I tried to run UML on filesystem images created using debootstrap for both the 'sid' (unstable) and the 'stretch' testing Debian releases. I used the following commands to generate the images:
  dd if=/dev/zero of=/path/to/fs/image.img bs=1 count=0 seek=10G
  /sbin/mkfs.ext4 -t ext4 -F /path/to/fs/image.img
  mount -o loop /path/to/fs/image.img fs-mount-location
  debootstrap --include=debconf-utils,locales sid fs-mount-location
  cat > temp-fs-mount/startup.sh <<EOF
  #!/bin/bash
    mount -t proc none /proc
    mount -t sysfs none /sys
    mount -t tmpfs none /run
    mountpoint /dev || mount -t devtmpfs none /dev
    echo "nameserver 8.8.8.8" > /etc/resolv.conf
    ip addr add 10.0.2.15/8 dev eth0
    ip link set eth0 up
    ip route add default dev eth0
    /bin/bash
  EOF
  chmod +x fs-mount-location/startup.sh
  umount fs-mount-location
I have been using the *same*2 filesystem image files for all the tests, reverting them to the original state after each test by keeping a backup copy.

Test outcomes are as follows:
- OK: everything works flawlessly inside UML.
- FAIL: software crashes are observed inside UML, as in the examples discussed above (localedef, apt-get, sometimes systemd-journald).

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

The UML command line was as follows:
  kernel-x86_64 umid=test-vm mem=1073741824 ubd0=image.img rw con=null con0=fd:0,fd:1 eth0=<as above> init=/startup.sh

Here are the outcomes:

+------+-----+---------+---------+---------+
| Host | UML | Network |  Suite  | OUTCOME |
+------+-----+---------+---------+---------+
|  A   |  1  |  SLIRP  |   sid   | FAIL    |
|  A   |  1  |   NAT   |   sid   | FAIL    | <= strace
|  A   |  2  |  SLIRP  |   sid   | FAIL    |
|  A   |  2  |   NAT   |   sid   | FAIL    |
|  B   |  1  |  SLIRP  |   sid   | OK      |
|  B   |  1  |   NAT   |   sid   | OK      |
|  B   |  2  |  SLIRP  |   sid   | OK      |
|  B   |  2  |   NAT   |   sid   | OK      |
|  C   |  1  |  SLIRP  |   sid   | OK      | <= strace
|  C   |  1  |   NAT   |   sid   | OK      |
|  C   |  2  |  SLIRP  |   sid   | OK      |
|  C   |  2  |   NAT   |   sid   | OK      |
|  A   |  1  |  SLIRP  | stretch | FAIL    |
|  A   |  1  |   NAT   | stretch | FAIL    |
|  A   |  2  |  SLIRP  | stretch | FAIL    |
|  A   |  2  |   NAT   | stretch | FAIL    |
|  B   |  1  |  SLIRP  | stretch | OK      |
|  B   |  1  |   NAT   | stretch | OK      |
|  B   |  2  |  SLIRP  | stretch | OK      |
|  B   |  2  |   NAT   | stretch | OK      |
|  C   |  1  |  SLIRP  | stretch | OK      |
|  C   |  1  |   NAT   | stretch | OK      |
|  C   |  2  |  SLIRP  | stretch | OK      |
|  C   |  2  |   NAT   | stretch | OK      |
+------+-----+---------+---------+---------+

So, one could come to an easy conclusion: something is wrong with host A. But what?
Here are some additional clues:
- I have performed an 'apt-get upgrade' on host A only a few days ago.
- Everything else works perfectly on host A.
- The problem occurs with two different host kernel versions (4.4.0-1-amd64 and 4.6.0-1-amd64).
- If I 'chroot' in the *same*filesystem image(s) used for the UML tests, everything works perfectly on host A.
- Changing the amount of RAM assigned to UML instances does not solve the problem on host A.
- It does not depend on the processes running on host A: I made a test after booting the host with init=/bin/bash and the problem still occurred.
- Although I am assigning the same amount of RAM to all the UML instances (purposely without 'M' or 'G' suffixes to avoid ambiguities), when UML boots it reports slightly different memory amounts:
On host A: Memory: 1024952K/1056060K available (3108K kernel code, 862K rwdata, 1032K rodata, 121K init, 294K bss, 31108K reserved, 0K cma-reserved)
On host C: Memory: 1024824K/1063076K available (3108K kernel code, 862K rwdata, 1032K rodata, 121K init, 294K bss, 38252K reserved, 0K cma-reserved)
- I have collected an strace of a working and a failing instance of localedef, collected in the scenarios marked in the table above using:
  strace -r -s 256 -T -yy -o out-strace-file -ff -v /usr/bin/localedef -i en_US -A /usr/share/locale/locale.alias -f UTF-8 en_US.UTF-8
These straces are available at the following addresses:
http://pastebin.com/bfjPERkK (failing, PID 378)
http://pastebin.com/BaWTCvjn (failing, PID 379)
http://pastebin.com/pCTttzPz (working, PID 56)
http://pastebin.com/ejXseFsq (working, PID 57)
After sanitization, it is pretty evident that everything is essentially identical up to the SIGSEGV at a 'brk' call. The following command can be used to compare a sane and a faulty output:
  diff -y <(awk '{$1=""; $NF=""; print}' localedef-strace-failing.378 | sed -r 's/\[[0-9]+\]//g') <(awk '{$1=""; $NF=""; print}' localedef-strace-working.56 | sed -r 's/\[[0-9]+\]//g') | less -S

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

I have more or less run out of ideas about how to overcome this problem. Any suggestions are welcome. Thank you very much even for just reading so far.

As a side note, this resembles the kind of problem that was previously reported here: https://sourceforge.net/p/user-mode-linux/mailman/message/34978201/

Regards,
Massimo

Re: [uml-user] Mailing list posts subject to approval?

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

Am 10. September 2016 18:51:02 MESZ, schrieb Massimo Rimondini <rim...@in...>:
>Hi,
>
>I have posted 2 messages to this list more than one month ago, and
>still they do not show up in the mailing list archives.
>Considering that the last publicly documented messages date back to
>last June, I wonder whether there is some kind of background approval
>process going on.
>
>Otherwise, I am a bit prone to thinking that the mailing list is
>experiencing problems or (worst case) is dead.
>
>Thank you and regards,
>Massimo
>
>
>------------------------------------------------------------------------------
>_______________________________________________
>User-mode-linux-user mailing list
>Use...@li...
>https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user

Hi,

Mhh, Strange! At least this one came through!

With kind regards
Thomas

[uml-user] Mailing list posts subject to approval?

[Massimo R. <rim...@in...>]

Hi,

I have posted 2 messages to this list more than one month ago, and still they do not show up in the mailing list archives.
Considering that the last publicly documented messages date back to last June, I wonder whether there is some kind of background approval process going on.

Otherwise, I am a bit prone to thinking that the mailing list is experiencing problems or (worst case) is dead.

Thank you and regards,
Massimo

Re: [uml-user] [user-mode-linux] memory leak in network path

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

Hi!

Am 18.06.2016 um 13:02 schrieb Enrico Mioso:
> Hi guys.
> 
> I am experiencing an user-mode-linux memory leak, that induces the user-mode kernel to eventually panic.
> 
> My sequence of actions to trigger it is relatively simple:
> - start it on an ubuntu 16.04 core image, after installing "ubuntu-standard" package
> - install aptitude and openssh-server if needed
> 
> When I type
> sudo aptitude build-dep gnuradio
> (but any package with lots of dependencies may do), I can see used memory by UML growing and growing.
> When the allocation limit I specify in the command line is reached, then it crashes.
> 
> This problem is triggerable pretty reliably on my box:
> Running a custom-compiled 4.4.12 kernel.
> 
> 
> UML kernel version: 4.6.1-usermodelinux
> 
> Thank you very much guys for your work and attention,

Please share the log of the crash.
How did you figure that UML is consuming more and more memory?

Thanks,
//richard

[uml-user] How to custom a 64-bit ext3 filesystem

[Jotus K. <an_...@12...>]

Hi ,
    Is there any one who can tell me how to make a 64-bit ext3 format filesystem by using mkrootfs tools?


    Any hint or advice is appreciated.

Re: [uml-user] Could UML run via seccomp traps instead of ptrace?

[Jeff D. <jd...@ad...>]

On Thu, May 26, 2016 at 12:49:13AM -0700, Dan Kaminsky wrote:
>     So I'm curious.  There is another option -- seccomp-bpf can trap on
> arbitrary syscalls.  Is there a reason anyone sees why UML couldn't be
> routed through it?

You need to be able to annull system calls.  Dunno if seccomp can do
that, but if it can, as well as read them out which I assume it can,
you're golden.

				Jeff

-- 
Jeff Dike
AddToIt
978-254-0789 (o)
978-394-8986 (c)

[uml-user] Could UML run via seccomp traps instead of ptrace?

[Dan K. <da...@wh...>]

Hello!

   So I've been spending some time in UML (among other virtualization
technologies).  There's some interesting security and performance models it
possibly allows, even in this era of containers and hypervisors.  Ptrace is
being something of a problem though; it's a little hairy and difficult to
scope.  It is unfortunately breaking many things I'm trying to do.

    So I'm curious.  There is another option -- seccomp-bpf can trap on
arbitrary syscalls.  Is there a reason anyone sees why UML couldn't be
routed through it?

--Dan

Re: [uml-user] Kernel panic - not syncing: No init found using initramfs

[Jotus K. <an_...@12...>]

Hi Vegard,
    Thanks for your reply. 
    I got the same result when I used ./linux init=/bin/sh command line to boot uml.
    Finally, I mount my root_fs to /mnt and ldd init. The ldd told me some lib is miss and some lib is 32-bit for my 64-bit init.
    Now, I can boot my UML. 


    Thanks all the same.
Jotus



At 2016-05-23 00:17:38, "Vegard Nossum" <veg...@gm...> wrote:
>On 16 May 2016 at 10:05, kail-gj <an_...@12...> wrote:
>> Hi,
>>     I build my uml from source with CONFIG_INITRAMFS_SOURCE configured with
>> a rootfs text file.  I specify the init file to  busybox as
>>     file /bin/busybox /home/xxxx/busybox/busybox 755 0 0 /init /bin/sh in
>> rootfs text file.
>>     But it does not work and output "kernel panic - not syncing: No init
>> found" error. The full boot log is followed.
>>     Please help me, thanks.
>> -------------------------------------------------
>> boot log:
>
>You still need to pass init= on the command line, no? This shows you
>didn't pass anything:
>
>> Kernel command line: root=98:0
>[...]
>> Kernel panic - not syncing: No init found.  Try passing init= option to
>> kernel.
>
>
>Vegard