user-mode-linux-devel

Re: [uml-devel] [PATCH] um: Fix PTRACE_POKEUSER on x86_64

[Geert U. <ge...@li...>]

Hi Richard,

On Sat, Apr 1, 2017 at 12:41 AM, Richard Weinberger <ri...@no...> wrote:
> This is broken since ever but sadly nobody noticed.
> Recent versions of GDB set DR_CONTROL unconditionally and
> UML dies due to a heap corruption. It turns out that
> the PTRACE_POKEUSER was copy&pasted from i386 and assumes
> that addresses are 4 bytes long.
>
> Fix that by using 8 as address size in the calculation.
>
> Cc: <st...@vg...>
> Reported-by: jie cao <cj...@gm...>
> Signed-off-by: Richard Weinberger <ri...@no...>
> ---
>  arch/x86/um/ptrace_64.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/um/ptrace_64.c b/arch/x86/um/ptrace_64.c
> index a5c9910d234f..09a085bde0d4 100644
> --- a/arch/x86/um/ptrace_64.c
> +++ b/arch/x86/um/ptrace_64.c
> @@ -125,7 +125,7 @@ int poke_user(struct task_struct *child, long addr, long data)
>         else if ((addr >= offsetof(struct user, u_debugreg[0])) &&
>                 (addr <= offsetof(struct user, u_debugreg[7]))) {
>                 addr -= offsetof(struct user, u_debugreg[0]);
> -               addr = addr >> 2;
> +               addr = addr >> 3;

While at it:

        addr >>= 3;

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[uml-devel] [PATCH] um: Fix PTRACE_POKEUSER on x86_64

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

This is broken since ever but sadly nobody noticed.
Recent versions of GDB set DR_CONTROL unconditionally and
UML dies due to a heap corruption. It turns out that
the PTRACE_POKEUSER was copy&pasted from i386 and assumes
that addresses are 4 bytes long.

Fix that by using 8 as address size in the calculation.

Cc: <st...@vg...>
Reported-by: jie cao <cj...@gm...>
Signed-off-by: Richard Weinberger <ri...@no...>
---
 arch/x86/um/ptrace_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/um/ptrace_64.c b/arch/x86/um/ptrace_64.c
index a5c9910d234f..09a085bde0d4 100644
--- a/arch/x86/um/ptrace_64.c
+++ b/arch/x86/um/ptrace_64.c
@@ -125,7 +125,7 @@ int poke_user(struct task_struct *child, long addr, long data)
 	else if ((addr >= offsetof(struct user, u_debugreg[0])) &&
 		(addr <= offsetof(struct user, u_debugreg[7]))) {
 		addr -= offsetof(struct user, u_debugreg[0]);
-		addr = addr >> 2;
+		addr = addr >> 3;
 		if ((addr == 4) || (addr == 5))
 			return -EIO;
 		child->thread.arch.debugregs[addr] = data;
-- 
2.10.2

Re: [uml-devel] UML regression with latest RC 4.11-rc2

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

Anton,

Am 17.03.2017 um 18:44 schrieb Anton Ivanov:
>> But you have to enable VM debugging to see it.
> 
> I have most debugging enabled to make sure I do not introduce any
> re-entrancy in the IRQ handlers and/or have any allocations of the wrong
> type where they do not belong.
> 
> We should probably submit a short patch #ifdef to turn this WARN() off
> for UML

Not before we understand the root cause. :)

Thanks,
//richard

Re: [uml-devel] UML regression with latest RC 4.11-rc2

[Anton I. <ant...@ko...>]

On 17/03/17 17:33, Richard Weinberger wrote:
> Am 17.03.2017 um 18:04 schrieb Anton Ivanov:
>> On 17/03/17 16:56, Richard Weinberger wrote:
>>> Anton,
>>>
>>> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
>>> <ant...@ko...> wrote:
>>>> Hi list, hi Richard
>>>>
>>>> There is an extra check in mm/mmap.c which now throws a WARN on every
>>>> page in making UML unusable with the latest 4.11-rc2
>>> Which WARN? Can you find the offending commit?
>> mm/mmap.c line 1112
> Okay, this triggers since:
>
> commit e86f15ee64d8ee46255d964d55f74f5ba9af8c36
> Author: Andrea Arcangeli <aar...@re...>
> Date:   Fri Oct 7 17:01:28 2016 -0700
>
>     mm: vma_merge: fix vm_page_prot SMP race condition against rmap_walk
>
> But you have to enable VM debugging to see it.

I have most debugging enabled to make sure I do not introduce any
re-entrancy in the IRQ handlers and/or have any allocations of the wrong
type where they do not belong.

We should probably submit a short patch #ifdef to turn this WARN() off
for UML

Brgds,

A.

>
> Thanks,
> //richard
>

Re: [uml-devel] UML regression with latest RC 4.11-rc2

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

Am 17.03.2017 um 18:04 schrieb Anton Ivanov:
> On 17/03/17 16:56, Richard Weinberger wrote:
>> Anton,
>>
>> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
>> <ant...@ko...> wrote:
>>> Hi list, hi Richard
>>>
>>> There is an extra check in mm/mmap.c which now throws a WARN on every
>>> page in making UML unusable with the latest 4.11-rc2
>> Which WARN? Can you find the offending commit?
> 
> mm/mmap.c line 1112

Okay, this triggers since:

commit e86f15ee64d8ee46255d964d55f74f5ba9af8c36
Author: Andrea Arcangeli <aar...@re...>
Date:   Fri Oct 7 17:01:28 2016 -0700

    mm: vma_merge: fix vm_page_prot SMP race condition against rmap_walk

But you have to enable VM debugging to see it.

Thanks,
//richard

Re: [uml-devel] UML regression with latest RC 4.11-rc2

[Anton I. <ant...@ko...>]

On 17/03/17 17:04, Anton Ivanov wrote:
> On 17/03/17 16:56, Richard Weinberger wrote:
>> Anton,
>>
>> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
>> <ant...@ko...> wrote:
>>> Hi list, hi Richard
>>>
>>> There is an extra check in mm/mmap.c which now throws a WARN on every
>>> page in making UML unusable with the latest 4.11-rc2
>> Which WARN? Can you find the offending commit?
> mm/mmap.c line 1112
>
> I spent the day polishing the epoll patch so have not had the time to
> look at this.
>
> It works fine with the 3 warns there commented out.

It looks like the culprit is an SMP mmap race fix 
e86f15ee64d8ee46255d964d55f74f5ba9af8c36

A.

>
> A.
>
>
> ------------------------------------------------------------------------------
> 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-devel mailing list
> Use...@li...
> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>

Re: [uml-devel] UML regression with latest RC 4.11-rc2

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

Anton,

Am 17.03.2017 um 18:04 schrieb Anton Ivanov:
> On 17/03/17 16:56, Richard Weinberger wrote:
>> Anton,
>>
>> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
>> <ant...@ko...> wrote:
>>> Hi list, hi Richard
>>>
>>> There is an extra check in mm/mmap.c which now throws a WARN on every
>>> page in making UML unusable with the latest 4.11-rc2
>> Which WARN? Can you find the offending commit?
> 
> mm/mmap.c line 1112
> 
> I spent the day polishing the epoll patch so have not had the time to look at this.
> 
> It works fine with the 3 warns there commented out.

Hm, it does not trigger here. Can you share your .config?

Thanks,
//richard

Re: [uml-devel] UML regression with latest RC 4.11-rc2

[Anton I. <ant...@ko...>]

On 17/03/17 16:56, Richard Weinberger wrote:
> Anton,
>
> On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
> <ant...@ko...> wrote:
>> Hi list, hi Richard
>>
>> There is an extra check in mm/mmap.c which now throws a WARN on every
>> page in making UML unusable with the latest 4.11-rc2
> Which WARN? Can you find the offending commit?

mm/mmap.c line 1112

I spent the day polishing the epoll patch so have not had the time to 
look at this.

It works fine with the 3 warns there commented out.

A.

>

Re: [uml-devel] FPU patches broke UML on i7-7700 CPU

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

Natale,

On Wed, Feb 15, 2017 at 3:31 PM, Natale Patriciello
<nat...@gm...> wrote:
>
> Hello,
>
> as I've reported here [1], by changing the work station I've got the
> same UML guest not working anymore. I investigated and the problem root
> is in the code added in this patchset [2] (add extended processor state
> save/restore support). In particular, the ptrace returns < 0 and the
> errno is set to 14. Reverting the code to use the functions
> *_i387_registers () makes everything to work correctly.
>
> There is something I can do for further debugging the issue? Or should I
> live with a modified kernel tree with a reverse patch applied ?

When reporting such bugs, please always CC all affected parties.
Especially the author of the offending patch.

-- 
Thanks,
//richard

Re: [uml-devel] UML regression with latest RC 4.11-rc2

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

Anton,

On Fri, Mar 17, 2017 at 8:51 AM, Anton Ivanov
<ant...@ko...> wrote:
> Hi list, hi Richard
>
> There is an extra check in mm/mmap.c which now throws a WARN on every
> page in making UML unusable with the latest 4.11-rc2

Which WARN? Can you find the offending commit?

-- 
Thanks,
//richard

[uml-devel] Interrupt controller

[Anton I. <ant...@ko...>]

Hi Richard, hi list,

I finally figured out what was going wrong with my Epoll IRQ controller POC.

I have a working one now. I will submit it after I have done some more 
extensive tests on it.

So far it is showing 10-20% improvements in IO in default config (one 
Ethernet, one UBD). This should be significantly better with a lot of 
devices as it scales much better than the poll based one.

A.

[uml-devel] UML regression with latest RC 4.11-rc2

[Anton I. <ant...@ko...>]

Hi list, hi Richard

There is an extra check in mm/mmap.c which now throws a WARN on every 
page in making UML unusable with the latest 4.11-rc2

A.

[uml-devel] [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.

Fixes: 4bcc595ccd80decb ("printk: reinstate KERN_CONT for printing
continuation lines")
Cc: st...@vg...
Cc: Vegard Nossum <veg...@or...>
Tested-by: Vegard Nossum <veg...@or...>
Reported-by: Vegard Nossum <veg...@or...>
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 a76295f7ede9..961be4a51511 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -20,10 +20,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%pB\n", address, reliable ? "" : "? ",
+		(void *)address);
 }
 
 static const struct stacktrace_ops stackops = {
-- 
2.10.2

Re: [uml-devel] [PATCH] um: use KERN_CONT in stack dump

[Vegard N. <veg...@or...>]

On 12/03/2017 10:45, Richard Weinberger wrote:
> Am 12.03.2017 um 10:38 schrieb Vegard Nossum:
>> Without KERN_CONT, the symbol will appear on a new line, making stack
>> traces completely unreadable:
[snip]
> I think it is better to fix the root of the problem by using a single printk.
> i.e.
>
> 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%pB\n", address, reliable ? "" : "? ",
> +               (void *)address);
>  }

