user-mode-linux-user

Re: [uml-user] Why it doesn't work on Ubuntu 14.04?

[Balaco B. <bal...@im...>]

> At first please show me both outputs of the 64bit and 32bit kernel.
> 

I'll send them - just with a severe lack of time these last few weeks.

-- 
  Balaco



On Wed, Jun 24, 2015, at 05:33, Richard Weinberger wrote:
> On Tue, Jun 23, 2015 at 1:41 PM, Balaco Baco <bal...@im...> wrote:
> > Before, I tried with 32b and 64b downloaded kernels. Both gave the same
> > error. I have even compiled the kernel, imagining some weird problems of
> > config or the lastest Ubuntu "tricks an and trouble" I have been seeing
> > for some time! No solution. The problem was in the images itself,
> > probably for same kind of reason.
> >
> > Couldn't we make this have a more meaninful error message? Like what
> > you've said, that would make the problem clear to me. Coredump/segfaults
> > and such are not really helpful.
> 
> At first please show me both outputs of the 64bit and 32bit kernel.
> 
> -- 
> Thanks,
> //richard

-- 
http://www.fastmail.com - Faster than the air-speed velocity of an
                          unladen european swallow

Re: [uml-user] Why it doesn't work on Ubuntu 14.04?

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

On Tue, Jun 23, 2015 at 1:41 PM, Balaco Baco <bal...@im...> wrote:
> Before, I tried with 32b and 64b downloaded kernels. Both gave the same
> error. I have even compiled the kernel, imagining some weird problems of
> config or the lastest Ubuntu "tricks an and trouble" I have been seeing
> for some time! No solution. The problem was in the images itself,
> probably for same kind of reason.
>
> Couldn't we make this have a more meaninful error message? Like what
> you've said, that would make the problem clear to me. Coredump/segfaults
> and such are not really helpful.

At first please show me both outputs of the 64bit and 32bit kernel.

-- 
Thanks,
//richard

Re: [uml-user] Why it doesn't work on Ubuntu 14.04?

[Balaco B. <bal...@im...>]

Before, I tried with 32b and 64b downloaded kernels. Both gave the same
error. I have even compiled the kernel, imagining some weird problems of
config or the lastest Ubuntu "tricks an and trouble" I have been seeing
for some time! No solution. The problem was in the images itself,
probably for same kind of reason.

Couldn't we make this have a more meaninful error message? Like what
you've said, that would make the problem clear to me. Coredump/segfaults
and such are not really helpful.

-- 
  Balaco



On Sun, Jun 21, 2015, at 05:35, Richard Weinberger wrote:
> On Sun, Jun 21, 2015 at 4:21 AM, Balaco Baco <bal...@im...> wrote:
> > I'm remotely accessing an Ubuntu 14.04.2 machine. And now I'm trying to
> > run an UML in it, but it is always giving me some errors, and it
> > finishes with segfaults or coredumps.
> >
> > For example, the end of output is:
> >
> > =========================
> > request_module: runaway loop modprobe binfmt-464c
> > Starting init: /sbin/init exists but couldn't execute it (error -8)
> 
> 8 is ENOEXEC.
> Are you trying to use a 64bit userspace with a 32bit kernel?
> 
> > Starting init: /etc/init exists but couldn't execute it (error -13)
> > request_module: runaway loop modprobe binfmt-464c
> > Starting init: /bin/sh exists but couldn't execute it (error -8)
> > Kernel panic - not syncing: No working init found.  Try passing init=
> > option to kernel. See Linux Documentation/init.txt for guidance.
> > CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.11-ckt20 #1
> > Stack:
> >  69037e90 602e26cd 60260fa9 00000000
> >  69037e90 601b0c71 60260fa9 00000000
> >  60260fa9 00000000 69037ea0 60263274
> > Call Trace:
> >  [<60260fa9>] ? printk+0x0/0xa0
> >  [<601b0c71>] ? bust_spinlocks+0x0/0x4f
> >  [<60260fa9>] ? printk+0x0/0xa0
> >  [<60260fa9>] ? printk+0x0/0xa0
> >  [<60263274>] dump_stack+0x2a/0x2c
> >  [<6026071d>] panic+0x141/0x290
> >  [<602605dc>] ? panic+0x0/0x290
> >  [<600b7e82>] ? copy_strings+0x0/0x2b9
> >  [<600b93ec>] ? do_execve+0x53c/0x5a7
> >  [<600185ed>] ? try_to_run_init_process+0x0/0x66
> >  [<600185ed>] ? try_to_run_init_process+0x0/0x66
> >  [<6025ff3b>] kernel_init+0x17e/0x184
> >  [<60019c86>] new_thread_handler+0x81/0xa3
> >
> > Aborted (core dumped)
> > =========================
> >
> > I get the same error with the 32bit kernel, the 64 bit kernel and with a
> > kernel I compiled from source. The "init=" option didn't help either. I
> > don't know what else I should do.
> 
> Is the error really *exactly* the same when you build a 64bit UML?
> 
> -- 
> Thanks,
> //richard

-- 
http://www.fastmail.com - Or how I learned to stop worrying and
                          love email again

Re: [uml-user] Why it doesn't work on Ubuntu 14.04?

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

On Sun, Jun 21, 2015 at 4:21 AM, Balaco Baco <bal...@im...> wrote:
> I'm remotely accessing an Ubuntu 14.04.2 machine. And now I'm trying to
> run an UML in it, but it is always giving me some errors, and it
> finishes with segfaults or coredumps.
>
> For example, the end of output is:
>
> =========================
> request_module: runaway loop modprobe binfmt-464c
> Starting init: /sbin/init exists but couldn't execute it (error -8)

8 is ENOEXEC.
Are you trying to use a 64bit userspace with a 32bit kernel?

> Starting init: /etc/init exists but couldn't execute it (error -13)
> request_module: runaway loop modprobe binfmt-464c
> Starting init: /bin/sh exists but couldn't execute it (error -8)
> Kernel panic - not syncing: No working init found.  Try passing init=
> option to kernel. See Linux Documentation/init.txt for guidance.
> CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.11-ckt20 #1
> Stack:
>  69037e90 602e26cd 60260fa9 00000000
>  69037e90 601b0c71 60260fa9 00000000
>  60260fa9 00000000 69037ea0 60263274
> Call Trace:
>  [<60260fa9>] ? printk+0x0/0xa0
>  [<601b0c71>] ? bust_spinlocks+0x0/0x4f
>  [<60260fa9>] ? printk+0x0/0xa0
>  [<60260fa9>] ? printk+0x0/0xa0
>  [<60263274>] dump_stack+0x2a/0x2c
>  [<6026071d>] panic+0x141/0x290
>  [<602605dc>] ? panic+0x0/0x290
>  [<600b7e82>] ? copy_strings+0x0/0x2b9
>  [<600b93ec>] ? do_execve+0x53c/0x5a7
>  [<600185ed>] ? try_to_run_init_process+0x0/0x66
>  [<600185ed>] ? try_to_run_init_process+0x0/0x66
>  [<6025ff3b>] kernel_init+0x17e/0x184
>  [<60019c86>] new_thread_handler+0x81/0xa3
>
> Aborted (core dumped)
> =========================
>
> I get the same error with the 32bit kernel, the 64 bit kernel and with a
> kernel I compiled from source. The "init=" option didn't help either. I
> don't know what else I should do.

