[uml-devel] uml-patch-2.4.24-1

[uml-devel] uml-patch-2.4.24-1

[Jeff Dike]

This patch updates UML to 2.4.24, and pushes out the fixes that have 
accumulated, including
        mconsole log (in combination with the next utilities release) will 
add a newline to the end of all input
        rebooting or halting a UML with mconsole sysrq will no longer hang
the client
        worked around the bug which caused /proc to have a 1970 date
        fixed a race which could cause a userspace signal to appear to have 
happened in the kernel and panicing it
        fixed some exec_shield brokenness.
        changed HZ to 100, fixing some time problems, including ps start times
drifting away from real time, and maybe some at brokenness

                                Jeff



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: 2.4.24-1um - exec-shield - [PATCH][RFC] memory shortness fix

[BlaisorBlade]

Alle 21:04, lunedì 16 febbraio 2004, Jeff Dike ha scritto:
> This patch updates UML to 2.4.24, and pushes out the fixes that have
> accumulated, including

>         fixed some exec_shield brokenness.

I diffed the two patches (2.4.23-2 and 2.4.24-1) and what I saw was that you 
just applied first part of Young's patch. I.e. the user actually gets less 
memory, as in his first patch, so the kernel will crash when it would be 
exhausting memory. Have you thought to something? IMHO, the broken code is 
this one in setup_physmem():

+       offset = uml_reserved - uml_physmem;
+       err = os_map_memory((void *) uml_reserved, physmem_fd, offset,
+                           len - offset, 1, 1, 0);

because uml_reserved is (in this point) sbrk(0) rounded up to 4 M: 

+       /* Reserve up to 4M after the current brk */
+       uml_reserved = ROUND_4M(brk_start) + (1 << 22);

the setup_physmem code thinks that "offset" bytes of real memory have already 
been allocated, while this is not true. Also, after calling setup_physmem you 
change uml_reserved:

+       /* Map in the area just after the brk now that kmalloc is about
+        * to be turned on.
+        */
+       brk_end = (unsigned long) UML_ROUND_UP(sbrk(0));
+       map_cb(NULL);
+       initial_thread_cb(map_cb, NULL);
+       free_bootmem(__pa(brk_end), uml_reserved - brk_end);
+       uml_reserved = brk_end;

This seems to me a bit inconsistent and difficult to read (uml_reserved is a 
global variable); the 4 missing megas (reserved to give some space to 
malloc() before kmalloc can be used through __wrap_malloc) are then remapped 
by map_cb, but this sounds a bit kludgy.

Anyway, changing uml_reserved that way deserves at least a comment.

The simple fix would be IMHO to add in setup_physmem:

  offset -= UML_ROUND_UP(brk_start) - UML_ROUND_UP(&_end);

similarly to what Young proposed, (something similar but less kludgy could be 
put here); but his fix was just like increasing the mem= param on the command 
line, and the increased value is then passed to init_maps so that 
totalram_pages (i.e. how much memory the kernel thinks to have) will be the 
increased one: once again, the kernel has less memory than it thinks to have; 
so instead of swapping when memory ends UML will crash.

Instead, with this one, UML still thinks to have 32 mega and gets them.

Any idea or comment?
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

[uml-devel] Re: 2.4.24-1um - exec-shield - [PATCH][RFC] memory shortness fix

[M A Young]

On Fri, 20 Feb 2004, BlaisorBlade wrote:

> The simple fix would be IMHO to add in setup_physmem:
>
>   offset -= UML_ROUND_UP(brk_start) - UML_ROUND_UP(&_end);

You can't do that because the memory you add to the physmem area isn't
empty, but includes memory used for other purposes, and using memory twice
isn't good!

	Michael Young


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: 2.4.24-1um - exec-shield - [PATCH][RFC] memory shortness fix

[BlaisorBlade]

Alle 23:23, venerdì 20 febbraio 2004, M A Young ha scritto:
> On Fri, 20 Feb 2004, BlaisorBlade wrote:
> > The simple fix would be IMHO to add in setup_physmem:
> >
> >   offset -= UML_ROUND_UP(brk_start) - UML_ROUND_UP(&_end);
>
> You can't do that because the memory you add to the physmem area isn't
> empty, but includes memory used for other purposes, and using memory twice
> isn't good!

Yes, you are perfectly right and what I wrote is at all foolish and stupid - I 
should have written len += UML_ROUND_UP(brk_start) - UML_ROUND_UP(&_end); (or 
something similar).

My idea was not about increasing the allocated memory by mmaping at an earlier 
offset, but about just increasing the length.

Just like increasing physmem_size but without changing how much memory thinks 
to have: IMHO, even with 256 Mega UML can crash, if it thinks to have 260 
mega, but it won't crash if it has 32 Mega and knows it has so little (it 
will swap or OOM, not crash). Right?

-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id\x1356&alloc_id438&opÌk
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: 2.4.24-1um - exec-shield - [PATCH][RFC] memory shortness fix

[M A Young]

On Sat, 21 Feb 2004, BlaisorBlade wrote:

> Yes, you are perfectly right and what I wrote is at all foolish and stupid - I
> should have written len += UML_ROUND_UP(brk_start) - UML_ROUND_UP(&_end); (or
> something similar).

That doesn't help you either, because increasing len within setup_physmem
writes to memory that is going to be used for other purposes. The only way
around this amounts to increasing physmem_size anyway.

	Michael Young


-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] Re: 2.4.24-1um - exec-shield - [PATCH][RFC] memory shortness fix

[BlaisorBlade]

Alle 21:54, sabato 21 febbraio 2004, M A Young ha scritto:
> On Sat, 21 Feb 2004, BlaisorBlade wrote:
> > Yes, you are perfectly right and what I wrote is at all foolish and
> > stupid - I should have written len += UML_ROUND_UP(brk_start) -
> > UML_ROUND_UP(&_end); (or something similar).
>
> That doesn't help you either, because increasing len within setup_physmem
> writes to memory that is going to be used for other purposes.
Why cannot we fix the other mmaps from the file?
> The only way
> around this amounts to increasing physmem_size anyway.

I must repeat myself: it seems that increasing physmem_size by, i.e., 4megas, 
when the user asked, i.e., for 32 mega, means that the kernel will have 
correctly 32mega of memory, but that it can try to access 36 mega of memory, 
right? I've actually checked that the statistics about how much memory it can 
use come from physmem_size, through init_maps() and mem_init():

        /* this will put all low memory onto the freelists */
        totalram_pages = free_all_bootmem();

Please, read this email and correct me on this point if I am wrong or confirm 
this behaviour.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729



-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel