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
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
22 matches
Mail list logo