Is the error really *exactly* the same when you build a 64bit UML?

-- 
Thanks,
//richard

[uml-user] Why it doesn't work on Ubuntu 14.04?

[Balaco B. <bal...@im...>]

I'm remotely accessing an Ubuntu 14.04.2 machine. And now I'm trying to
run an UML in it, but it is always giving me some errors, and it
finishes with segfaults or coredumps.

For example, the end of output is:

=========================
request_module: runaway loop modprobe binfmt-464c
Starting init: /sbin/init exists but couldn't execute it (error -8)
Starting init: /etc/init exists but couldn't execute it (error -13)
request_module: runaway loop modprobe binfmt-464c
Starting init: /bin/sh exists but couldn't execute it (error -8)
Kernel panic - not syncing: No working init found.  Try passing init=
option to kernel. See Linux Documentation/init.txt for guidance.
CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.11-ckt20 #1
Stack:
 69037e90 602e26cd 60260fa9 00000000
 69037e90 601b0c71 60260fa9 00000000
 60260fa9 00000000 69037ea0 60263274
Call Trace:
 [<60260fa9>] ? printk+0x0/0xa0
 [<601b0c71>] ? bust_spinlocks+0x0/0x4f
 [<60260fa9>] ? printk+0x0/0xa0
 [<60260fa9>] ? printk+0x0/0xa0
 [<60263274>] dump_stack+0x2a/0x2c
 [<6026071d>] panic+0x141/0x290
 [<602605dc>] ? panic+0x0/0x290
 [<600b7e82>] ? copy_strings+0x0/0x2b9
 [<600b93ec>] ? do_execve+0x53c/0x5a7
 [<600185ed>] ? try_to_run_init_process+0x0/0x66
 [<600185ed>] ? try_to_run_init_process+0x0/0x66
 [<6025ff3b>] kernel_init+0x17e/0x184
 [<60019c86>] new_thread_handler+0x81/0xa3

Aborted (core dumped)
=========================

I get the same error with the 32bit kernel, the 64 bit kernel and with a
kernel I compiled from source. The "init=" option didn't help either. I
don't know what else I should do.



-- 
  Balaco


-- 
http://www.fastmail.com - Access your email from home and the web

Re: [uml-user] BTRFS : starting an uml using BTRFS gives

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

On Sun, May 31, 2015 at 7:13 PM, Toralf Förster <tor...@gm...> wrote:
> I don't get it in moment, at a 64 bit Gentoo Linux (host is Linux t44 4.0.4-hardened-r3) I get :
>
>
> $ /home/tfoerste/devel/linux/linux earlyprintk ubda=t44uml ubdb=/mnt/ramdisk/t44uml_swap eth0=tuntap,tap0,72:ef:3d:b6:67:0c,192.168.1.254 mem=2000M con0=fd:0,fd:1 con=pts umid=uml_t44uml softlockup_all_cpu_backtrace=1
> Core dump limits :
>         soft - 0
>         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...none found
> Checking if /dev/shm is on tmpfs...OK
> Checking PROT_EXEC mmap in /dev/shm...OK
> bootconsole [earlycon0] enabled
> PID hash table entries: 4096 (order: 3, 32768 bytes)
> Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> Memory: 2009296K/2048000K available (3008K kernel code, 673K rwdata, 892K rodata, 113K init, 173K bss, 38704K reserved, 0K cma-reserved)
> NR_IRQS:15
> clocksource itimer: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
> Calibrating delay loop... 5746.68 BogoMIPS (lpj=28733440)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
> Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
> Initializing cgroup subsys blkio
> Initializing cgroup subsys devices
> Initializing cgroup subsys freezer
> 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
> xor: measuring software checksum speed
>    8regs     : 20528.400 MB/sec
>    8regs_prefetch: 17211.600 MB/sec
>    32regs    : 19893.600 MB/sec
>    32regs_prefetch: 16321.600 MB/sec
> xor: using function: 8regs (20528.400 MB/sec)
> NET: Registered protocol family 16
> raid6: int64x1  gen()  3012 MB/s
> raid6: int64x1  xor()  1664 MB/s
> raid6: int64x2  gen()  3137 MB/s
> raid6: int64x2  xor()  2110 MB/s
> raid6: int64x4  gen()  2882 MB/s
> raid6: int64x4  xor()  1801 MB/s
> raid6: int64x8  gen()  2464 MB/s
> raid6: int64x8  xor()  1423 MB/s
> raid6: using algorithm int64x2 gen() 3137 MB/s
> raid6: .... xor() 2110 MB/s, rmw enabled
> raid6: using intx1 recovery algorithm
> Switched to clocksource itimer
> NET: Registered protocol family 2
> TCP established hash table entries: 16384 (order: 5, 131072 bytes)
> TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
> TCP: Hash tables configured (established 16384 bind 16384)
> UDP hash table entries: 1024 (order: 3, 32768 bytes)
> UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
> NET: Registered protocol family 1
> console [stderr0] disabled
> mconsole (version 2) initialized on /home/tfoerste/.uml/uml_t44uml/mconsole
> Checking host MADV_REMOVE support...OK
> futex hash table entries: 256 (order: 0, 6144 bytes)
> VFS: Disk quotas dquot_6.6.0
> VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
> 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
> console [tty0] enabled
>                       bootconsole [earlycon0] disabled
> bootconsole [earlycon0] disabled
>                                 Initializing software serial port version 1
> console [mc-1] enabled
> Failed to initialize ubd device 1 :Couldn't determine size of device's file
> Netdevice 0 (72:ef:3d:b6:67:0c) :
> TUN/TAP backend - IP = 192.168.1.254
> Btrfs loaded
> BTRFS: device fsid 3342a6f8-d944-44df-bffb-f64ac9f0bdc8 devid 1 transid 51 /dev/root
> BTRFS info (device ubda): disk space caching is enabled
> BTRFS: has skinny extents
> VFS: Mounted root (btrfs filesystem) readonly on device 0:13.
> devtmpfs: mounted
>
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 4.1.0-rc5-00161-gaaa20fc
> RIP: 0033:[<00000000602a150d>]
> RSP: 0000032dff262ef8  EFLAGS: 00010212
> RAX: 00000000602a14f9 RBX: 0000000060706da8 RCX: 0000032dfeb94f19
> RDX: 0000000060286650 RSI: 0000032dff263fe8 RDI: 00000000dcede000
> RBP: 0000032dff263fe8 R08: 0000000000000000 R09: 0000000000000000
> R10: 00000000dc81fbd0 R11: 0000000000000246 R12: 00000000dcede000
> R13: 0000032dff263000 R14: 0000000060286b60 R15: 00000000603277f8
> Kernel panic - not syncing: Segfault with no mm
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-rc5-00161-gaaa20fc #2
> Stack:
>
> Modules linked in:
> Pid: 1, comm: swapper Not tainted 4.1.0-rc5-00161-gaaa20fc
> RIP: 0033:[<00000000602898cc>]
> RSP: 0000000060665450  EFLAGS: 00010202
> RAX: 0000000000000006 RBX: 000000006057088f RCX: 0000000060706da8
> RDX: 0000000000000000 RSI: 0000000060715af8 RDI: 0000000000000000
> RBP: 0000000060665480 R08: 0000000060665059 R09: 00000000602cf270
> R10: 0000000000000008 R11: 00000000004685dd R12: 0000000000000001
> R13: 0000032dff262eff R14: 00000000606656f0 R15: 0000000000000001
> Kernel panic - not syncing: Segfault with no mm
>
>
> $ addr2line -e ~/devel/linux/linux 00000000602a150d
> /home/tfoerste/devel/linux/arch/um/os-Linux/skas/process.c:180
>
> $ addr2line -e ~/devel/linux/linux 00000000602898cc
> /home/tfoerste/devel/linux/arch/um/kernel/sysrq.c:52
>
>
>
>
> The /etc/fstab of the 64 bit Gentoo Linux UML guest is :
>
> /dev/ubda               /               btrfs           noatime         0 1
> /dev/ubdb               none            swap            sw              0 0
>
> shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0
>
>
>
> What do I miss ?

