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
> > > guaranteed of getting a
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 inten
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 for
> > itself? Is in
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 is
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 change to the
> > > int
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 ways for using the new functional
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 12:15 PM, Kirill A. Sh
"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:
>> > >
>> > > > > Firs
"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 man page? I couldn't fix powerpc b
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
> > suitab
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 an
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 point about brk is not
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
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. brk()
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 all
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 of the
> > regression Fl
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 steadily
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 randomiz
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
> out-of-
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 add
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 steadily keeps incremen
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 randomizati
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 51
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 07:47 AM, Nicholas Piggin wrote:
> "Y
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, obvious rule. Avoids break
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 bits in the top of poi
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 (provided that memory allocat
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 f
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 + le
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 on some arm
> >> variant, but I have not seen it on our own builders) wh
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 the glibc build crashes with a segmentatio
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
#incl
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 for the introduction of
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 th
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.
>
> Kernel version is 4.
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.
Kernel version is 4.13.9 (Fedora 26 variant).
I have only seen this with an explicit l
36 matches
Mail list logo
