linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Michael Ellerman <mpe@ellerman.id.au>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Florian Weimer <fweimer@redhat.com>,
	linuxppc-dev@lists.ozlabs.org,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH 2/5] powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary
Date: Tue, 7 Nov 2017 13:52:35 +1100	[thread overview]
Message-ID: <20171107135235.38042223@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <878tfi4ybr.fsf@concordia.ellerman.id.au>

On Tue, 07 Nov 2017 13:28:08 +1100
Michael Ellerman <mpe@ellerman.id.au> wrote:

> Nicholas Piggin <npiggin@gmail.com> writes:
> 
> > On Mon, 06 Nov 2017 16:14:10 +0530
> > "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com> wrote:
> >  
> >> Nicholas Piggin <npiggin@gmail.com> writes:
> >>   
> >> > While mapping hints with a length that cross 128TB are disallowed,
> >> > MAP_FIXED allocations that cross 128TB are allowed. These are failing
> >> > on hash (on radix they succeed). Add an additional case for fixed
> >> > mappings to expand the addr_limit when crossing 128TB.    
> >> 
> >> Shouldn't that be fixed in radix. But i see x86 also doing this?
> >> 
> >> 
> >> 	if (flags & MAP_FIXED)
> >> 		return addr;
> >> 
> >> Kiril,
> >> 
> >> Is that expected?  
> >
> > I should actually reply to this one because the other did not
> > have Kirill on cc.
> >
> > Generic mapping code appears it will always succeed when given an
> > explicit hint request, even if the address is below the boundary
> > and address + length is above it. Even when !MAP_FIXED. This is the
> > sane behaviour AFAIKS.  
> 
> It's "sane" if you want the 128T boundary to be invisible.

Not invisible: mmap(NULL, length, ...) + length < 128TB

> But the whole goddamn point was that we wanted apps to have to opt-in to
> using > 128T, and having brk accidentally go over the 128T boundary does
> not count as opting in.

If brk() is given an explicit address > 128TB, then that's opting
in, right?

If malloc is doing some allocation scheme which "opts in", such as
using explicit brk or mmap, then there is no way for the kernel to
solve that. Making increasingly convoluted policy to try to allow
the good and reject the bad is not right IMO.

> So it's a mess as usual.

If we wanted to make this ABI-identical with existing systems, then
it can't work without out-of-band opt-in. Why wasn't a personality
+ sysctl used for this, as we apparently have for a previous address
space layout change?

> 
> > So we should switch powerpc to match, shouldn't we?  
> 
> Yes we should do whatever the other arches do. 
> 
> Actually we should do what the man page describes .. except it doesn't.

  reply	other threads:[~2017-11-07  2:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-06 10:03 [PATCH 0/5] VA allocator fixes Nicholas Piggin
2017-11-06 10:03 ` [PATCH 1/5] powerpc/64s/hash: Fix 128TB-512TB virtual address boundary case allocation Nicholas Piggin
2017-11-06 10:38   ` Aneesh Kumar K.V
2017-11-06 10:54     ` Nicholas Piggin
2017-11-06 11:05       ` Aneesh Kumar K.V
2017-11-06 11:21         ` Nicholas Piggin
2017-11-07  2:00         ` Aneesh Kumar K.V
2017-11-07  2:03           ` Nicholas Piggin
2017-11-06 10:03 ` [PATCH 2/5] powerpc/64s/hash: Allow MAP_FIXED allocations to cross 128TB boundary Nicholas Piggin
2017-11-06 10:44   ` Aneesh Kumar K.V
2017-11-06 11:55     ` Nicholas Piggin
2017-11-07  2:28       ` Michael Ellerman
2017-11-07  2:52         ` Nicholas Piggin [this message]
2017-11-06 10:03 ` [PATCH 3/5] powerpc/64s/hash: Fix fork() with 512TB process address space Nicholas Piggin
2017-11-06 10:44   ` Aneesh Kumar K.V
2017-11-06 10:03 ` [PATCH 4/5] powerpc/64s/radix: Fix 128TB-512TB virtual address boundary case allocation Nicholas Piggin
2017-11-06 11:14   ` Aneesh Kumar K.V
2017-11-06 11:42     ` Nicholas Piggin
2017-11-06 10:03 ` [PATCH 5/5] powerpc/64s: mm_context.addr_limit is only used on hash Nicholas Piggin
2017-11-06 15:16 ` [PATCH 0/5] VA allocator fixes Florian Weimer
2017-11-07  0:06   ` Nicholas Piggin
2017-11-07  1:59     ` Aneesh Kumar K.V

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171107135235.38042223@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=fweimer@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).