Re: POWER: Unexpected fault when writing to brk-allocated memory

On Fri, 10 Nov 2017 12:08:35 + David Laight wrote: > From: Matthew Wilcox > > Sent: 09 November 2017 19:44 > > > > 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 > >

RE: POWER: Unexpected fault when writing to brk-allocated memory

From: Matthew Wilcox > Sent: 09 November 2017 19:44 > > 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 for > > itself? Is

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Thu, 9 Nov 2017 11:44:21 -0800 Matthew Wilcox wrote: > 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

Re: POWER: Unexpected fault when writing to brk-allocated memory

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 for > itself? Is intended to be cross-platform or just x86 and power specific? It

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, 7 Nov 2017 17:01:58 +0300 "Kirill A. Shutemov" 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

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Wed, Nov 08, 2017 at 03:56:06PM +1100, Michael Ellerman wrote: > "Aneesh Kumar K.V" writes: > > >> > >> 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

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/08/2017 07:08 AM, Michael Ellerman wrote: "Kirill A. Shutemov" writes: On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: On 11/07/2017

Re: POWER: Unexpected fault when writing to brk-allocated memory

"Kirill A. Shutemov" writes: > On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: >> On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: >> > On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: >> > > On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote:

Re: POWER: Unexpected fault when writing to brk-allocated memory

"Aneesh Kumar K.V" writes: >> >> 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

Re: POWER: Unexpected fault when writing to brk-allocated memory

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

Re: POWER: Unexpected fault when writing to brk-allocated memory

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

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, 7 Nov 2017 15:28:25 +0300 "Kirill A. Shutemov" wrote: > On Tue, Nov 07, 2017 at 10:56:36PM +1100, Nicholas Piggin wrote: > > > No, it won't. You will hit stack first. > > > > I guess so. Florian's bug didn't crash there for some reason, okay > > but I suppose my

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, Nov 07, 2017 at 02:05:42PM +0100, Florian Weimer wrote: > On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: > > On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: > > > On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: > > > > > > > > First of all, using addr and MAP_FIXED to

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 12:44 PM, Kirill A. Shutemov wrote: On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal.

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, Nov 07, 2017 at 10:56:36PM +1100, Nicholas Piggin wrote: > > No, it won't. You will hit stack first. > > I guess so. Florian's bug didn't crash there for some reason, okay > but I suppose my point about brk is not exactly where the standard > heap is, but the pattern of allocations. An

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, 7 Nov 2017 14:15:43 +0300 "Kirill A. Shutemov" wrote: > On Tue, Nov 07, 2017 at 04:07:05PM +1100, Nicholas Piggin wrote: > > C'ing everyone who was on the x86 56-bit user virtual address patch. > > > > I think we need more time to discuss this behaviour, in light

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, Nov 07, 2017 at 12:26:12PM +0100, Florian Weimer wrote: > On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: > > > > First of all, using addr and MAP_FIXED to develop our heuristic can > > > never really give unchanged ABI. It's an in-band signal. brk() is a > > > good example that

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 12:15 PM, Kirill A. Shutemov wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk() is a good example that steadily keeps incrementing address, so depending on malloc usage and address space

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, Nov 07, 2017 at 09:15:21AM +0100, Florian Weimer wrote: > MAP_FIXED is near-impossible to use correctly. I hope you don't expect > applications to do that. If you want address-based opt in, it should work > without MAP_FIXED. Sure, in obscure cases, applications might still see >

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, Nov 07, 2017 at 04:07:05PM +1100, Nicholas Piggin wrote: > C'ing everyone who was on the x86 56-bit user virtual address patch. > > I think we need more time to discuss this behaviour, in light of the > regression Florian uncovered. I would propose we turn off the 56-bit > user virtual

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Tue, 7 Nov 2017 09:15:21 +0100 Florian Weimer wrote: > On 11/07/2017 06:07 AM, Nicholas Piggin wrote: > > > First of all, using addr and MAP_FIXED to develop our heuristic can > > never really give unchanged ABI. It's an in-band signal. brk() is a > > good example that

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/07/2017 06:07 AM, Nicholas Piggin wrote: First of all, using addr and MAP_FIXED to develop our heuristic can never really give unchanged ABI. It's an in-band signal. brk() is a good example that steadily keeps incrementing address, so depending on malloc usage and address space

