All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Florian Weimer <fweimer@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linuxppc-dev@lists.ozlabs.org, linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Dave Hansen <dave.hansen@intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arch@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: POWER: Unexpected fault when writing to brk-allocated memory
Date: Fri, 10 Nov 2017 04:15:26 +1100	[thread overview]
Message-ID: <20171110041526.6137bc9a@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20171107140158.iz4b2lchhrt6eobe@node.shutemov.name>

On Tue, 7 Nov 2017 17:01:58 +0300
"Kirill A. Shutemov" <kirill@shutemov.name> wrote:

> On Tue, Nov 07, 2017 at 07:15:58PM +0530, Aneesh Kumar K.V wrote:
> >   
> > > 
> > > If it is decided to keep these kind of heuristics, can we get just a
> > > small but reasonably precise description of each change to the
> > > interface and ways for using the new functionality, such that would be
> > > suitable for the man page? I couldn't fix powerpc because nothing
> > > matches and even Aneesh and you differ on some details (MAP_FIXED
> > > behaviour).  
> > 
> > 
> > I would consider MAP_FIXED as my mistake. We never discussed this explicitly
> > and I kind of assumed it to behave the same way. ie, we search in lower
> > address space (128TB) if the hint addr is below 128TB.
> > 
> > IIUC we agree on the below.
> > 
> > 1) MAP_FIXED allow the addr to be used, even if hint addr is below 128TB but
> > hint_addr + len is > 128TB.
> > 
> > 2) For everything else we search in < 128TB space if hint addr is below
> > 128TB
> > 
> > 3) We don't switch to large address space if hint_addr + len > 128TB. The
> > decision to switch to large address space is primarily based on hint addr
> > 
> > Is there any other rule we need to outline? Or is any of the above not
> > correct?  
> 
> That's correct.
> 

Thanks guys, I'll send out some powerpc patches to match -- it deviates in
its MAP_FIXED handling (treats it the same as !MAP_FIXED).

So these semantics are what we're going with? Anything that does mmap() is
guaranteed of getting a 47-bit pointer and it can use the top 17 bits for
itself? Is intended to be cross-platform or just x86 and power specific?

Also, this may follow from deduction from 1-3, but for explicit
specification in man page:

4) To get an unspecified allocation with the largest possible address range,
we pass in -1 for mmap hint.

Are we allowing 8 bits bits of unused address in this case, or must the
app not assume anything about number of bits used?

Thanks,
Nick

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Florian Weimer <fweimer@redhat.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	linuxppc-dev@lists.ozlabs.org, linux-mm <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Dave Hansen <dave.hansen@intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	linux-arch@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: POWER: Unexpected fault when writing to brk-allocated memory
Date: Fri, 10 Nov 2017 04:15:26 +1100	[thread overview]
Message-ID: <20171110041526.6137bc9a@roar.ozlabs.ibm.com> (raw)
Message-ID: <20171109171526.FR8_A3Wzy6JIfAU8pRqe5nqIRfjSJ-RwivBdSU6jJq8@z> (raw)
In-Reply-To: <20171107140158.iz4b2lchhrt6eobe@node.shutemov.name>

On Tue, 7 Nov 2017 17:01:58 +0300
"Kirill A. Shutemov" <kirill@shutemov.name> wrote:

> On Tue, Nov 07, 2017 at 07:15:58PM +0530, Aneesh Kumar K.V wrote:
> >   
> > > 
> > > If it is decided to keep these kind of heuristics, can we get just a
> > > small but reasonably precise description of each change to the
> > > interface and ways for using the new functionality, such that would be
> > > suitable for the man page? I couldn't fix powerpc because nothing
> > > matches and even Aneesh and you differ on some details (MAP_FIXED
> > > behaviour).  
> > 
> > 
> > I would consider MAP_FIXED as my mistake. We never discussed this explicitly
> > and I kind of assumed it to behave the same way. ie, we search in lower
> > address space (128TB) if the hint addr is below 128TB.
> > 
> > IIUC we agree on the below.
> > 
> > 1) MAP_FIXED allow the addr to be used, even if hint addr is below 128TB but
> > hint_addr + len is > 128TB.
> > 
> > 2) For everything else we search in < 128TB space if hint addr is below
> > 128TB
> > 
> > 3) We don't switch to large address space if hint_addr + len > 128TB. The
> > decision to switch to large address space is primarily based on hint addr
> > 
> > Is there any other rule we need to outline? Or is any of the above not
> > correct?  
> 
> That's correct.
> 

Thanks guys, I'll send out some powerpc patches to match -- it deviates in
its MAP_FIXED handling (treats it the same as !MAP_FIXED).

So these semantics are what we're going with? Anything that does mmap() is
guaranteed of getting a 47-bit pointer and it can use the top 17 bits for
itself? Is intended to be cross-platform or just x86 and power specific?

