uweigand added inline comments.
================ Comment at: compiler-rt/lib/tsan/rtl/tsan_platform_posix.cpp:123 +#if defined(__s390x__) + ProtectRange(HiAppMemEnd(), 0xfffffffffffff000ull); +#endif ---------------- iii wrote: > uweigand wrote: > > iii wrote: > > > uweigand wrote: > > > > Did you test this on older kernels without 5-level page table support? > > > > I believe the allocation / mprotect may fail on those ... > > > No, not really. Would it make sense to probe here? E.g. first try > > > 0xfffffffffffff000, then 0x20000000000000. Or is there a way to query > > > user_addr_max() / TASK_SIZE_MAX / TASK_SIZE? > > I don't know of any way to query this. You can simply do the allocation in > > stages (first to the top of the three-pagetable range, then four, then > > five), and ignore failures. As an unfortunate side effect this will force > > the kernel to allocate five levels of page tables even when unnecessary, > > but I don't think there's anything we can do about that. > 3-level page table limit is quite below the application range defined in this > series (0x40000000000 < 0xc00000000000). Are there any relevant kernels that > do not support 4-level page tables? I tried to search the git history, and it > looks as if even 2.6 ones have it. Ah, right. Yes, we can certainly assume 4-level support at this point. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D105629/new/ https://reviews.llvm.org/D105629 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