Re: POWER: Unexpected fault when writing to brk-allocated memory

C'ing everyone who was on the x86 56-bit user virtual address patch. I think we need more time to discuss this behaviour, in light of the regression Florian uncovered. I would propose we turn off the 56-bit user virtual address support for x86 for 4.14, and powerpc would follow and turn off its

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Mon, 6 Nov 2017 09:32:25 +0100 Florian Weimer wrote: > On 11/06/2017 09:30 AM, Aneesh Kumar K.V wrote: > > On 11/06/2017 01:55 PM, Nicholas Piggin wrote: > >> On Mon, 6 Nov 2017 09:11:37 +0100 > >> Florian Weimer wrote: > >> > >>> On 11/06/2017

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 09:30 AM, Aneesh Kumar K.V wrote: On 11/06/2017 01:55 PM, Nicholas Piggin wrote: On Mon, 6 Nov 2017 09:11:37 +0100 Florian Weimer wrote: On 11/06/2017 07:47 AM, Nicholas Piggin wrote: "You get < 128TB unless explicitly requested." Simple, reasonable,

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 01:55 PM, Nicholas Piggin wrote: On Mon, 6 Nov 2017 09:11:37 +0100 Florian Weimer wrote: On 11/06/2017 07:47 AM, Nicholas Piggin wrote: "You get < 128TB unless explicitly requested." Simple, reasonable, obvious rule. Avoids breaking apps that store some

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Mon, 6 Nov 2017 09:11:37 +0100 Florian Weimer wrote: > On 11/06/2017 07:47 AM, Nicholas Piggin wrote: > > "You get < 128TB unless explicitly requested." > > > > Simple, reasonable, obvious rule. Avoids breaking apps that store > > some bits in the top of pointers

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 07:47 AM, Nicholas Piggin wrote: "You get < 128TB unless explicitly requested." Simple, reasonable, obvious rule. Avoids breaking apps that store some bits in the top of pointers (provided that memory allocator userspace libraries also do the right thing). So brk would simplify

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/06/2017 07:18 AM, Aneesh Kumar K.V wrote: We should not return that address, unless we requested with a hint value of > 128TB. IIRC we discussed this early during the mmap interface change and said, we will return an address > 128T only if the hint address is above 128TB (not hint addr +

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Mon, 06 Nov 2017 11:48:06 +0530 "Aneesh Kumar K.V" wrote: > Nicholas Piggin writes: > > > On Fri, 3 Nov 2017 18:05:20 +0100 > > Florian Weimer wrote: > > > >> We are seeing an issue on ppc64le and ppc64 (and perhaps

Re: POWER: Unexpected fault when writing to brk-allocated memory

Nicholas Piggin writes: > On Fri, 3 Nov 2017 18:05:20 +0100 > Florian Weimer wrote: > >> We are seeing an issue on ppc64le and ppc64 (and perhaps on some arm >> variant, but I have not seen it on our own builders) where running >> localedef as part of

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/05/2017 01:18 PM, Nicholas Piggin wrote: Something like the following patch may help if you could test. The patch appears to fix it: # /lib64/ld64.so.1 ./a.out initial brk value: 0x7fffe459 probing at 0x8001fffc I used the follow simplified reproducer: #include #include

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Sun, 5 Nov 2017 13:35:40 +0100 Florian Weimer wrote: > On 11/05/2017 01:18 PM, Nicholas Piggin wrote: > > > There was a recent change to move to 128TB address space by default, > > and option for 512TB addresses if explicitly requested. > > Do you have a commit hash

Re: POWER: Unexpected fault when writing to brk-allocated memory

On 11/05/2017 01:18 PM, Nicholas Piggin wrote: There was a recent change to move to 128TB address space by default, and option for 512TB addresses if explicitly requested. Do you have a commit hash for the introduction of 128TB by default? Thanks. Your brk request asked for > 128TB which

Re: POWER: Unexpected fault when writing to brk-allocated memory

On Fri, 3 Nov 2017 18:05:20 +0100 Florian Weimer wrote: > We are seeing an issue on ppc64le and ppc64 (and perhaps on some arm > variant, but I have not seen it on our own builders) where running > localedef as part of the glibc build crashes with a segmentation fault. > >