From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Laight Subject: RE: POWER: Unexpected fault when writing to brk-allocated memory Date: Fri, 10 Nov 2017 12:08:35 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD00B84EF@AcuExch.aculab.com> References: <546d4155-5b7c-6dba-b642-29c103e336bc@redhat.com> <20171107160705.059e0c2b@roar.ozlabs.ibm.com> <20171107111543.ep57evfxxbwwlhdh@node.shutemov.name> <20171107222228.0c8a50ff@roar.ozlabs.ibm.com> <20171107122825.posamr2dmzlzvs2p@node.shutemov.name> <20171108002448.6799462e@roar.ozlabs.ibm.com> <2ce0a91c-985c-aad8-abfa-e91bc088bb3e@linux.vnet.ibm.com> <20171107140158.iz4b2lchhrt6eobe@node.shutemov.name> <20171110041526.6137bc9a@roar.ozlabs.ibm.com> <20171109194421.GA12789@bombadil.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <20171109194421.GA12789@bombadil.infradead.org> Content-Language: en-US List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+glppe-linuxppc-embedded-2=m.gmane.org@lists.ozlabs.org Sender: "Linuxppc-dev" To: 'Matthew Wilcox' , Nicholas Piggin Cc: Florian Weimer , "linux-arch@vger.kernel.org" , linux-mm , Peter Zijlstra , "linuxppc-dev@lists.ozlabs.org" , Linux Kernel Mailing List , Andy Lutomirski , Dave Hansen , Thomas Gleixner , "Aneesh Kumar K.V" , "Kirill A. Shutemov" , Andrew Morton , Linus Torvalds , Ingo Molnar , "Kirill A. Shutemov" List-Id: linux-arch.vger.kernel.org From: Matthew Wilcox > Sent: 09 November 2017 19:44 >=20 > On Fri, Nov 10, 2017 at 04:15:26AM +1100, Nicholas Piggin wrote: > > 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 f= or > > itself? Is intended to be cross-platform or just x86 and power specific= ? >=20 > It is x86 and powerpc specific. The arm64 people have apparently stumble= d > across apps that expect to be able to use bit 48 for their own purposes. > And their address space is 48 bit by default. Oops. (Do you mean 49bit?) Aren't such apps just doomed to be broken? ISTR there is something on (IIRC) sparc64 that does a 'match' on the high address bits to make it much harder to overrun one area into another. David From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out4.electric.net (smtp-out4.electric.net [192.162.216.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3yYJj52gKXzDrKG for ; Fri, 10 Nov 2017 23:08:39 +1100 (AEDT) From: David Laight To: 'Matthew Wilcox' , Nicholas Piggin CC: Florian Weimer , "linux-arch@vger.kernel.org" , Dave Hansen , "Peter Zijlstra" , Linus Torvalds , Ingo Molnar , "Linux Kernel Mailing List" , Andy Lutomirski , linux-mm , Aneesh Kumar K.V , "Kirill A. Shutemov" , Andrew Morton , "linuxppc-dev@lists.ozlabs.org" , "Thomas Gleixner" , "Kirill A. Shutemov" Subject: RE: POWER: Unexpected fault when writing to brk-allocated memory Date: Fri, 10 Nov 2017 12:08:35 +0000 Message-ID: <063D6719AE5E284EB5DD2968C1650D6DD00B84EF@AcuExch.aculab.com> References: <546d4155-5b7c-6dba-b642-29c103e336bc@redhat.com> <20171107160705.059e0c2b@roar.ozlabs.ibm.com> <20171107111543.ep57evfxxbwwlhdh@node.shutemov.name> <20171107222228.0c8a50ff@roar.ozlabs.ibm.com> <20171107122825.posamr2dmzlzvs2p@node.shutemov.name> <20171108002448.6799462e@roar.ozlabs.ibm.com> <2ce0a91c-985c-aad8-abfa-e91bc088bb3e@linux.vnet.ibm.com> <20171107140158.iz4b2lchhrt6eobe@node.shutemov.name> <20171110041526.6137bc9a@roar.ozlabs.ibm.com> <20171109194421.GA12789@bombadil.infradead.org> In-Reply-To: <20171109194421.GA12789@bombadil.infradead.org> Content-Type: text/plain; charset="Windows-1252" MIME-Version: 1.0 List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Matthew Wilcox > Sent: 09 November 2017 19:44 >=20 > On Fri, Nov 10, 2017 at 04:15:26AM +1100, Nicholas Piggin wrote: > > 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 f= or > > itself? Is intended to be cross-platform or just x86 and power specific= ? >=20 > It is x86 and powerpc specific. The arm64 people have apparently stumble= d > across apps that expect to be able to use bit 48 for their own purposes. > And their address space is 48 bit by default. Oops. (Do you mean 49bit?) Aren't such apps just doomed to be broken? ISTR there is something on (IIRC) sparc64 that does a 'match' on the high address bits to make it much harder to overrun one area into another. David