On Wed, Jun 22, 2016 at 12:18 PM, Cyrill Gorcunov <gorcunov@xxxxxxxxx> wrote: > On Wed, Jun 22, 2016 at 08:13:29AM -0700, Andy Lutomirski wrote: > ... >> > >> > However based on the above discussion, it appears that some sort of >> > prctl(PR_GET_TASK_SIZE, ...) and prctl(PR_SET_TASK_SIZE, ...) may be >> > preferable for AArch64. (And perhaps other justifications for the new >> > calls influences the x86 decisions.) What do folks think? >> >> I would advocate a slightly different approach: >> >> - Keep TASK_SIZE either unconditionally matching the hardware or keep >> TASK_SIZE as the actual logical split between user and kernel >> addresses. Don't let it change at runtime under any circumstances. >> The reason is that there have been plenty of bugs and >> overcomplications that result from letting it vary. For example, if >> (addr < TASK_SIZE) really ought to be the correct check (assuming >> USER_DS, anyway) for whether dereferencing addr will access user >> memory, at least on architectures with a global address space (which >> is most of them, I think). >> >> - If needed, introduce a clean concept of the maximum address that >> mmap will return, but don't call it TASK_SIZE. So, if a user program >> wants to limit itself to less than the full hardware VA space (or less >> than 63 bits, for that matter), it can. >> >> As an example, a 32-bit x86 program really could have something mapped >> above the 32-bit boundary. It just wouldn't be useful, but the kernel >> should still understand that it's *user* memory. >> >> So you'd have PR_SET_MMAP_LIMIT and PR_GET_MMAP_LIMIT or similar instead. > > +1. Also it might be (not sure though, just guessing) suitable to do such > thing via memory cgroup controller, instead of carrying this limit per > each process (or task structure/vma or mm). I think we'll want this per mm. After all, a high-VA-limit-aware bash should be able run high-VA-unaware programs without fiddling with cgroups. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>