On Fri, 12 Sep 2025 09:58:49 +0200, Benjamin Berg wrote: > On Fri, 2025-09-12 at 08:30 +0800, Tiwei Bie wrote: > > On Thu, 11 Sep 2025 10:06:53 +0200, Benjamin Berg wrote: > > > > > [SNIP] > > > That said, I do believe that the allocations from the libc itself are > > > problematic. A lot of the mappings from UML are there already (i.e. the > > > physical memory is mapped). However, I believe the vmalloc area for > > > example is not guarded. > > > > > > So when pthread allocates the thread specific memory (stack, TLS, ...), > > > we really do not know where this will be mapped into the address space. > > > If it happens to be in an area that UML wants to use later, then UML > > > could map e.g. vmalloc data over it. > > > > > > Now, it could be that (currently) the addresses picked by pthread (or > > > the host kernel) do not actually clash with anything. However, I do not > > > think there is any guarantee for that. > > > > Indeed. The mmap from libc (pthread, shared libs, ...) can potentially > > conflict with UML. The reason it has been working on x86_64 so far might > > be that we did this in linux_main(): > > > > task_size = task_size & PGDIR_MASK; > > > > The current layout is: > > > > shared libs and pthreads are located at 7ffxxxxxxxxx > > TASK_SIZE = 7f8000000000 > > VMALLOC_END = 7f7fffffe000 (which is > > TASK_SIZE-2*PAGE_SIZE) > > Uh, right, yes. Because of the masking we are capping ourselves to > 0x7f8000000000. And then all of the interesting bits (vdso, ...) happen > to be mapped above that address and are effectively protected. And, > there is also plenty of space for other allocations technically. > > That is kind of horrible, as it only works because all of this happens > to be mapped into the top of the address space.
+1. > But, maybe something to > just wilfully ignore and only fix as part of a nolibc port? Sure. Thanks! Regards, Tiwei
