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

[BlaisorBlade <blaisorblade_spam@yahoo.it>]

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