Currently, UML locates its text, data, and physical and kernel virtual memory areas in the middle of its process' address spaces. This causes some virtual address space fragmentation which could break some applications which need large contiguous areas of virtual memory.
This will be fixed by relocating all of UML's data above TASK_SIZE, allowing the process to use all memory below that. The UML TASK_SIZE will be lower than the host TASK_SIZE by enough to fit UML and its data between them.
However, with the standard TASK_SIZE on the host, this will break one specialized application of UML - honeypots. For UML to work as a honeypot, exploits that work against physical machines also have to work against virtual machines. For stack smash attacks, this requires that the stack be in the same location in the address space as on the host. So, I'm planning on allowing the process stack to occupy the very top of the process address space, with UML just below that, and the process having a large contiguous virtual memory area below that. A cleaner solution, but one which requires that the host kernel be rebuilt, is to change the userspace/kernelspace virtual address space split from the usual 3G/1G to something like 3.5G/.5G. This would allow the UML TASK_SIZE to be 0xc0000000, which would leave the process stacks in the same location as they are on a normally configured host.