Your patch is better.

Tested-by: Vegard Nossum <veg...@or...>

Thanks,


Vegard

Re: [uml-devel] [PATCH] um: use KERN_CONT in stack dump

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

Vegard,

Am 12.03.2017 um 10:38 schrieb Vegard Nossum:
> Without KERN_CONT, the symbol will appear on a new line, making stack
> traces completely unreadable:
> 
>     Call Trace:
>      [<6008e891>] ?
>     printk+0x0/0x94
>      [<6001cce6>]
>     show_stack+0xfe/0x15b
>      [<600666ec>] ?
>     dump_stack_print_info+0xe1/0xea
>      [<6008e891>] ?
>     printk+0x0/0x94
>      [<6023e826>] ?
>     bust_spinlocks+0x0/0x4f
>      [<602343b8>]
>     dump_stack+0x2a/0x2c
>      [<6008e662>]
>     panic+0x170/0x31e
>      [<6008e4f2>] ?
>     panic+0x0/0x31e
> 
> This makes it readable again:
> 
>     Call Trace:
>      [<6008e891>] ? printk+0x0/0x94
>      [<6001cce6>] show_stack+0xfe/0x15b
>      [<600666ec>] ? dump_stack_print_info+0xe1/0xea
>      [<6008e891>] ? printk+0x0/0x94
>      [<6023e826>] ? bust_spinlocks+0x0/0x4f
>      [<602343b8>] dump_stack+0x2a/0x2c
>      [<6008e662>] panic+0x170/0x31e
> 
> Signed-off-by: Vegard Nossum <veg...@or...>
> ---
>  arch/um/kernel/sysrq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
> index a76295f7ede9..edf1f80123e7 100644
> --- a/arch/um/kernel/sysrq.c
> +++ b/arch/um/kernel/sysrq.c
> @@ -22,7 +22,7 @@ static void _print_addr(void *data, unsigned long address, int reliable)
>  {
>  	pr_info(" [<%08lx>]", address);
>  	pr_cont(" %s", reliable ? "" : "? ");
> -	print_symbol("%s", address);
> +	print_symbol(KERN_CONT "%s", address);
>  	pr_cont("\n");
>  }
> 