Dunno. :)
btrfs works definitely on UML. Does the issue also happen without
hardened stuff?

-- 
Thanks,
//richard

Re: [uml-user] [PATCH] um: Fix a build error

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

Am 15.06.2015 um 16:43 schrieb Firo Yang:
> Gcc5 failed to build uml.
> Update codes to test __GNUC__ with 5 will be happier.
> 
> Signed-off-by: Firo Yang <fi...@gm...>

The issue got already addressed by patches:
[PATCH 2/5] um: Stop abusing __KERNEL__
[PATCH 3/5] um: Remove copy&paste code from init.h

They will appear soon in Linus' tree.

Thanks,
//richard

[uml-user] [PATCH] um: Fix a build error

[Firo Y. <fi...@gm...>]

Gcc5 failed to build uml.
Update codes to test __GNUC__ with 5 will be happier.

Signed-off-by: Firo Yang <fi...@gm...>
---
 arch/um/include/shared/init.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/include/shared/init.h b/arch/um/include/shared/init.h
index b3906f8..3af7098 100644
--- a/arch/um/include/shared/init.h
+++ b/arch/um/include/shared/init.h
@@ -54,7 +54,7 @@ typedef void (*exitcall_t)(void);
 #endif
 
 #else
-#if __GNUC__ == 4
+#if __GNUC__ == 4 || __GNUC__ == 5
 # define __used			__attribute__((__used__))
 #endif
 #endif
-- 
2.4.3

Re: [uml-user] [PATCH 3/3] um/os-Linux: Use char[] for syscall_stub declarations

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

