On Mon, 30 Mar 2015, KOSAKI Motohiro wrote:
> On Thu, Mar 26, 2015 at 10:08 AM, Eric B Munson wrote:
> > On 03/26/2015 07:56 AM, Davide Libenzi wrote:
> >> On Wed, 25 Mar 2015, David Rientjes wrote:
> >>
> >>> I looked at this thread at http://marc.info/?t=14139250881
> >>> since I didn't
On Thu, Mar 26, 2015 at 10:08 AM, Eric B Munson wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/26/2015 07:56 AM, Davide Libenzi wrote:
>> On Wed, 25 Mar 2015, David Rientjes wrote:
>>
>>> I looked at this thread at http://marc.info/?t=14139250881
>>> since I didn't have it
On Mon, 30 Mar 2015, KOSAKI Motohiro wrote:
On Thu, Mar 26, 2015 at 10:08 AM, Eric B Munson emun...@akamai.com wrote:
On 03/26/2015 07:56 AM, Davide Libenzi wrote:
On Wed, 25 Mar 2015, David Rientjes wrote:
I looked at this thread at http://marc.info/?t=14139250881
since I didn't
On Thu, Mar 26, 2015 at 10:08 AM, Eric B Munson emun...@akamai.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/26/2015 07:56 AM, Davide Libenzi wrote:
On Wed, 25 Mar 2015, David Rientjes wrote:
I looked at this thread at http://marc.info/?t=14139250881
since I didn't
On Thu, 26 Mar 2015, David Rientjes wrote:
> On Thu, 26 Mar 2015, Davide Libenzi wrote:
>
> > > Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
> > > hugetlb vma is long standing and there may be applications that break as
> > > a
> > > result of changing the
Might be too late in this thread, but in case you are going to continue and/or
repost:
[CC += linux-...@vger.kernel.org]
(also linux-man and Michael to match my other reply)
Since this is a kernel-user-space API change, please CC linux-api@. The
kernel source file
On 03/26/2015 08:39 PM, Davide Libenzi wrote:
> On Thu, 26 Mar 2015, David Rientjes wrote:
>
>> Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
>> hugetlb vma is long standing and there may be applications that break as a
>> result of changing the behavior: a database
On 03/26/2015 08:39 PM, Davide Libenzi wrote:
On Thu, 26 Mar 2015, David Rientjes wrote:
Yes, this munmap() behavior of lengths = hugepage_size - PAGE_SIZE for a
hugetlb vma is long standing and there may be applications that break as a
result of changing the behavior: a database that
Might be too late in this thread, but in case you are going to continue and/or
repost:
[CC += linux-...@vger.kernel.org]
(also linux-man and Michael to match my other reply)
Since this is a kernel-user-space API change, please CC linux-api@. The
kernel source file
On Thu, 26 Mar 2015, David Rientjes wrote:
On Thu, 26 Mar 2015, Davide Libenzi wrote:
Yes, this munmap() behavior of lengths = hugepage_size - PAGE_SIZE for a
hugetlb vma is long standing and there may be applications that break as
a
result of changing the behavior: a database
On Thu, 26 Mar 2015, Davide Libenzi wrote:
> > Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
> > hugetlb vma is long standing and there may be applications that break as a
> > result of changing the behavior: a database that reserves all allocated
> > hugetlb memory
On Thu, 26 Mar 2015, David Rientjes wrote:
> Yes, this munmap() behavior of lengths <= hugepage_size - PAGE_SIZE for a
> hugetlb vma is long standing and there may be applications that break as a
> result of changing the behavior: a database that reserves all allocated
> hugetlb memory with
On Thu, 26 Mar 2015, Davide Libenzi wrote:
> > I looked at this thread at http://marc.info/?t=14139250881 since I
> > didn't have it in my mailbox, and I didn't get a chance to actually run
> > your test code.
> >
> > In short, I think what you're saying is that
> >
> > ptr =
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/26/2015 07:56 AM, Davide Libenzi wrote:
> On Wed, 25 Mar 2015, David Rientjes wrote:
>
>> I looked at this thread at http://marc.info/?t=14139250881
>> since I didn't have it in my mailbox, and I didn't get a chance
>> to actually run your
On Wed, 25 Mar 2015, David Rientjes wrote:
> I looked at this thread at http://marc.info/?t=14139250881 since I
> didn't have it in my mailbox, and I didn't get a chance to actually run
> your test code.
>
> In short, I think what you're saying is that
>
> ptr = mmap(..., 4KB, ...,
On Wed, 25 Mar 2015, David Rientjes wrote:
I looked at this thread at http://marc.info/?t=14139250881 since I
didn't have it in my mailbox, and I didn't get a chance to actually run
your test code.
In short, I think what you're saying is that
ptr = mmap(..., 4KB, ...,
On Thu, 26 Mar 2015, Davide Libenzi wrote:
Yes, this munmap() behavior of lengths = hugepage_size - PAGE_SIZE for a
hugetlb vma is long standing and there may be applications that break as a
result of changing the behavior: a database that reserves all allocated
hugetlb memory with
On Thu, 26 Mar 2015, Davide Libenzi wrote:
I looked at this thread at http://marc.info/?t=14139250881 since I
didn't have it in my mailbox, and I didn't get a chance to actually run
your test code.
In short, I think what you're saying is that
ptr = mmap(..., 4KB, ...,
On Thu, 26 Mar 2015, David Rientjes wrote:
Yes, this munmap() behavior of lengths = hugepage_size - PAGE_SIZE for a
hugetlb vma is long standing and there may be applications that break as a
result of changing the behavior: a database that reserves all allocated
hugetlb memory with mmap()
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/26/2015 07:56 AM, Davide Libenzi wrote:
On Wed, 25 Mar 2015, David Rientjes wrote:
I looked at this thread at http://marc.info/?t=14139250881
since I didn't have it in my mailbox, and I didn't get a chance
to actually run your test
On Wed, 25 Mar 2015, Davide Libenzi wrote:
> > When you say "tracking back to 3.2.x", I think you mean you've tried as
> > far back as 3.2.x and found the same behaviour, but not tried further?
> >
> > From the source, it looks like this is unchanged since MAP_HUGETLB was
> > introduced in
On Wed, 25 Mar 2015, Hugh Dickins wrote:
> When you say "tracking back to 3.2.x", I think you mean you've tried as
> far back as 3.2.x and found the same behaviour, but not tried further?
>
> From the source, it looks like this is unchanged since MAP_HUGETLB was
> introduced in 2.6.32. And is
On Wed, 22 Oct 2014, Davide Libenzi wrote:
> [Resending with proper CC list suggested by Andrew]
I have recently been reminded of this languishing in my inbox ;)
(along with many others that I won't get to answer so quickly).
And in turn it reminds me of an older from Joern, who was annoyed
On Wed, 25 Mar 2015, Hugh Dickins wrote:
When you say tracking back to 3.2.x, I think you mean you've tried as
far back as 3.2.x and found the same behaviour, but not tried further?
From the source, it looks like this is unchanged since MAP_HUGETLB was
introduced in 2.6.32. And is the same
On Wed, 22 Oct 2014, Davide Libenzi wrote:
[Resending with proper CC list suggested by Andrew]
I have recently been reminded of this languishing in my inbox ;)
(along with many others that I won't get to answer so quickly).
And in turn it reminds me of an older from Joern, who was annoyed
that
On Wed, 25 Mar 2015, Davide Libenzi wrote:
When you say tracking back to 3.2.x, I think you mean you've tried as
far back as 3.2.x and found the same behaviour, but not tried further?
From the source, it looks like this is unchanged since MAP_HUGETLB was
introduced in 2.6.32. And is
[Resending with proper CC list suggested by Andrew]
Calling munmap on a MAP_HUGETLB area, and a size which is not 2MB aligned,
causes munmap to fail. Tested on 3.13.x but tracking back to 3.2.x.
In do_munmap() we forcibly want a 4KB default page, and we wrongly
calculate the end of the map.
[Resending with proper CC list suggested by Andrew]
Calling munmap on a MAP_HUGETLB area, and a size which is not 2MB aligned,
causes munmap to fail. Tested on 3.13.x but tracking back to 3.2.x.
In do_munmap() we forcibly want a 4KB default page, and we wrongly
calculate the end of the map.
28 matches
Mail list logo