I think it is better to fix the root of the problem by using a single printk.
i.e.

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%pB\n", address, reliable ? "" : "? ",
+               (void *)address);
 }

Thanks,
//richard

[uml-devel] [PATCH] um: use KERN_CONT in stack dump

[Vegard N. <veg...@or...>]

Without KERN_CONT, the symbol will appear on a new line, making stack
traces completely unreadable:

    Call Trace:
     [<6008e891>] ?
    printk+0x0/0x94
     [<6001cce6>]
    show_stack+0xfe/0x15b
     [<600666ec>] ?
    dump_stack_print_info+0xe1/0xea
     [<6008e891>] ?
    printk+0x0/0x94
     [<6023e826>] ?
    bust_spinlocks+0x0/0x4f
     [<602343b8>]
    dump_stack+0x2a/0x2c
     [<6008e662>]
    panic+0x170/0x31e
     [<6008e4f2>] ?
    panic+0x0/0x31e

This makes it readable again:

    Call Trace:
     [<6008e891>] ? printk+0x0/0x94
     [<6001cce6>] show_stack+0xfe/0x15b
     [<600666ec>] ? dump_stack_print_info+0xe1/0xea
     [<6008e891>] ? printk+0x0/0x94
     [<6023e826>] ? bust_spinlocks+0x0/0x4f
     [<602343b8>] dump_stack+0x2a/0x2c
     [<6008e662>] panic+0x170/0x31e