Am 12.10.2014 um 13:02 schrieb Nicolas Iooss:
> When declaring __syscall_stub_start, use the same type in UML userspace
> code as in arch/um/include/asm/sections.h.
> 
> While at it, also declare batch_syscall_stub as char[].
> 
> Signed-off-by: Nicolas Iooss <nic...@m4...>
> ---
>  arch/um/os-Linux/skas/mem.c     |  6 +++---
>  arch/um/os-Linux/skas/process.c | 11 +++++------
>  2 files changed, 8 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/um/os-Linux/skas/mem.c b/arch/um/os-Linux/skas/mem.c
> index 689b18db798f..abb02becca80 100644
> --- a/arch/um/os-Linux/skas/mem.c
> +++ b/arch/um/os-Linux/skas/mem.c
> @@ -19,7 +19,7 @@
>  #include <sysdep/ptrace.h>
>  #include <sysdep/stub.h>
>  
> -extern unsigned long batch_syscall_stub, __syscall_stub_start;
> +extern char batch_syscall_stub[], __syscall_stub_start[];
>  
>  extern void wait_stub_done(int pid);
>  
> @@ -39,8 +39,8 @@ static int __init init_syscall_regs(void)
>  {
>  	get_safe_registers(syscall_regs, NULL);
>  	syscall_regs[REGS_IP_INDEX] = STUB_CODE +
> -		((unsigned long) &batch_syscall_stub -
> -		 (unsigned long) &__syscall_stub_start);
> +		((unsigned long) batch_syscall_stub -
> +		 (unsigned long) __syscall_stub_start);
>  	return 0;
>  }
>  
> diff --git a/arch/um/os-Linux/skas/process.c b/arch/um/os-Linux/skas/process.c
> index 908579f2b0ab..fa934d0c8932 100644
> --- a/arch/um/os-Linux/skas/process.c
> +++ b/arch/um/os-Linux/skas/process.c
> @@ -193,7 +193,7 @@ static void handle_trap(int pid, struct uml_pt_regs *regs,
>  	handle_syscall(regs);
>  }
>  
> -extern int __syscall_stub_start;
> +extern char __syscall_stub_start[];
>  
>  static int userspace_tramp(void *stack)
>  {
> @@ -218,7 +218,7 @@ static int userspace_tramp(void *stack)
>  		 */
>  		int fd;
>  		unsigned long long offset;
> -		fd = phys_mapping(to_phys(&__syscall_stub_start), &offset);
> +		fd = phys_mapping(to_phys(__syscall_stub_start), &offset);
>  		addr = mmap64((void *) STUB_CODE, UM_KERN_PAGE_SIZE,
>  			      PROT_EXEC, MAP_FIXED | MAP_PRIVATE, fd, offset);
>  		if (addr == MAP_FAILED) {
> @@ -245,7 +245,7 @@ static int userspace_tramp(void *stack)
>  
>  		unsigned long v = STUB_CODE +
>  				  (unsigned long) stub_segv_handler -
> -				  (unsigned long) &__syscall_stub_start;
> +				  (unsigned long) __syscall_stub_start;
>  
>  		set_sigstack((void *) STUB_DATA, UM_KERN_PAGE_SIZE);
>  		sigemptyset(&sa.sa_mask);
> @@ -474,7 +474,7 @@ static int __init init_thread_regs(void)
>  	/* Set parent's instruction pointer to start of clone-stub */
>  	thread_regs[REGS_IP_INDEX] = STUB_CODE +
>  				(unsigned long) stub_clone_handler -
> -				(unsigned long) &__syscall_stub_start;
> +				(unsigned long) __syscall_stub_start;
>  	thread_regs[REGS_SP_INDEX] = STUB_DATA + UM_KERN_PAGE_SIZE -
>  		sizeof(void *);
>  #ifdef __SIGNAL_FRAMESIZE
> @@ -582,8 +582,7 @@ int map_stub_pages(int fd, unsigned long code, unsigned long data,
>  	struct proc_mm_op mmop;
>  	int n;
>  	unsigned long long code_offset;
> -	int code_fd = phys_mapping(to_phys((void *) &__syscall_stub_start),
> -				   &code_offset);
> +	int code_fd = phys_mapping(to_phys(__syscall_stub_start), &code_offset);
>  
>  	mmop = ((struct proc_mm_op) { .op        = MM_MMAP,
>  				      .u         =

Thank you Nicoals, all three patches are now in my 4.2 queue!
Special thanks to Thomas Meyer for exhuming this patches. :-)

Thanks,
//richard

Re: [uml-user] [PATCH] um: kernel: ksyms: Export symbol syscall() for fixing modpost issue

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

Am 04.10.2014 um 15:11 schrieb Chen Gang:
> syscall() is implemented in libc.so/a (e.g. for glibc, in "syscall.o"),
> so for normal ".o" files, it is undefined, neither can be found within
> kernel wide, so will break modpost.
> 
> Since ".o" files is OK, can simply export 'syscall' symbol, let modpost
> know about that, then can fix this issue.
> 
> The related error (with allmodconfig under um):
> 
>     MODPOST 1205 modules
>   ERROR: "syscall" [fs/hostfs/hostfs.ko] undefined!
> 
> Signed-off-by: Chen Gang <gan...@gm...>
> ---
>  arch/um/kernel/ksyms.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/um/kernel/ksyms.c b/arch/um/kernel/ksyms.c
> index 543c047..e7780f3 100644
> --- a/arch/um/kernel/ksyms.c
> +++ b/arch/um/kernel/ksyms.c
> @@ -42,3 +42,6 @@ EXPORT_SYMBOL(os_makedev);
>  EXPORT_SYMBOL(add_sigio_fd);
>  EXPORT_SYMBOL(ignore_sigio_fd);
>  EXPORT_SYMBOL(sigio_broken);
> +
> +extern long int syscall (long int __sysno, ...);
> +EXPORT_SYMBOL(syscall);

Thanks Chen, applied to my 4.2 queue!

[uml-user] BTRFS : starting an uml using BTRFS gives

[Toralf F. <tor...@gm...>]

I don't get it in moment, at a 64 bit Gentoo Linux (host is Linux t44 4.0.4-hardened-r3) I get :


$ /home/tfoerste/devel/linux/linux earlyprintk ubda=t44uml ubdb=/mnt/ramdisk/t44uml_swap eth0=tuntap,tap0,72:ef:3d:b6:67:0c,192.168.1.254 mem=2000M con0=fd:0,fd:1 con=pts umid=uml_t44uml softlockup_all_cpu_backtrace=1
Core dump limits :
        soft - 0
        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...none found
Checking if /dev/shm is on tmpfs...OK
Checking PROT_EXEC mmap in /dev/shm...OK
bootconsole [earlycon0] enabled
PID hash table entries: 4096 (order: 3, 32768 bytes)
Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
Memory: 2009296K/2048000K available (3008K kernel code, 673K rwdata, 892K rodata, 113K init, 173K bss, 38704K reserved, 0K cma-reserved)
NR_IRQS:15
clocksource itimer: mask: 0xffffffffffffffff max_cycles: 0x1d854df40, max_idle_ns: 3526361616960 ns
Calibrating delay loop... 5746.68 BogoMIPS (lpj=28733440)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
Initializing cgroup subsys blkio
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
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
xor: measuring software checksum speed
   8regs     : 20528.400 MB/sec
   8regs_prefetch: 17211.600 MB/sec
   32regs    : 19893.600 MB/sec
   32regs_prefetch: 16321.600 MB/sec
xor: using function: 8regs (20528.400 MB/sec)
NET: Registered protocol family 16
raid6: int64x1  gen()  3012 MB/s
raid6: int64x1  xor()  1664 MB/s
raid6: int64x2  gen()  3137 MB/s
raid6: int64x2  xor()  2110 MB/s
raid6: int64x4  gen()  2882 MB/s
raid6: int64x4  xor()  1801 MB/s
raid6: int64x8  gen()  2464 MB/s
raid6: int64x8  xor()  1423 MB/s
raid6: using algorithm int64x2 gen() 3137 MB/s
raid6: .... xor() 2110 MB/s, rmw enabled
raid6: using intx1 recovery algorithm
Switched to clocksource itimer
NET: Registered protocol family 2
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
UDP hash table entries: 1024 (order: 3, 32768 bytes)
UDP-Lite hash table entries: 1024 (order: 3, 32768 bytes)
NET: Registered protocol family 1
console [stderr0] disabled
mconsole (version 2) initialized on /home/tfoerste/.uml/uml_t44uml/mconsole
Checking host MADV_REMOVE support...OK
futex hash table entries: 256 (order: 0, 6144 bytes)
VFS: Disk quotas dquot_6.6.0
VFS: Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
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
console [tty0] enabled
                      bootconsole [earlycon0] disabled
bootconsole [earlycon0] disabled
                                Initializing software serial port version 1
console [mc-1] enabled
Failed to initialize ubd device 1 :Couldn't determine size of device's file
Netdevice 0 (72:ef:3d:b6:67:0c) :
TUN/TAP backend - IP = 192.168.1.254
Btrfs loaded
BTRFS: device fsid 3342a6f8-d944-44df-bffb-f64ac9f0bdc8 devid 1 transid 51 /dev/root
BTRFS info (device ubda): disk space caching is enabled
BTRFS: has skinny extents
VFS: Mounted root (btrfs filesystem) readonly on device 0:13.
devtmpfs: mounted

Modules linked in:
Pid: 1, comm: swapper Not tainted 4.1.0-rc5-00161-gaaa20fc
RIP: 0033:[<00000000602a150d>]
RSP: 0000032dff262ef8  EFLAGS: 00010212
RAX: 00000000602a14f9 RBX: 0000000060706da8 RCX: 0000032dfeb94f19
RDX: 0000000060286650 RSI: 0000032dff263fe8 RDI: 00000000dcede000
RBP: 0000032dff263fe8 R08: 0000000000000000 R09: 0000000000000000
R10: 00000000dc81fbd0 R11: 0000000000000246 R12: 00000000dcede000
R13: 0000032dff263000 R14: 0000000060286b60 R15: 00000000603277f8
Kernel panic - not syncing: Segfault with no mm
CPU: 0 PID: 1 Comm: swapper Not tainted 4.1.0-rc5-00161-gaaa20fc #2
Stack:

Modules linked in:
Pid: 1, comm: swapper Not tainted 4.1.0-rc5-00161-gaaa20fc
RIP: 0033:[<00000000602898cc>]
RSP: 0000000060665450  EFLAGS: 00010202
RAX: 0000000000000006 RBX: 000000006057088f RCX: 0000000060706da8
RDX: 0000000000000000 RSI: 0000000060715af8 RDI: 0000000000000000
RBP: 0000000060665480 R08: 0000000060665059 R09: 00000000602cf270
R10: 0000000000000008 R11: 00000000004685dd R12: 0000000000000001
R13: 0000032dff262eff R14: 00000000606656f0 R15: 0000000000000001
Kernel panic - not syncing: Segfault with no mm


$ addr2line -e ~/devel/linux/linux 00000000602a150d
/home/tfoerste/devel/linux/arch/um/os-Linux/skas/process.c:180

$ addr2line -e ~/devel/linux/linux 00000000602898cc
/home/tfoerste/devel/linux/arch/um/kernel/sysrq.c:52




The /etc/fstab of the 64 bit Gentoo Linux UML guest is :

/dev/ubda               /               btrfs           noatime         0 1
/dev/ubdb               none            swap            sw              0 0

shm                     /dev/shm        tmpfs           nodev,nosuid,noexec     0 0



What do I miss ?

-- 
Toralf
pgp key: 7B1A 07F4 EC82 0F90 D4C2  8936 872A E508 0076 E94E

Re: [uml-user] UML for mips

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

On Mon, Apr 13, 2015 at 8:42 AM, kobabo kobabo <kob...@ou...> wrote:
> Hi,
>
> Is it possible to run UML on mips architecture?

No. So far UML was only ported to Linux/x86.

-- 
Thanks,
//richard

[uml-user] UML for mips

[kobabo k. <kob...@ou...>]

Hi,

Is it possible to run UML on mips architecture?

Thanks,
Koba@@
 		 	   		  

Re: [uml-user] [PATCH 0/4] kbuild: refactor Makefile inclusion

[Michal M. <mm...@su...>]

On 2015-03-27 12:43, Masahiro Yamada wrote:
> Masahiro Yamada (4):
>   kbuild: use relative path to include Makefile
>   kbuild: use relative path more to include Makefile
>   kbuild: include $(src)/Makefile rather than $(obj)/Makefile
>   kbuild: ia64: use $(src)/Makefile.gate rather than particular path

Applied to kbuild.git#kbuild.

Michal

Re: [uml-user] [PATCH 6/8] mtd: replace CONFIG_8xx by CONFIG_PPC_8xx

[Brian N. <com...@gm...>]

On Thu, Mar 12, 2015 at 04:24:04PM +0100, Christophe Leroy wrote:
> Two config options exist to define powerpc MPC8xx:
> * CONFIG_PPC_8xx
> * CONFIG_8xx
> In addition, CONFIG_PPC_8xx also defines CONFIG_CPM1 as
> communication co-processor
> 
> arch/powerpc/platforms/Kconfig.cputype has contained the following
> comment about CONFIG_8xx item for some years:
> "# this is temp to handle compat with arch=ppc"
> 
> It looks like not many places still have that old CONFIG_8xx used,
> so it is likely to be a good time to get rid of it completely ?
> 
> Signed-off-by: Christophe Leroy <chr...@c-...>

I'm not sure if the consistency aspect is worked out for all symbols
(Geert's comment on the cover letter), but this one looks fine.

Applied this patch to l2-mtd.git.

Brian

[uml-user] [PATCH 2/4] kbuild: use relative path more to include Makefile

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

Prior to this commit, it was impossible to use relative path to
include Makefiles from the top level Makefile because the option
"--include-dir=$(srctree)" becomes effective when Make enters into
sub Makefiles.

To use relative path in any places, this commit moves the option
above the "sub-make" target.

Signed-off-by: Masahiro Yamada <yam...@so...>
---

 Makefile             | 22 ++++++++++------------
 arch/mips/Makefile   |  2 +-
 arch/um/Makefile     |  6 +++---
 arch/x86/Makefile    |  2 +-
 arch/x86/Makefile.um |  2 +-
 5 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/Makefile b/Makefile
index cc68048..402ff77 100644
--- a/Makefile
+++ b/Makefile
@@ -10,9 +10,10 @@ NAME = Hurr durr I'ma sheep
 # Comments in this file are targeted only to the developer, do not
 # expect to learn how to build the kernel reading this file.
 
-# Do not use make's built-in rules and variables
-# (this increases performance and avoids hard-to-debug behaviour);
-MAKEFLAGS += -rR
+# o Do not use make's built-in rules and variables
+#   (this increases performance and avoids hard-to-debug behaviour);
+# o Look for make include files relative to root of kernel src
+MAKEFLAGS += -rR --include-dir=$(CURDIR)
 
 # Avoid funny character set dependencies
 unexport LC_ALL
@@ -344,12 +345,9 @@ endif
 export COMPILER
 endif
 
-# Look for make include files relative to root of kernel src
-MAKEFLAGS += --include-dir=$(srctree)
-
 # We need some generic definitions (do not try to remake the file).
-$(srctree)/scripts/Kbuild.include: ;
-include $(srctree)/scripts/Kbuild.include
+scripts/Kbuild.include: ;
+include scripts/Kbuild.include
 
 # Make variables (CC, etc...)
 AS		= $(CROSS_COMPILE)as
@@ -533,7 +531,7 @@ ifeq ($(config-targets),1)
 # Read arch specific Makefile to set KBUILD_DEFCONFIG as needed.
 # KBUILD_DEFCONFIG may point out an alternative default configuration
 # used for 'make defconfig'
-include $(srctree)/arch/$(SRCARCH)/Makefile
+include arch/$(SRCARCH)/Makefile
 export KBUILD_DEFCONFIG KBUILD_KCONFIG
 
 config: scripts_basic outputmakefile FORCE
@@ -609,7 +607,7 @@ endif # $(dot-config)
 # Defaults to vmlinux, but the arch makefile usually adds further targets
 all: vmlinux
 
-include $(srctree)/arch/$(SRCARCH)/Makefile
+include arch/$(SRCARCH)/Makefile
 
 KBUILD_CFLAGS	+= $(call cc-option,-fno-delete-null-pointer-checks,)
 
@@ -781,8 +779,8 @@ ifeq ($(shell $(CONFIG_SHELL) $(srctree)/scripts/gcc-goto.sh $(CC)), y)
 	KBUILD_CFLAGS += -DCC_HAVE_ASM_GOTO
 endif
 
-include $(srctree)/scripts/Makefile.kasan
-include $(srctree)/scripts/Makefile.extrawarn
+include scripts/Makefile.kasan
+include scripts/Makefile.extrawarn
 
 # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
 KBUILD_CPPFLAGS += $(KCPPFLAGS)
diff --git a/arch/mips/Makefile b/arch/mips/Makefile
index 8f57fc7..d152dfb 100644
--- a/arch/mips/Makefile
+++ b/arch/mips/Makefile
@@ -225,7 +225,7 @@ endif
 #
 # Board-dependent options and extra files
 #
-include $(srctree)/arch/mips/Kbuild.platforms
+include arch/mips/Kbuild.platforms
 
 ifdef CONFIG_PHYSICAL_START
 load-y					= $(CONFIG_PHYSICAL_START)
diff --git a/arch/um/Makefile b/arch/um/Makefile
index e4b1a96..17d4460 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -43,8 +43,8 @@ endif
 
 HOST_DIR := arch/$(HEADER_ARCH)
 
-include $(srctree)/$(ARCH_DIR)/Makefile-skas
-include $(srctree)/$(HOST_DIR)/Makefile.um
+include $(ARCH_DIR)/Makefile-skas
+include $(HOST_DIR)/Makefile.um
 
 core-y += $(HOST_DIR)/um/
 
@@ -73,7 +73,7 @@ USER_CFLAGS = $(patsubst $(KERNEL_DEFINES),,$(patsubst -D__KERNEL__,,\
 	$(filter -I%,$(CFLAGS)) -D_FILE_OFFSET_BITS=64 -idirafter include
 
 #This will adjust *FLAGS accordingly to the platform.
-include $(srctree)/$(ARCH_DIR)/Makefile-os-$(OS)
+include $(ARCH_DIR)/Makefile-os-$(OS)
 
 KBUILD_CPPFLAGS += -I$(srctree)/$(HOST_DIR)/include \
 		   -I$(srctree)/$(HOST_DIR)/include/uapi \
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5ba2d9c..2fda005 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -63,7 +63,7 @@ ifeq ($(CONFIG_X86_32),y)
 				$(call cc-option,-fno-unit-at-a-time))
 
         # CPU-specific tuning. Anything which can be shared with UML should go here.
-        include $(srctree)/arch/x86/Makefile_32.cpu
+        include arch/x86/Makefile_32.cpu
         KBUILD_CFLAGS += $(cflags-y)
 
         # temporary until string.h is fixed
diff --git a/arch/x86/Makefile.um b/arch/x86/Makefile.um
index 95eba55..5b7e898 100644
--- a/arch/x86/Makefile.um
+++ b/arch/x86/Makefile.um
@@ -18,7 +18,7 @@ LDS_EXTRA		:= -Ui386
 export LDS_EXTRA
 
 # First of all, tune CFLAGS for the specific CPU. This actually sets cflags-y.
-include $(srctree)/arch/x86/Makefile_32.cpu
+include arch/x86/Makefile_32.cpu
 
 # prevent gcc from keeping the stack 16 byte aligned. Taken from i386.
 cflags-y += $(call cc-option,-mpreferred-stack-boundary=2)
-- 
1.9.1

[uml-user] [PATCH 0/4] kbuild: refactor Makefile inclusion

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

Masahiro Yamada (4):
  kbuild: use relative path to include Makefile
  kbuild: use relative path more to include Makefile
  kbuild: include $(src)/Makefile rather than $(obj)/Makefile
  kbuild: ia64: use $(src)/Makefile.gate rather than particular path

 Makefile                  | 22 ++++++++++------------
 arch/arm/boot/Makefile    |  2 +-
 arch/ia64/kernel/Makefile |  2 +-
 arch/mips/Makefile        |  2 +-
 arch/um/Makefile          |  6 +++---
 arch/x86/Makefile         |  2 +-
 arch/x86/Makefile.um      |  2 +-
 scripts/Makefile.dtbinst  |  2 +-
 scripts/Makefile.fwinst   |  2 +-
 9 files changed, 20 insertions(+), 22 deletions(-)

-- 
1.9.1

Re: [uml-user] [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap

[Laurent D. <ld...@li...>]

On 26/03/2015 19:55, Ingo Molnar wrote:
> 
> * Laurent Dufour <ld...@li...> wrote:
> 
>> +{
>> +	unsigned long vdso_end, vdso_start;
>> +
>> +	if (!mm->context.vdso_base)
>> +		return;
>> +	vdso_start = mm->context.vdso_base;
>> +
>> +#ifdef CONFIG_PPC64
>> +	/* Calling is_32bit_task() implies that we are dealing with the
>> +	 * current process memory. If there is a call path where mm is not
>> +	 * owned by the current task, then we'll have need to store the
>> +	 * vDSO size in the mm->context.
>> +	 */
>> +	BUG_ON(current->mm != mm);
>> +	if (is_32bit_task())
>> +		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +	else
>> +		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
>> +#else
>> +	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +#endif
>> +	vdso_end += (1<<PAGE_SHIFT); /* data page */
>> +
>> +	/* Check if the vDSO is in the range of the remapped area */
>> +	if ((vdso_start <= old_start && old_start < vdso_end) ||
>> +	    (vdso_start < old_end && old_end <= vdso_end)  ||
>> +	    (old_start <= vdso_start && vdso_start < old_end)) {
>> +		/* Update vdso_base if the vDSO is entirely moved. */
>> +		if (old_start == vdso_start && old_end == vdso_end &&
>> +		    (old_end - old_start) == (new_end - new_start))
>> +			mm->context.vdso_base = new_start;
>> +		else
>> +			mm->context.vdso_base = 0;
>> +	}
>> +}
> 
> Oh my, that really looks awfully complex, as you predicted, and right 
> in every mremap() call.

I do agree, that's awfully complex ;)

> I'm fine with your original, imperfect, KISS approach. Sorry about 
> this detour ...
>
> Reviewed-by: Ingo Molnar <mi...@ke...>

No problem, so let's stay on the v3 version of the patch.
Thanks for Reviewed-by statement which, I guess, applied to the v3 too.
Should I resend the v3 ?

Thanks,
Laurent.

Re: [uml-user] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

[Benjamin H. <be...@ke...>]

On Thu, 2015-03-26 at 10:43 +0100, Ingo Molnar wrote:
> * Benjamin Herrenschmidt <be...@ke...> wrote:
> 
> > On Wed, 2015-03-25 at 19:36 +0100, Ingo Molnar wrote:
> > > * Ingo Molnar <mi...@ke...> wrote:
> > > 
> > > > > +#define __HAVE_ARCH_REMAP
> > > > > +static inline void arch_remap(struct mm_struct *mm,
> > > > > +			      unsigned long old_start, unsigned long old_end,
> > > > > +			      unsigned long new_start, unsigned long new_end)
> > > > > +{
> > > > > +	/*
> > > > > +	 * mremap() doesn't allow moving multiple vmas so we can limit the
> > > > > +	 * check to old_start == vdso_base.
> > > > > +	 */
> > > > > +	if (old_start == mm->context.vdso_base)
> > > > > +		mm->context.vdso_base = new_start;
> > > > > +}
> > > > 
> > > > mremap() doesn't allow moving multiple vmas, but it allows the 
> > > > movement of multi-page vmas and it also allows partial mremap()s, 
> > > > where it will split up a vma.
> > > 
> > > I.e. mremap() supports the shrinking (and growing) of vmas. In that 
> > > case mremap() will unmap the end of the vma and will shrink the 
> > > remaining vDSO vma.
> > > 
> > > Doesn't that result in a non-working vDSO that should zero out 
> > > vdso_base?
> > 
> > Right. Now we can't completely prevent the user from shooting itself 
> > in the foot I suppose, though there is a legit usage scenario which 
> > is to move the vDSO around which it would be nice to support. I 
> > think it's reasonable to put the onus on the user here to do the 
> > right thing.
> 
> I argue we should use the right condition to clear vdso_base: if the 
> vDSO gets at least partially unmapped. Otherwise there's little point 
> in the whole patch: either correctly track whether the vDSO is OK, or 
> don't ...

Well, if we are going to clear it at all yes, we should probably be a
bit smarter about it. My point however was we probably don't need to be
super robust about dealing with any crazy scenario userspace might
conceive.

> There's also the question of mprotect(): can users mprotect() the vDSO 
> on PowerPC?

Nothing prevents it. But here too, I wouldn't bother. The user might be
doing on purpose expecting to catch the resulting signal for example
(though arguably a signal from a sigreturn frame is ... odd).

Cheers,
Ben.

Re: [uml-user] [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap

[Ingo M. <mi...@ke...>]

* Laurent Dufour <ld...@li...> wrote:

> +{
> +	unsigned long vdso_end, vdso_start;
> +
> +	if (!mm->context.vdso_base)
> +		return;
> +	vdso_start = mm->context.vdso_base;
> +
> +#ifdef CONFIG_PPC64
> +	/* Calling is_32bit_task() implies that we are dealing with the
> +	 * current process memory. If there is a call path where mm is not
> +	 * owned by the current task, then we'll have need to store the
> +	 * vDSO size in the mm->context.
> +	 */
> +	BUG_ON(current->mm != mm);
> +	if (is_32bit_task())
> +		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +	else
> +		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
> +#else
> +	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
> +#endif
> +	vdso_end += (1<<PAGE_SHIFT); /* data page */
> +
> +	/* Check if the vDSO is in the range of the remapped area */
> +	if ((vdso_start <= old_start && old_start < vdso_end) ||
> +	    (vdso_start < old_end && old_end <= vdso_end)  ||
> +	    (old_start <= vdso_start && vdso_start < old_end)) {
> +		/* Update vdso_base if the vDSO is entirely moved. */
> +		if (old_start == vdso_start && old_end == vdso_end &&
> +		    (old_end - old_start) == (new_end - new_start))
> +			mm->context.vdso_base = new_start;
> +		else
> +			mm->context.vdso_base = 0;
> +	}
> +}

Oh my, that really looks awfully complex, as you predicted, and right 
in every mremap() call.

I'm fine with your original, imperfect, KISS approach. Sorry about 
this detour ...

Reviewed-by: Ingo Molnar <mi...@ke...>

Thanks,

	Ingo

[uml-user] [PATCH v4 2/2] powerpc/mm: Tracking vDSO remap

[Laurent D. <ld...@li...>]

Some processes (CRIU) are moving the vDSO area using the mremap system
call. As a consequence the kernel reference to the vDSO base address is
no more valid and the signal return frame built once the vDSO has been
moved is not pointing to the new sigreturn address.

This patch handles vDSO remapping and unmapping.
Moving or unmapping partially the vDSO lead to invalidate it from the
kernel point of view.

Signed-off-by: Laurent Dufour <ld...@li...>
---
 arch/powerpc/include/asm/mmu_context.h | 32 +++++++++++++++++++++++++++-
 arch/powerpc/kernel/vdso.c             | 39 ++++++++++++++++++++++++++++++++++
 2 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h
index 73382eba02dc..67734ce8be67 100644
--- a/arch/powerpc/include/asm/mmu_context.h
+++ b/arch/powerpc/include/asm/mmu_context.h
@@ -8,7 +8,6 @@
 #include <linux/spinlock.h>
 #include <asm/mmu.h>	
 #include <asm/cputable.h>
-#include <asm-generic/mm_hooks.h>
 #include <asm/cputhreads.h>
 
 /*
@@ -109,5 +108,36 @@ static inline void enter_lazy_tlb(struct mm_struct *mm,
 #endif
 }
 
+static inline void arch_dup_mmap(struct mm_struct *oldmm,
+				 struct mm_struct *mm)
+{
+}
+
+static inline void arch_exit_mmap(struct mm_struct *mm)
+{
+}
+
+extern void arch_vdso_remap(struct mm_struct *mm,
+			    unsigned long old_start, unsigned long old_end,
+			    unsigned long new_start, unsigned long new_end);
+static inline void arch_unmap(struct mm_struct *mm, struct vm_area_struct *vma,
+			      unsigned long start, unsigned long end)
+{
+	arch_vdso_remap(mm, start, end, 0, 0);
+}
+
+static inline void arch_bprm_mm_init(struct mm_struct *mm,
+				     struct vm_area_struct *vma)
+{
+}
+
+#define __HAVE_ARCH_REMAP
+static inline void arch_remap(struct mm_struct *mm,
+			      unsigned long old_start, unsigned long old_end,
+			      unsigned long new_start, unsigned long new_end)
+{
+	arch_vdso_remap(mm, old_start, old_end, new_start, new_end);
+}
+
 #endif /* __KERNEL__ */
 #endif /* __ASM_POWERPC_MMU_CONTEXT_H */
diff --git a/arch/powerpc/kernel/vdso.c b/arch/powerpc/kernel/vdso.c
index 305eb0d9b768..a11b5d8f36d6 100644
--- a/arch/powerpc/kernel/vdso.c
+++ b/arch/powerpc/kernel/vdso.c
@@ -283,6 +283,45 @@ int arch_setup_additional_pages(struct linux_binprm *bprm, int uses_interp)
 	return rc;
 }
 
+void arch_vdso_remap(struct mm_struct *mm,
+		     unsigned long old_start, unsigned long old_end,
+		     unsigned long new_start, unsigned long new_end)
+{
+	unsigned long vdso_end, vdso_start;
+
+	if (!mm->context.vdso_base)
+		return;
+	vdso_start = mm->context.vdso_base;
+
+#ifdef CONFIG_PPC64
+	/* Calling is_32bit_task() implies that we are dealing with the
+	 * current process memory. If there is a call path where mm is not
+	 * owned by the current task, then we'll have need to store the
+	 * vDSO size in the mm->context.
+	 */
+	BUG_ON(current->mm != mm);
+	if (is_32bit_task())
+		vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+	else
+		vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
+#else
+	vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
+#endif
+	vdso_end += (1<<PAGE_SHIFT); /* data page */
+
+	/* Check if the vDSO is in the range of the remapped area */
+	if ((vdso_start <= old_start && old_start < vdso_end) ||
+	    (vdso_start < old_end && old_end <= vdso_end)  ||
+	    (old_start <= vdso_start && vdso_start < old_end)) {
+		/* Update vdso_base if the vDSO is entirely moved. */
+		if (old_start == vdso_start && old_end == vdso_end &&
+		    (old_end - old_start) == (new_end - new_start))
+			mm->context.vdso_base = new_start;
+		else
+			mm->context.vdso_base = 0;
+	}
+}
+
 const char *arch_vma_name(struct vm_area_struct *vma)
 {
 	if (vma->vm_mm && vma->vm_start == vma->vm_mm->context.vdso_base)
-- 
1.9.1

[uml-user] [PATCH v4 0/2] Tracking user space vDSO remaping

[Laurent D. <ld...@li...>]

CRIU is recreating the process memory layout by remapping the checkpointee
memory area on top of the current process (criu). This includes remapping
the vDSO to the place it has at checkpoint time.

However some architectures like powerpc are keeping a reference to the vDSO
base address to build the signal return stack frame by calling the vDSO
sigreturn service. So once the vDSO has been moved, this reference is no
more valid and the signal frame built later are not usable.

This patch serie is introducing a new mm hook 'arch_remap' which is called
when mremap is done and the mm lock still hold. The next patch is adding the
vDSO remap and unmap tracking to the powerpc architecture.

Changes in v4:
--------------
- Reviewing the PowerPC part of the patch to handle partial unmap and remap
  of the vDSO.

Changes in v3:
--------------
- Fixed grammatical error in a comment of the second patch. 
  Thanks again, Ingo.

Changes in v2:
--------------
- Following the Ingo Molnar's advice, enabling the call to arch_remap through
  the __HAVE_ARCH_REMAP macro. This reduces considerably the first patch.

Laurent Dufour (2):
  mm: Introducing arch_remap hook
  powerpc/mm: Tracking vDSO remap

 arch/powerpc/include/asm/mmu_context.h | 32 +++++++++++++++++++++++++++-
 arch/powerpc/kernel/vdso.c             | 39 ++++++++++++++++++++++++++++++++++
 mm/mremap.c                            | 11 ++++++++--
 3 files changed, 79 insertions(+), 3 deletions(-)

-- 
1.9.1

[uml-user] [PATCH v4 1/2] mm: Introducing arch_remap hook

[Laurent D. <ld...@li...>]

Some architecture would like to be triggered when a memory area is moved
through the mremap system call.

This patch is introducing a new arch_remap mm hook which is placed in the
path of mremap, and is called before the old area is unmapped (and the
arch_unmap hook is called).

The architectures which need to call this hook should define
__HAVE_ARCH_REMAP in their asm/mmu_context.h and provide the arch_remap
service with the following prototype:
void arch_remap(struct mm_struct *mm,
                unsigned long old_start, unsigned long old_end,
                unsigned long new_start, unsigned long new_end);

Signed-off-by: Laurent Dufour <ld...@li...>
---
 mm/mremap.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/mm/mremap.c b/mm/mremap.c
index 57dadc025c64..bafc234db45c 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -25,6 +25,7 @@
 
 #include <asm/cacheflush.h>
 #include <asm/tlbflush.h>
+#include <asm/mmu_context.h>
 
 #include "internal.h"
 
@@ -286,8 +287,14 @@ static unsigned long move_vma(struct vm_area_struct *vma,
 		old_len = new_len;
 		old_addr = new_addr;
 		new_addr = -ENOMEM;
-	} else if (vma->vm_file && vma->vm_file->f_op->mremap)
-		vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+	} else {
+		if (vma->vm_file && vma->vm_file->f_op->mremap)
+			vma->vm_file->f_op->mremap(vma->vm_file, new_vma);
+#ifdef __HAVE_ARCH_REMAP
+		arch_remap(mm, old_addr, old_addr+old_len,
+			   new_addr, new_addr+new_len);
+#endif
+	}
 
 	/* Conceal VM_ACCOUNT so old reservation is not undone */
 	if (vm_flags & VM_ACCOUNT) {
-- 
1.9.1

Re: [uml-user] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

[Laurent D. <ld...@li...>]

On 26/03/2015 15:17, Ingo Molnar wrote:
> 
> * Laurent Dufour <ld...@li...> wrote:
> 
>>> I argue we should use the right condition to clear vdso_base: if 
>>> the vDSO gets at least partially unmapped. Otherwise there's 
>>> little point in the whole patch: either correctly track whether 
>>> the vDSO is OK, or don't ...
>>
>> That's a good option, but it may be hard to achieve in the case the 
>> vDSO area has been splitted in multiple pieces.
>>
>> Not sure there is a right way to handle that, here this is a best 
>> effort, allowing a process to unmap its vDSO and having the 
>> sigreturn call done through the stack area (it has to make it 
>> executable).
>>
>> Anyway I'll dig into that, assuming that the vdso_base pointer 
>> should be clear if a part of the vDSO is moved or unmapped. The 
>> patch will be larger since I'll have to get the vDSO size which is 
>> private to the vdso.c file.
> 
> At least for munmap() I don't think that's a worry: once unmapped 
> (even if just partially), vdso_base becomes zero and won't ever be set 
> again.
> 
> So no need to track the zillion pieces, should there be any: Humpty 
> Dumpty won't be whole again, right?

My idea is to clear vdso_base if at least part of the vdso is unmap.
But since some part of the vdso may have been moved and unmapped later,
to be complete, the patch has to handle partial mremap() of the vDSO
too. Otherwise such a scenario will not be detected:

	new_area = mremap(vdso_base + page_size, ....);
	munmap(new_area,...);

>>> There's also the question of mprotect(): can users mprotect() the 
>>> vDSO on PowerPC?
>>
>> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
>> certainly all the other architectures. Furthermore, if it is done on 
>> a partial part of the vDSO it is splitting the vma...
> 
> btw., CRIU's main purpose here is to reconstruct a vDSO that was 
> originally randomized, but whose address must now be reproduced as-is, 
> right?

You're right, CRIU has to move the vDSO to the same address it has at
checkpoint time.

> In that sense detecting the 'good' mremap() as your patch does should 
> do the trick and is certainly not objectionable IMHO - I was just 
> wondering whether we could make a perfect job very simply.

I'd try to address the perfect job, this may complexify the patch,
especially because the vdso's size is not recorded in the PowerPC
mm_context structure. Not sure it is a good idea to extend that structure..

Thanks,
Laurent.

Re: [uml-user] [PATCH v3 2/2] powerpc/mm: Tracking vDSO remap

[Ingo M. <mi...@ke...>]

* Laurent Dufour <ld...@li...> wrote:

> > I argue we should use the right condition to clear vdso_base: if 
> > the vDSO gets at least partially unmapped. Otherwise there's 
> > little point in the whole patch: either correctly track whether 
> > the vDSO is OK, or don't ...
> 
> That's a good option, but it may be hard to achieve in the case the 
> vDSO area has been splitted in multiple pieces.
>
> Not sure there is a right way to handle that, here this is a best 
> effort, allowing a process to unmap its vDSO and having the 
> sigreturn call done through the stack area (it has to make it 
> executable).
> 
> Anyway I'll dig into that, assuming that the vdso_base pointer 
> should be clear if a part of the vDSO is moved or unmapped. The 
> patch will be larger since I'll have to get the vDSO size which is 
> private to the vdso.c file.

At least for munmap() I don't think that's a worry: once unmapped 
(even if just partially), vdso_base becomes zero and won't ever be set 
again.

So no need to track the zillion pieces, should there be any: Humpty 
Dumpty won't be whole again, right?

> > There's also the question of mprotect(): can users mprotect() the 
> > vDSO on PowerPC?
> 
> Yes, mprotect() the vDSO is allowed on PowerPC, as it is on x86, and 
> certainly all the other architectures. Furthermore, if it is done on 
> a partial part of the vDSO it is splitting the vma...

btw., CRIU's main purpose here is to reconstruct a vDSO that was 
originally randomized, but whose address must now be reproduced as-is, 
right?

In that sense detecting the 'good' mremap() as your patch does should 
do the trick and is certainly not objectionable IMHO - I was just 
wondering whether we could make a perfect job very simply.

Thanks,

	Ingo