On Thu, Jan 5, 2017 at 11:39 AM, Dave Hansen [off-list ref] wrote:

On 01/05/2017 11:29 AM, Kirill A. Shutemov wrote:

quoted

On Thu, Jan 05, 2017 at 11:13:57AM -0800, Dave Hansen wrote:

quoted

On 12/26/2016 05:54 PM, Kirill A. Shutemov wrote:

quoted

MM would use min(RLIMIT_VADDR, TASK_SIZE) as upper limit of virtual
address available to map by userspace.

What happens to existing mappings above the limit when this upper limit
is dropped?

Nothing: we only prevent creating new mappings. All existing are not
affected.

The semantics here the same as with other resource limits.

quoted

Similarly, why do we do with an application running with something
incompatible with the larger address space that tries to raise the
limit?  Say, legacy MPX.

It has to know what it does. Yes, it can change limit to the point where
application is unusable. But you can to the same with other limits.

I'm not sure I'm comfortable with this.  Do other rlimit changes cause
silent data corruption?  I'm pretty sure doing this to MPX would.

What actually goes wrong in this case?  That is, what combination of
MPX setup of subsequent allocations will cause a problem, and is the
problem worse than just a segfault?  IMO it would be really nice to
keep the messy case confined to MPX.

FWIW, this problem is kind of generic.  If you run code in a process,
MPX or otherwise, that assumes something about pointer values and then
create a pointer that violates its assumptions, you will cause
problems.  For example, some VMs use high bits to store metadata.  If
you feed a pointer that's too big to such code, boom.  This is exactly
why high addresses need to be opt-in.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>