Signed-off-by: Vegard Nossum <veg...@or...>
---
 arch/um/kernel/sysrq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/um/kernel/sysrq.c b/arch/um/kernel/sysrq.c
index a76295f7ede9..edf1f80123e7 100644
--- a/arch/um/kernel/sysrq.c
+++ b/arch/um/kernel/sysrq.c
@@ -22,7 +22,7 @@ static void _print_addr(void *data, unsigned long address, int reliable)
 {
 	pr_info(" [<%08lx>]", address);
 	pr_cont(" %s", reliable ? "" : "? ");
-	print_symbol("%s", address);
+	print_symbol(KERN_CONT "%s", address);
 	pr_cont("\n");
 }
 
-- 
2.12.0.rc0

Re: [uml-devel] [PATCH v2] um: Set number of CPUs

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

Nikola,

Am 02.03.2017 um 14:16 schrieb Nikola Kotur:
> Define NR_CPUS required by the timer subsystem.
> 
> Fixes this make warning:
> 
>     scripts/kconfig/conf  --oldconfig arch/x86/um/Kconfig
>     kernel/time/Kconfig:155:warning: range is invalid
> 
> Signed-off-by: Nikola Kotur <ko...@gm...>

Looks good!

Thanks,
//richard

[uml-devel] FPU patches broke UML on i7-7700 CPU

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

Hello,

as I've reported here [1], by changing the work station I've got the
same UML guest not working anymore. I investigated and the problem root
is in the code added in this patchset [2] (add extended processor state
save/restore support). In particular, the ptrace returns < 0 and the
errno is set to 14. Reverting the code to use the functions
*_i387_registers () makes everything to work correctly.

There is something I can do for further debugging the issue? Or should I
live with a modified kernel tree with a reverse patch applied ?

Thank you


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