Also, this may follow from deduction from 1-3, but for explicit
specification in man page:

4) To get an unspecified allocation with the largest possible address range,
we pass in -1 for mmap hint.

Are we allowing 8 bits bits of unused address in this case, or must the
app not assume anything about number of bits used?

Thanks,
Nick

  reply	other threads:[~2017-11-09 17:15 UTC|newest]

Thread overview: 70+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-03 17:05 POWER: Unexpected fault when writing to brk-allocated memory Florian Weimer
2017-11-03 17:05 ` Florian Weimer
2017-11-05 12:18 ` Nicholas Piggin
2017-11-05 12:18   ` Nicholas Piggin
2017-11-05 12:35   ` Florian Weimer
2017-11-05 12:54     ` Nicholas Piggin
2017-11-05 12:54       ` Nicholas Piggin
2017-11-05 14:50   ` Florian Weimer
2017-11-05 14:50     ` Florian Weimer
2017-11-06  6:18   ` Aneesh Kumar K.V
2017-11-06  6:18     ` Aneesh Kumar K.V
2017-11-06  6:47     ` Nicholas Piggin
2017-11-06  6:47       ` Nicholas Piggin
2017-11-06  8:11       ` Florian Weimer
2017-11-06  8:11         ` Florian Weimer
2017-11-06  8:25         ` Nicholas Piggin
2017-11-06  8:25           ` Nicholas Piggin
2017-11-06  8:30           ` Aneesh Kumar K.V
2017-11-06  8:30             ` Aneesh Kumar K.V
2017-11-06  8:32             ` Florian Weimer
2017-11-06  8:32               ` Florian Weimer
2017-11-06 10:20               ` Nicholas Piggin
2017-11-06 10:20                 ` Nicholas Piggin
2017-11-07  5:07               ` Nicholas Piggin
2017-11-07  5:07                 ` Nicholas Piggin
2017-11-07  8:15                 ` Florian Weimer
2017-11-07  8:15                   ` Florian Weimer
2017-11-07  9:24                   ` Nicholas Piggin
2017-11-07  9:24                     ` Nicholas Piggin
2017-11-07 11:16                   ` Kirill A. Shutemov
2017-11-07 11:16                     ` Kirill A. Shutemov
2017-11-07 11:15                 ` Kirill A. Shutemov
2017-11-07 11:15                   ` Kirill A. Shutemov
2017-11-07 11:26                   ` Florian Weimer
2017-11-07 11:26                     ` Florian Weimer
2017-11-07 11:44                     ` Kirill A. Shutemov
2017-11-07 11:44                       ` Kirill A. Shutemov
2017-11-07 13:05                       ` Florian Weimer
2017-11-07 13:16                         ` Kirill A. Shutemov
2017-11-07 13:16                           ` Kirill A. Shutemov
2017-11-08  6:08                           ` Michael Ellerman
2017-11-08  6:08                             ` Michael Ellerman
2017-11-08  6:18                             ` Florian Weimer
2017-11-08  6:18                               ` Florian Weimer
2017-11-07 11:56                   ` Nicholas Piggin
2017-11-07 11:56                     ` Nicholas Piggin
2017-11-07 12:28                     ` Kirill A. Shutemov
2017-11-07 12:28                       ` Kirill A. Shutemov
2017-11-07 13:33                       ` Nicholas Piggin
2017-11-07 13:33                         ` Nicholas Piggin
2017-11-07 13:45                         ` Aneesh Kumar K.V
2017-11-07 13:45                           ` Aneesh Kumar K.V
2017-11-07 14:01                           ` Kirill A. Shutemov
2017-11-07 14:01                             ` Kirill A. Shutemov
2017-11-09 17:15                             ` Nicholas Piggin [this message]
2017-11-09 17:15                               ` Nicholas Piggin
2017-11-09 19:44                               ` Matthew Wilcox
2017-11-09 19:44                                 ` Matthew Wilcox
2017-11-10  1:26                                 ` Nicholas Piggin
2017-11-10  1:26                                   ` Nicholas Piggin
2017-11-10 12:08                                 ` David Laight
2017-11-10 12:08                                   ` David Laight
2017-11-11 10:30                                   ` Nicholas Piggin
2017-11-11 10:30                                     ` Nicholas Piggin
2017-11-08  4:56                           ` Michael Ellerman
2017-11-08  4:56                             ` Michael Ellerman
2017-11-08  8:30                             ` Kirill A. Shutemov
2017-11-08  8:30                               ` Kirill A. Shutemov
2017-11-06  8:10     ` Florian Weimer
2017-11-06  8:10       ` Florian Weimer

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=20171110041526.6137bc9a@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=dave.hansen@intel.com \
    --cc=fweimer@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=kirill@shutemov.name \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@amacapital.net \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.