Thread (25 messages) 25 messages, 9 authors, 2017-03-06

Re: [PATCHv3 33/33] mm, x86: introduce PR_SET_MAX_VADDR and PR_GET_MAX_VADDR

From: hpa@zytor.com
Date: 2017-02-17 23:12:25
Also in: linux-arch, linux-mm, lkml

Possibly related (same subject, not in this thread)

On February 17, 2017 3:02:33 PM PST, Andy Lutomirski [off-list ref] wrote:
On Fri, Feb 17, 2017 at 1:01 PM, Linus Torvalds
[off-list ref] wrote:
quoted
On Fri, Feb 17, 2017 at 12:12 PM, Andy Lutomirski
[off-list ref] wrote:
quoted
quoted
At the very least, I'd want to see
MAP_FIXED_BUT_DONT_BLOODY_UNMAP_ANYTHING.  I *hate* the current
interface.
That's unrelated, but I guess w could add a MAP_NOUNMAP flag, and
then
quoted
you can use MAP_FIXED | MAP_NOUNMAP or something.

But that has nothing to do with the 47-vs-56 bit issue.
quoted
How about MAP_LIMIT where the address passed in is interpreted as an
upper bound instead of a fixed address?
Again, that's a unrelated semantic issue. Right now - if you don't
pass in MAP_FIXED at all, the "addr" argument is used as a starting
value for deciding where to find an unmapped area. But there is no
way
quoted
to specify the end. That would basically be what the process control
thing would be (not per-system-call, but per-thread ).
What I'm trying to say is: if we're going to do the route of 48-bit
limit unless a specific mmap call requests otherwise, can we at least
have an interface that doesn't suck?
Let's not, please.

But we really want this interface anyway.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help