Re: [uml-devel] [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

Re: [uml-devel] uml does not work with initrd=file

[<sg...@ao...>]

On Sun, 15 Jan 2017, Thomas Meyer wrote:

> Am 15. Januar 2017 13:16:22 MEZ schrieb sg...@ao...:
>> Hi,
>>
>> there seems to be a problem with usermode linux when started
>> with an initial ramdisk (argument initrd=file). Here is what
>> happens:
>>
>> ------------------------------------
>>
>> Locating the bottom of the address space ... 0x1000
>> Locating the top of the address space ... Checking that ptrace can
>> change system call numbers...0xc0000000
>> Core dump limits :
>> 	soft - 0
>> 	hard - NONE
>> 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
>> Adding 8470528 bytes to physical memory to account for exec-shield gap
>> kmsg_dump:
>> <1>bootmem alloc of 140 bytes failed!
>> <0>Kernel panic - not syncing: Out of memory
>> <4>CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-um #3
>> <6>Stack:
>> <4> 081eb922 081eb922 0822d547 00000000 08222000 00000000 0817fe48
>> 00000000
>> <4> 0822bf6c 080bd1a7 00000007 0829c600 081f113d 0822bfbc 082220fc
>> 00000000
>> <4> 00000000 00000000 0805393d 081f113d 0000008c 0804c88e 0000008c
>> 00000080
>> <6>Call Trace:
>> <6> [<0805cffb>] ?
>> <4>show_stack+0x9d/0x157
>> <6> [<0817fe48>] ?
>> <4>dump_stack+0x23/0x2b
>> <6> [<080bd1a7>] ?
>> <4>panic+0x9e/0x1b4
>> <6> [<0805393d>] ?
>> <4>__alloc_bootmem+0x3f/0x43
>> <6> [<0804c88e>] ?
>> <4>read_initrd+0x6a/0x101
>> <6> [<08096fa5>] ?
>> <4>kmsg_dump_register+0x37/0x65
>> <6> [<0805e8a9>] ?
>> <4>uml_finishsetup+0x27/0x3b
>> <6>
>>
>> ---------------------------------
>>
>>
>> Function read_initrd() calls alloc_bootmem(), but at this point
>> memory hasn't been initialized yet.
>>
>> A quick solution is to move uml_postsetup() (the function
>> that calls read_initrd()) right after the memory has been
>> initialized. This may be wrong since uml_postsetup() may call
>> other functions besides read_initrd(), but worked for me:
>> the initial ramdisk is loaded and init run.
>>
>>
>> --- linux-4.9.0/arch/um/kernel/um_arch.c	2016-12-11 20:17:54.000000000
>> +0100
>> +++ linux-4.9.0-um/arch/um/kernel/um_arch.c	2017-01-15
>> 11:16:32.000000000 +0100
>> @@ -231,7 +231,7 @@
>>  	atomic_notifier_chain_register(&panic_notifier_list,
>>  				       &panic_exit_notifier);
>>
>> -	uml_postsetup();
>> +	// uml_postsetup();
>>
>>  	new_thread_handler();
>>  }
>> @@ -340,6 +340,7 @@
>>  {
>>  	stack_protections((unsigned long) &init_thread_info);
>>  	setup_physmem(uml_physmem, uml_reserved, physmem_size, highmem);
>> +	uml_postsetup();
>>  	mem_total_pages(physmem_size, iomem_size, highmem);
>>
>>  	paging_init();
>>
>> ------------------------------------------------------------------------------
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> _______________________________________________
>> User-mode-linux-devel mailing list
>> Use...@li...
>> https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
>
> Hi,
>
> I don't think this is correct. How much memory do you assign your uml instance?
>

I tried:

vmlinux initrd=initrd.gz
vmlinux initrd=initrd.gz mem=10M
vmlinux initrd=initrd.gz mem=100M

the result is the same. ulimit -m gives "unlimited". With the same 
settings, uml had no problem booting from a romfs filesystem without
initrd.

> Your initial ramdisk is probably bigger than your assigned memory size?
>

I suspected something like this, so I tried with smaller and smaller
ramdisks.

The log above is for an initrd.gz of 140 bytes (just a text
file with 10 letters in it, cpio'd and compressed). Of course the
kernel would not find /init in it, but it never arrives at that
point. I enclose initrd.gz, and also .config, just in case it
could be useful.

> With kind regards
> Thomas
>

Re: [uml-devel] uml does not work with initrd=file

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

Am 15. Januar 2017 13:16:22 MEZ schrieb sg...@ao...:
>Hi,
>
>there seems to be a problem with usermode linux when started
>with an initial ramdisk (argument initrd=file). Here is what
>happens:
>
>------------------------------------
>
>Locating the bottom of the address space ... 0x1000
>Locating the top of the address space ... Checking that ptrace can
>change system call numbers...0xc0000000
>Core dump limits :
> 	soft - 0
> 	hard - NONE
>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
>Adding 8470528 bytes to physical memory to account for exec-shield gap
>kmsg_dump:
><1>bootmem alloc of 140 bytes failed!
><0>Kernel panic - not syncing: Out of memory
><4>CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-um #3
><6>Stack:
><4> 081eb922 081eb922 0822d547 00000000 08222000 00000000 0817fe48
>00000000
><4> 0822bf6c 080bd1a7 00000007 0829c600 081f113d 0822bfbc 082220fc
>00000000
><4> 00000000 00000000 0805393d 081f113d 0000008c 0804c88e 0000008c
>00000080
><6>Call Trace:
><6> [<0805cffb>] ? 
><4>show_stack+0x9d/0x157
><6> [<0817fe48>] ? 
><4>dump_stack+0x23/0x2b
><6> [<080bd1a7>] ? 
><4>panic+0x9e/0x1b4
><6> [<0805393d>] ? 
><4>__alloc_bootmem+0x3f/0x43
><6> [<0804c88e>] ? 
><4>read_initrd+0x6a/0x101
><6> [<08096fa5>] ? 
><4>kmsg_dump_register+0x37/0x65
><6> [<0805e8a9>] ? 
><4>uml_finishsetup+0x27/0x3b
><6>
>
>---------------------------------
>
>
>Function read_initrd() calls alloc_bootmem(), but at this point 
>memory hasn't been initialized yet.
>
>A quick solution is to move uml_postsetup() (the function
>that calls read_initrd()) right after the memory has been
>initialized. This may be wrong since uml_postsetup() may call
>other functions besides read_initrd(), but worked for me:
>the initial ramdisk is loaded and init run.
>
>
>--- linux-4.9.0/arch/um/kernel/um_arch.c	2016-12-11 20:17:54.000000000
>+0100
>+++ linux-4.9.0-um/arch/um/kernel/um_arch.c	2017-01-15
>11:16:32.000000000 +0100
>@@ -231,7 +231,7 @@
>  	atomic_notifier_chain_register(&panic_notifier_list,
>  				       &panic_exit_notifier);
>
>-	uml_postsetup();
>+	// uml_postsetup();
>
>  	new_thread_handler();
>  }
>@@ -340,6 +340,7 @@
>  {
>  	stack_protections((unsigned long) &init_thread_info);
>  	setup_physmem(uml_physmem, uml_reserved, physmem_size, highmem);
>+	uml_postsetup();
>  	mem_total_pages(physmem_size, iomem_size, highmem);
>
>  	paging_init();
>
>------------------------------------------------------------------------------
>Developer Access Program for Intel Xeon Phi Processors
>Access to Intel Xeon Phi processor-based developer platforms.
>With one year of Intel Parallel Studio XE.
>Training and support from Colfax.
>Order your platform today. http://sdm.link/xeonphi
>_______________________________________________
>User-mode-linux-devel mailing list
>Use...@li...
>https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Hi,

I don't think this is correct. How much memory do you assign your uml instance?

Your initial ramdisk is probably bigger than your assigned memory size?

With kind regards
Thomas

[uml-devel] uml does not work with initrd=file

[<sg...@ao...>]

Hi,

there seems to be a problem with usermode linux when started
with an initial ramdisk (argument initrd=file). Here is what
happens:

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

Locating the bottom of the address space ... 0x1000
Locating the top of the address space ... Checking that ptrace can change system call numbers...0xc0000000
Core dump limits :
 	soft - 0
 	hard - NONE
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
Adding 8470528 bytes to physical memory to account for exec-shield gap
kmsg_dump:
<1>bootmem alloc of 140 bytes failed!
<0>Kernel panic - not syncing: Out of memory
<4>CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-um #3
<6>Stack:
<4> 081eb922 081eb922 0822d547 00000000 08222000 00000000 0817fe48 00000000
<4> 0822bf6c 080bd1a7 00000007 0829c600 081f113d 0822bfbc 082220fc 00000000
<4> 00000000 00000000 0805393d 081f113d 0000008c 0804c88e 0000008c 00000080
<6>Call Trace:
<6> [<0805cffb>] ? 
<4>show_stack+0x9d/0x157
<6> [<0817fe48>] ? 
<4>dump_stack+0x23/0x2b
<6> [<080bd1a7>] ? 
<4>panic+0x9e/0x1b4
<6> [<0805393d>] ? 
<4>__alloc_bootmem+0x3f/0x43
<6> [<0804c88e>] ? 
<4>read_initrd+0x6a/0x101
<6> [<08096fa5>] ? 
<4>kmsg_dump_register+0x37/0x65
<6> [<0805e8a9>] ? 
<4>uml_finishsetup+0x27/0x3b
<6>

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


Function read_initrd() calls alloc_bootmem(), but at this point 
memory hasn't been initialized yet.

A quick solution is to move uml_postsetup() (the function
that calls read_initrd()) right after the memory has been
initialized. This may be wrong since uml_postsetup() may call
other functions besides read_initrd(), but worked for me:
the initial ramdisk is loaded and init run.


--- linux-4.9.0/arch/um/kernel/um_arch.c	2016-12-11 20:17:54.000000000 +0100
+++ linux-4.9.0-um/arch/um/kernel/um_arch.c	2017-01-15 11:16:32.000000000 +0100
@@ -231,7 +231,7 @@
  	atomic_notifier_chain_register(&panic_notifier_list,
  				       &panic_exit_notifier);

-	uml_postsetup();
+	// uml_postsetup();

  	new_thread_handler();
  }
@@ -340,6 +340,7 @@
  {
  	stack_protections((unsigned long) &init_thread_info);
  	setup_physmem(uml_physmem, uml_reserved, physmem_size, highmem);
+	uml_postsetup();
  	mem_total_pages(physmem_size, iomem_size, highmem);

  	paging_init();

[uml-devel] 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-devel] [PATCH] mtd: nand: oxnas_nand: fix build errors on arch/um, require HAS_IOMEM

[Randy D. <rd...@in...>]

From: Randy Dunlap <rd...@in...>

Fix build errors on arch/um, which does not support HAS_IOMEM,
while the oxnas_nand.c driver uses interfaces that are
supplied by HAS_IOMEM.

(loadable module build:)
ERROR: "devm_ioremap_resource" [drivers/mtd/nand/oxnas_nand.ko] undefined!
or (built-in build:)
drivers/built-in.o: In function `oxnas_nand_probe':
drivers/mtd/nand/oxnas_nand.c:102: undefined reference to `devm_ioremap_resource'

Signed-off-by: Randy Dunlap <rd...@in...>
Reported-by: kbuild test robot <fen...@in...>
Cc: Boris Brezillon <bor...@fr...>
Cc: Neil Armstrong <nar...@ba...>
Cc:	Jeff Dike <jd...@ad...>
Cc:	Richard Weinberger <ri...@no...>
Cc:	use...@li...
Cc:	lin...@li...
---
 drivers/mtd/nand/Kconfig |    1 +
 1 file changed, 1 insertion(+)

--- lnx-410-rc2.orig/drivers/mtd/nand/Kconfig
+++ lnx-410-rc2/drivers/mtd/nand/Kconfig
@@ -426,6 +426,7 @@ config MTD_NAND_ORION
 
 config MTD_NAND_OXNAS
 	tristate "NAND Flash support for Oxford Semiconductor SoC"
+	depends on HAS_IOMEM
 	help
 	  This enables the NAND flash controller on Oxford Semiconductor SoCs.
 

[uml-devel] [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