From: Jeff D. <jd...@ad...> - 2004-02-16 19:41:01
|
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 |
From: BlaisorBlade <bla...@ya...> - 2004-02-20 17:43:55
|
Alle 21:04, luned=EC 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 yo= u=20 just applied first part of Young's patch. I.e. the user actually gets less= =20 memory, as in his first patch, so the kernel will crash when it would be=20 exhausting memory. Have you thought to something? IMHO, the broken code is= =20 this one in setup_physmem(): + offset =3D uml_reserved - uml_physmem; + err =3D 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:=20 + /* Reserve up to 4M after the current brk */ + uml_reserved =3D ROUND_4M(brk_start) + (1 << 22); the setup_physmem code thinks that "offset" bytes of real memory have alrea= dy=20 been allocated, while this is not true. Also, after calling setup_physmem y= ou=20 change uml_reserved: + /* Map in the area just after the brk now that kmalloc is about + * to be turned on. + */ + brk_end =3D (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 =3D brk_end; This seems to me a bit inconsistent and difficult to read (uml_reserved is = a=20 global variable); the 4 missing megas (reserved to give some space to=20 malloc() before kmalloc can be used through __wrap_malloc) are then remappe= d=20 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 -=3D UML_ROUND_UP(brk_start) - UML_ROUND_UP(&_end); similarly to what Young proposed, (something similar but less kludgy could = be=20 put here); but his fix was just like increasing the mem=3D param on the com= mand=20 line, and the increased value is then passed to init_maps so that=20 totalram_pages (i.e. how much memory the kernel thinks to have) will be the= =20 increased one: once again, the kernel has less memory than it thinks to hav= e;=20 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? =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: M A Y. <m.a...@du...> - 2004-02-20 22:30:18
|
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 |
From: BlaisorBlade <bla...@ya...> - 2004-02-21 15:55:14
|
Alle 23:23, venerd=EC 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 -=3D 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 = =2D I=20 should have written len +=3D UML_ROUND_UP(brk_start) - UML_ROUND_UP(&_end);= (or=20 something similar). My idea was not about increasing the allocated memory by mmaping at an earl= ier=20 offset, but about just increasing the length. Just like increasing physmem_size but without changing how much memory thin= ks=20 to have: IMHO, even with 256 Mega UML can crash, if it thinks to have 260=20 mega, but it won't crash if it has 32 Mega and knows it has so little (it=20 will swap or OOM, not crash). Right? =2D-=20 Paolo Giarrusso, aka Blaisorblade Linux registered user n. 292729 |
From: M A Y. <m.a...@du...> - 2004-02-21 21:01:17
|
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 |
From: BlaisorBlade <bla...@ya...> - 2004-02-22 15:38:32
|
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 |