* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-13 16:57 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-13 16:57 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> >
> > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > userspace explicitly asked for it.
> > >
> > > Userspace can ask for allocation from full address space by specifying
> > > hint address above 47-bit.
> > >
> > > Nicholas noticed that current implementation violates this interface:
> > > we can get vma partly in high addresses if we ask for a mapping at very
> > > end of 47-bit address space.
> > >
> > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > border.
> >
> > What happens for mappings with MAP_FIXED which cross the border?
>
> It will succeed with 5-level paging.
And why is this allowed?
> It should be safe as with 4-level paging such request would fail and it's
> reasonable to expect that userspace is not relying on the failure to
> function properly.
Huch?
The first rule when looking at user space is that is broken or
hostile. Reasonable and user space are mutually exclusive.
Thanks,
tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
2017-11-13 16:57 ` Thomas Gleixner
@ 2017-11-13 19:14 ` Thomas Gleixner
-1 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-13 19:14 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, 13 Nov 2017, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
>
> > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > >
> > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > userspace explicitly asked for it.
> > > >
> > > > Userspace can ask for allocation from full address space by specifying
> > > > hint address above 47-bit.
> > > >
> > > > Nicholas noticed that current implementation violates this interface:
> > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > end of 47-bit address space.
> > > >
> > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > border.
> > >
> > > What happens for mappings with MAP_FIXED which cross the border?
> >
> > It will succeed with 5-level paging.
>
> And why is this allowed?
>
> > It should be safe as with 4-level paging such request would fail and it's
> > reasonable to expect that userspace is not relying on the failure to
> > function properly.
>
> Huch?
>
> The first rule when looking at user space is that is broken or
> hostile. Reasonable and user space are mutually exclusive.
Aside of that in case of get_unmapped_area:
If va_unmapped_area() fails, then the address and the len which caused the
overlap check to trigger are handed in to arch_get_unmapped_area(), which
again can create an invalid mapping if I'm not missing something.
If mappings which overlap the boundary are invalid then we have to make
sure at all ends that they wont happen.
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-13 19:14 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-13 19:14 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, 13 Nov 2017, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
>
> > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > >
> > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > userspace explicitly asked for it.
> > > >
> > > > Userspace can ask for allocation from full address space by specifying
> > > > hint address above 47-bit.
> > > >
> > > > Nicholas noticed that current implementation violates this interface:
> > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > end of 47-bit address space.
> > > >
> > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > border.
> > >
> > > What happens for mappings with MAP_FIXED which cross the border?
> >
> > It will succeed with 5-level paging.
>
> And why is this allowed?
>
> > It should be safe as with 4-level paging such request would fail and it's
> > reasonable to expect that userspace is not relying on the failure to
> > function properly.
>
> Huch?
>
> The first rule when looking at user space is that is broken or
> hostile. Reasonable and user space are mutually exclusive.
Aside of that in case of get_unmapped_area:
If va_unmapped_area() fails, then the address and the len which caused the
overlap check to trigger are handed in to arch_get_unmapped_area(), which
again can create an invalid mapping if I'm not missing something.
If mappings which overlap the boundary are invalid then we have to make
sure at all ends that they wont happen.
Thanks,
tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
2017-11-13 19:14 ` Thomas Gleixner
@ 2017-11-13 20:06 ` Kirill A. Shutemov
-1 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2017-11-13 20:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Thomas Gleixner wrote:
> > On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> >
> > > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > > >
> > > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > > userspace explicitly asked for it.
> > > > >
> > > > > Userspace can ask for allocation from full address space by specifying
> > > > > hint address above 47-bit.
> > > > >
> > > > > Nicholas noticed that current implementation violates this interface:
> > > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > > end of 47-bit address space.
> > > > >
> > > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > > border.
> > > >
> > > > What happens for mappings with MAP_FIXED which cross the border?
> > >
> > > It will succeed with 5-level paging.
> >
> > And why is this allowed?
> >
> > > It should be safe as with 4-level paging such request would fail and it's
> > > reasonable to expect that userspace is not relying on the failure to
> > > function properly.
> >
> > Huch?
> >
> > The first rule when looking at user space is that is broken or
> > hostile. Reasonable and user space are mutually exclusive.
>
> Aside of that in case of get_unmapped_area:
>
> If va_unmapped_area() fails, then the address and the len which caused the
> overlap check to trigger are handed in to arch_get_unmapped_area(), which
> again can create an invalid mapping if I'm not missing something.
>
> If mappings which overlap the boundary are invalid then we have to make
> sure at all ends that they wont happen.
They are not invalid.
The patch tries to address following theoretical issue:
We have an application that tries, for some reason, to allocate memory
with mmap(addr), without MAP_FIXED, where addr is near the borderline of
47-bit address space and addr+len is above the border.
On 4-level paging machine this request would succeed, but the address will
always be within 47-bit VA -- cannot allocate by hint address, ignore it.
If the application cannot handle high address this might be an issue on
5-level paging machine as such call would succeed *and* allocate memory by
the specified hint address. In this case part of the mapping would be
above the border line and may lead to misbehaviour.
I hope this makes any sense :)
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-13 20:06 ` Kirill A. Shutemov
0 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2017-11-13 20:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Thomas Gleixner wrote:
> > On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> >
> > > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > > >
> > > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > > userspace explicitly asked for it.
> > > > >
> > > > > Userspace can ask for allocation from full address space by specifying
> > > > > hint address above 47-bit.
> > > > >
> > > > > Nicholas noticed that current implementation violates this interface:
> > > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > > end of 47-bit address space.
> > > > >
> > > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > > border.
> > > >
> > > > What happens for mappings with MAP_FIXED which cross the border?
> > >
> > > It will succeed with 5-level paging.
> >
> > And why is this allowed?
> >
> > > It should be safe as with 4-level paging such request would fail and it's
> > > reasonable to expect that userspace is not relying on the failure to
> > > function properly.
> >
> > Huch?
> >
> > The first rule when looking at user space is that is broken or
> > hostile. Reasonable and user space are mutually exclusive.
>
> Aside of that in case of get_unmapped_area:
>
> If va_unmapped_area() fails, then the address and the len which caused the
> overlap check to trigger are handed in to arch_get_unmapped_area(), which
> again can create an invalid mapping if I'm not missing something.
>
> If mappings which overlap the boundary are invalid then we have to make
> sure at all ends that they wont happen.
They are not invalid.
The patch tries to address following theoretical issue:
We have an application that tries, for some reason, to allocate memory
with mmap(addr), without MAP_FIXED, where addr is near the borderline of
47-bit address space and addr+len is above the border.
On 4-level paging machine this request would succeed, but the address will
always be within 47-bit VA -- cannot allocate by hint address, ignore it.
If the application cannot handle high address this might be an issue on
5-level paging machine as such call would succeed *and* allocate memory by
the specified hint address. In this case part of the mapping would be
above the border line and may lead to misbehaviour.
I hope this makes any sense :)
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
2017-11-13 20:06 ` Kirill A. Shutemov
@ 2017-11-13 21:14 ` Thomas Gleixner
-1 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-13 21:14 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> > > > It will succeed with 5-level paging.
> > >
> > > And why is this allowed?
> > >
> > > > It should be safe as with 4-level paging such request would fail and it's
> > > > reasonable to expect that userspace is not relying on the failure to
> > > > function properly.
> > >
> > > Huch?
> > >
> > > The first rule when looking at user space is that is broken or
> > > hostile. Reasonable and user space are mutually exclusive.
> >
> > Aside of that in case of get_unmapped_area:
> >
> > If va_unmapped_area() fails, then the address and the len which caused the
> > overlap check to trigger are handed in to arch_get_unmapped_area(), which
> > again can create an invalid mapping if I'm not missing something.
> >
> > If mappings which overlap the boundary are invalid then we have to make
> > sure at all ends that they wont happen.
>
> They are not invalid.
>
> The patch tries to address following theoretical issue:
>
> We have an application that tries, for some reason, to allocate memory
> with mmap(addr), without MAP_FIXED, where addr is near the borderline of
> 47-bit address space and addr+len is above the border.
>
> On 4-level paging machine this request would succeed, but the address will
> always be within 47-bit VA -- cannot allocate by hint address, ignore it.
>
> If the application cannot handle high address this might be an issue on
> 5-level paging machine as such call would succeed *and* allocate memory by
> the specified hint address. In this case part of the mapping would be
> above the border line and may lead to misbehaviour.
>
> I hope this makes any sense :)
I can see where you are heading to. Now the case I was looking at is:
arch_get_unmapped_area_topdown()
addr0 = addr;
....
if (addr) {
if (cross_border(addr, len))
goto get_unmapped_area;
...
}
get_unmapped_area:
...
if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
addr - vm_unmapped_area(&info);
^^^ fails for whatever reason.
bottomup:
return arch_get_unmapped_area(.., addr0, len, ....);
AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-13 21:14 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-13 21:14 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> > > > It will succeed with 5-level paging.
> > >
> > > And why is this allowed?
> > >
> > > > It should be safe as with 4-level paging such request would fail and it's
> > > > reasonable to expect that userspace is not relying on the failure to
> > > > function properly.
> > >
> > > Huch?
> > >
> > > The first rule when looking at user space is that is broken or
> > > hostile. Reasonable and user space are mutually exclusive.
> >
> > Aside of that in case of get_unmapped_area:
> >
> > If va_unmapped_area() fails, then the address and the len which caused the
> > overlap check to trigger are handed in to arch_get_unmapped_area(), which
> > again can create an invalid mapping if I'm not missing something.
> >
> > If mappings which overlap the boundary are invalid then we have to make
> > sure at all ends that they wont happen.
>
> They are not invalid.
>
> The patch tries to address following theoretical issue:
>
> We have an application that tries, for some reason, to allocate memory
> with mmap(addr), without MAP_FIXED, where addr is near the borderline of
> 47-bit address space and addr+len is above the border.
>
> On 4-level paging machine this request would succeed, but the address will
> always be within 47-bit VA -- cannot allocate by hint address, ignore it.
>
> If the application cannot handle high address this might be an issue on
> 5-level paging machine as such call would succeed *and* allocate memory by
> the specified hint address. In this case part of the mapping would be
> above the border line and may lead to misbehaviour.
>
> I hope this makes any sense :)
I can see where you are heading to. Now the case I was looking at is:
arch_get_unmapped_area_topdown()
addr0 = addr;
....
if (addr) {
if (cross_border(addr, len))
goto get_unmapped_area;
...
}
get_unmapped_area:
...
if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
addr - vm_unmapped_area(&info);
^^^ fails for whatever reason.
bottomup:
return arch_get_unmapped_area(.., addr0, len, ....);
AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.
Thanks,
tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
2017-11-13 21:14 ` Thomas Gleixner
@ 2017-11-14 12:05 ` Kirill A. Shutemov
-1 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2017-11-14 12:05 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, Nov 13, 2017 at 10:14:36PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> > On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> > > > > It will succeed with 5-level paging.
> > > >
> > > > And why is this allowed?
> > > >
> > > > > It should be safe as with 4-level paging such request would fail and it's
> > > > > reasonable to expect that userspace is not relying on the failure to
> > > > > function properly.
> > > >
> > > > Huch?
> > > >
> > > > The first rule when looking at user space is that is broken or
> > > > hostile. Reasonable and user space are mutually exclusive.
> > >
> > > Aside of that in case of get_unmapped_area:
> > >
> > > If va_unmapped_area() fails, then the address and the len which caused the
> > > overlap check to trigger are handed in to arch_get_unmapped_area(), which
> > > again can create an invalid mapping if I'm not missing something.
> > >
> > > If mappings which overlap the boundary are invalid then we have to make
> > > sure at all ends that they wont happen.
> >
> > They are not invalid.
> >
> > The patch tries to address following theoretical issue:
> >
> > We have an application that tries, for some reason, to allocate memory
> > with mmap(addr), without MAP_FIXED, where addr is near the borderline of
> > 47-bit address space and addr+len is above the border.
> >
> > On 4-level paging machine this request would succeed, but the address will
> > always be within 47-bit VA -- cannot allocate by hint address, ignore it.
> >
> > If the application cannot handle high address this might be an issue on
> > 5-level paging machine as such call would succeed *and* allocate memory by
> > the specified hint address. In this case part of the mapping would be
> > above the border line and may lead to misbehaviour.
> >
> > I hope this makes any sense :)
>
> I can see where you are heading to. Now the case I was looking at is:
>
> arch_get_unmapped_area_topdown()
>
> addr0 = addr;
>
> ....
> if (addr) {
> if (cross_border(addr, len))
> goto get_unmapped_area;
> ...
> }
> get_unmapped_area:
> ...
> if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
>
> ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
>
> addr - vm_unmapped_area(&info);
>
> ^^^ fails for whatever reason.
>
> bottomup:
> return arch_get_unmapped_area(.., addr0, len, ....);
>
>
> AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
> border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.
No, it can't as long as addr0 is below DEFAULT_MAP_WINDOW:
arch_get_unmapped_area()
{
...
find_start_end(addr, flags, &begin, &end);
// end is DEFAULT_MAP_WINDOW here, since addr is below the border
...
if (addr) {
...
// end - len is less than addr, so the condition below is
// false.
if (end - len >= addr &&
(!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
...
info.high_limit = end;
...
return vm_unmapped_area(&info);
}
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-14 12:05 ` Kirill A. Shutemov
0 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2017-11-14 12:05 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, Nov 13, 2017 at 10:14:36PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> > On Mon, Nov 13, 2017 at 08:14:54PM +0100, Thomas Gleixner wrote:
> > > > > It will succeed with 5-level paging.
> > > >
> > > > And why is this allowed?
> > > >
> > > > > It should be safe as with 4-level paging such request would fail and it's
> > > > > reasonable to expect that userspace is not relying on the failure to
> > > > > function properly.
> > > >
> > > > Huch?
> > > >
> > > > The first rule when looking at user space is that is broken or
> > > > hostile. Reasonable and user space are mutually exclusive.
> > >
> > > Aside of that in case of get_unmapped_area:
> > >
> > > If va_unmapped_area() fails, then the address and the len which caused the
> > > overlap check to trigger are handed in to arch_get_unmapped_area(), which
> > > again can create an invalid mapping if I'm not missing something.
> > >
> > > If mappings which overlap the boundary are invalid then we have to make
> > > sure at all ends that they wont happen.
> >
> > They are not invalid.
> >
> > The patch tries to address following theoretical issue:
> >
> > We have an application that tries, for some reason, to allocate memory
> > with mmap(addr), without MAP_FIXED, where addr is near the borderline of
> > 47-bit address space and addr+len is above the border.
> >
> > On 4-level paging machine this request would succeed, but the address will
> > always be within 47-bit VA -- cannot allocate by hint address, ignore it.
> >
> > If the application cannot handle high address this might be an issue on
> > 5-level paging machine as such call would succeed *and* allocate memory by
> > the specified hint address. In this case part of the mapping would be
> > above the border line and may lead to misbehaviour.
> >
> > I hope this makes any sense :)
>
> I can see where you are heading to. Now the case I was looking at is:
>
> arch_get_unmapped_area_topdown()
>
> addr0 = addr;
>
> ....
> if (addr) {
> if (cross_border(addr, len))
> goto get_unmapped_area;
> ...
> }
> get_unmapped_area:
> ...
> if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
>
> ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
>
> addr - vm_unmapped_area(&info);
>
> ^^^ fails for whatever reason.
>
> bottomup:
> return arch_get_unmapped_area(.., addr0, len, ....);
>
>
> AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
> border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.
No, it can't as long as addr0 is below DEFAULT_MAP_WINDOW:
arch_get_unmapped_area()
{
...
find_start_end(addr, flags, &begin, &end);
// end is DEFAULT_MAP_WINDOW here, since addr is below the border
...
if (addr) {
...
// end - len is less than addr, so the condition below is
// false.
if (end - len >= addr &&
(!vma || addr + len <= vm_start_gap(vma)))
return addr;
}
...
info.high_limit = end;
...
return vm_unmapped_area(&info);
}
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
2017-11-14 12:05 ` Kirill A. Shutemov
@ 2017-11-14 12:11 ` Thomas Gleixner
-1 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-14 12:11 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Tue, 14 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 10:14:36PM +0100, Thomas Gleixner wrote:
> > I can see where you are heading to. Now the case I was looking at is:
> >
> > arch_get_unmapped_area_topdown()
> >
> > addr0 = addr;
> >
> > ....
> > if (addr) {
> > if (cross_border(addr, len))
> > goto get_unmapped_area;
> > ...
> > }
> > get_unmapped_area:
> > ...
> > if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
> >
> > ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
> >
> > addr - vm_unmapped_area(&info);
> >
> > ^^^ fails for whatever reason.
> >
> > bottomup:
> > return arch_get_unmapped_area(.., addr0, len, ....);
> >
> >
> > AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
> > border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.
>
> No, it can't as long as addr0 is below DEFAULT_MAP_WINDOW:
>
> arch_get_unmapped_area()
> {
> ...
> find_start_end(addr, flags, &begin, &end);
> // end is DEFAULT_MAP_WINDOW here, since addr is below the border
Sigh, I missed that task_size_64bit() magic in find_start_end().
This is really convoluted and non intuitive. I'm so not looking forward to
debug any failure in that context.
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-14 12:11 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-14 12:11 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Tue, 14 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 10:14:36PM +0100, Thomas Gleixner wrote:
> > I can see where you are heading to. Now the case I was looking at is:
> >
> > arch_get_unmapped_area_topdown()
> >
> > addr0 = addr;
> >
> > ....
> > if (addr) {
> > if (cross_border(addr, len))
> > goto get_unmapped_area;
> > ...
> > }
> > get_unmapped_area:
> > ...
> > if (addr > DEFAULT_MAP_WINDOW && !in_compat_syscall())
> >
> > ^^^ evaluates to false because addr < DEFAULT_MAP_WINDOW
> >
> > addr - vm_unmapped_area(&info);
> >
> > ^^^ fails for whatever reason.
> >
> > bottomup:
> > return arch_get_unmapped_area(.., addr0, len, ....);
> >
> >
> > AFAICT arch_get_unmapped_area() can allocate a mapping which crosses the
> > border, i.e. a mapping which you want to prevent for the !MAP_FIXED case.
>
> No, it can't as long as addr0 is below DEFAULT_MAP_WINDOW:
>
> arch_get_unmapped_area()
> {
> ...
> find_start_end(addr, flags, &begin, &end);
> // end is DEFAULT_MAP_WINDOW here, since addr is below the border
Sigh, I missed that task_size_64bit() magic in find_start_end().
This is really convoluted and non intuitive. I'm so not looking forward to
debug any failure in that context.
Thanks,
tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
2017-11-13 16:57 ` Thomas Gleixner
@ 2017-11-13 20:00 ` Kirill A. Shutemov
-1 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2017-11-13 20:00 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, Nov 13, 2017 at 05:57:03PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
>
> > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > >
> > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > userspace explicitly asked for it.
> > > >
> > > > Userspace can ask for allocation from full address space by specifying
> > > > hint address above 47-bit.
> > > >
> > > > Nicholas noticed that current implementation violates this interface:
> > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > end of 47-bit address space.
> > > >
> > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > border.
> > >
> > > What happens for mappings with MAP_FIXED which cross the border?
> >
> > It will succeed with 5-level paging.
>
> And why is this allowed?
>
> > It should be safe as with 4-level paging such request would fail and it's
> > reasonable to expect that userspace is not relying on the failure to
> > function properly.
>
> Huch?
>
> The first rule when looking at user space is that is broken or
> hostile. Reasonable and user space are mutually exclusive.
That's basically the same assumption we made to implement current
interface of allocation memory above 47-bits.
The premise is that nobody in right mind would try mmap(addr, MAP_FIXED)
where addr >= (1UL << 47) as it will always fail. So we can allow this to
succeed on 5-level paging machine as a way to allocate from larger address
space.
By the same logic we can allow allocation for cases where addr is below
(1UL << 47), but addr+size is above the limit.
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-13 20:00 ` Kirill A. Shutemov
0 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2017-11-13 20:00 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, Nov 13, 2017 at 05:57:03PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
>
> > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > >
> > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > userspace explicitly asked for it.
> > > >
> > > > Userspace can ask for allocation from full address space by specifying
> > > > hint address above 47-bit.
> > > >
> > > > Nicholas noticed that current implementation violates this interface:
> > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > end of 47-bit address space.
> > > >
> > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > border.
> > >
> > > What happens for mappings with MAP_FIXED which cross the border?
> >
> > It will succeed with 5-level paging.
>
> And why is this allowed?
>
> > It should be safe as with 4-level paging such request would fail and it's
> > reasonable to expect that userspace is not relying on the failure to
> > function properly.
>
> Huch?
>
> The first rule when looking at user space is that is broken or
> hostile. Reasonable and user space are mutually exclusive.
That's basically the same assumption we made to implement current
interface of allocation memory above 47-bits.
The premise is that nobody in right mind would try mmap(addr, MAP_FIXED)
where addr >= (1UL << 47) as it will always fail. So we can allow this to
succeed on 5-level paging machine as a way to allocate from larger address
space.
By the same logic we can allow allocation for cases where addr is below
(1UL << 47), but addr+size is above the limit.
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
2017-11-13 20:00 ` Kirill A. Shutemov
@ 2017-11-13 21:17 ` Thomas Gleixner
-1 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-13 21:17 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 05:57:03PM +0100, Thomas Gleixner wrote:
> > On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> >
> > > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > > >
> > > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > > userspace explicitly asked for it.
> > > > >
> > > > > Userspace can ask for allocation from full address space by specifying
> > > > > hint address above 47-bit.
> > > > >
> > > > > Nicholas noticed that current implementation violates this interface:
> > > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > > end of 47-bit address space.
> > > > >
> > > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > > border.
> > > >
> > > > What happens for mappings with MAP_FIXED which cross the border?
> > >
> > > It will succeed with 5-level paging.
> >
> > And why is this allowed?
> >
> > > It should be safe as with 4-level paging such request would fail and it's
> > > reasonable to expect that userspace is not relying on the failure to
> > > function properly.
> >
> > Huch?
> >
> > The first rule when looking at user space is that is broken or
> > hostile. Reasonable and user space are mutually exclusive.
>
> That's basically the same assumption we made to implement current
> interface of allocation memory above 47-bits.
>
> The premise is that nobody in right mind would try mmap(addr, MAP_FIXED)
> where addr >= (1UL << 47) as it will always fail. So we can allow this to
> succeed on 5-level paging machine as a way to allocate from larger address
> space.
>
> By the same logic we can allow allocation for cases where addr is below
> (1UL << 47), but addr+size is above the limit.
Makes some sense, but it would be nice to have this documented exactly in
arch_get_unmapped_area_topdown(), i.e. the function where you are adding
the border check to. Otherwise 3 month from now somebody will look at that
and ask exactly the same question again.
Thanks,
tglx
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-13 21:17 ` Thomas Gleixner
0 siblings, 0 replies; 24+ messages in thread
From: Thomas Gleixner @ 2017-11-13 21:17 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> On Mon, Nov 13, 2017 at 05:57:03PM +0100, Thomas Gleixner wrote:
> > On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> >
> > > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > > >
> > > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > > userspace explicitly asked for it.
> > > > >
> > > > > Userspace can ask for allocation from full address space by specifying
> > > > > hint address above 47-bit.
> > > > >
> > > > > Nicholas noticed that current implementation violates this interface:
> > > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > > end of 47-bit address space.
> > > > >
> > > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > > border.
> > > >
> > > > What happens for mappings with MAP_FIXED which cross the border?
> > >
> > > It will succeed with 5-level paging.
> >
> > And why is this allowed?
> >
> > > It should be safe as with 4-level paging such request would fail and it's
> > > reasonable to expect that userspace is not relying on the failure to
> > > function properly.
> >
> > Huch?
> >
> > The first rule when looking at user space is that is broken or
> > hostile. Reasonable and user space are mutually exclusive.
>
> That's basically the same assumption we made to implement current
> interface of allocation memory above 47-bits.
>
> The premise is that nobody in right mind would try mmap(addr, MAP_FIXED)
> where addr >= (1UL << 47) as it will always fail. So we can allow this to
> succeed on 5-level paging machine as a way to allocate from larger address
> space.
>
> By the same logic we can allow allocation for cases where addr is below
> (1UL << 47), but addr+size is above the limit.
Makes some sense, but it would be nice to have this documented exactly in
arch_get_unmapped_area_topdown(), i.e. the function where you are adding
the border check to. Otherwise 3 month from now somebody will look at that
and ask exactly the same question again.
Thanks,
tglx
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
2017-11-13 21:17 ` Thomas Gleixner
@ 2017-11-14 12:06 ` Kirill A. Shutemov
-1 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2017-11-14 12:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, Nov 13, 2017 at 10:17:30PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> > On Mon, Nov 13, 2017 at 05:57:03PM +0100, Thomas Gleixner wrote:
> > > On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> > >
> > > > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > > > >
> > > > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > > > userspace explicitly asked for it.
> > > > > >
> > > > > > Userspace can ask for allocation from full address space by specifying
> > > > > > hint address above 47-bit.
> > > > > >
> > > > > > Nicholas noticed that current implementation violates this interface:
> > > > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > > > end of 47-bit address space.
> > > > > >
> > > > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > > > border.
> > > > >
> > > > > What happens for mappings with MAP_FIXED which cross the border?
> > > >
> > > > It will succeed with 5-level paging.
> > >
> > > And why is this allowed?
> > >
> > > > It should be safe as with 4-level paging such request would fail and it's
> > > > reasonable to expect that userspace is not relying on the failure to
> > > > function properly.
> > >
> > > Huch?
> > >
> > > The first rule when looking at user space is that is broken or
> > > hostile. Reasonable and user space are mutually exclusive.
> >
> > That's basically the same assumption we made to implement current
> > interface of allocation memory above 47-bits.
> >
> > The premise is that nobody in right mind would try mmap(addr, MAP_FIXED)
> > where addr >= (1UL << 47) as it will always fail. So we can allow this to
> > succeed on 5-level paging machine as a way to allocate from larger address
> > space.
> >
> > By the same logic we can allow allocation for cases where addr is below
> > (1UL << 47), but addr+size is above the limit.
>
> Makes some sense, but it would be nice to have this documented exactly in
> arch_get_unmapped_area_topdown(), i.e. the function where you are adding
> the border check to. Otherwise 3 month from now somebody will look at that
> and ask exactly the same question again.
Okay, I'll update the patch.
--
Kirill A. Shutemov
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH] x86/mm: Do not allow non-MAP_FIXED mapping across DEFAULT_MAP_WINDOW border
@ 2017-11-14 12:06 ` Kirill A. Shutemov
0 siblings, 0 replies; 24+ messages in thread
From: Kirill A. Shutemov @ 2017-11-14 12:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Kirill A. Shutemov, Ingo Molnar, Linus Torvalds, x86,
H. Peter Anvin, Andy Lutomirski, Cyrill Gorcunov,
Nicholas Piggin, linux-mm, linux-kernel
On Mon, Nov 13, 2017 at 10:17:30PM +0100, Thomas Gleixner wrote:
> On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> > On Mon, Nov 13, 2017 at 05:57:03PM +0100, Thomas Gleixner wrote:
> > > On Mon, 13 Nov 2017, Kirill A. Shutemov wrote:
> > >
> > > > On Mon, Nov 13, 2017 at 04:43:26PM +0100, Thomas Gleixner wrote:
> > > > > On Tue, 7 Nov 2017, Kirill A. Shutemov wrote:
> > > > >
> > > > > > In case of 5-level paging, we don't put any mapping above 47-bit, unless
> > > > > > userspace explicitly asked for it.
> > > > > >
> > > > > > Userspace can ask for allocation from full address space by specifying
> > > > > > hint address above 47-bit.
> > > > > >
> > > > > > Nicholas noticed that current implementation violates this interface:
> > > > > > we can get vma partly in high addresses if we ask for a mapping at very
> > > > > > end of 47-bit address space.
> > > > > >
> > > > > > Let's make sure that, when consider hint address for non-MAP_FIXED
> > > > > > mapping, start and end of resulting vma are on the same side of 47-bit
> > > > > > border.
> > > > >
> > > > > What happens for mappings with MAP_FIXED which cross the border?
> > > >
> > > > It will succeed with 5-level paging.
> > >
> > > And why is this allowed?
> > >
> > > > It should be safe as with 4-level paging such request would fail and it's
> > > > reasonable to expect that userspace is not relying on the failure to
> > > > function properly.
> > >
> > > Huch?
> > >
> > > The first rule when looking at user space is that is broken or
> > > hostile. Reasonable and user space are mutually exclusive.
> >
> > That's basically the same assumption we made to implement current
> > interface of allocation memory above 47-bits.
> >
> > The premise is that nobody in right mind would try mmap(addr, MAP_FIXED)
> > where addr >= (1UL << 47) as it will always fail. So we can allow this to
> > succeed on 5-level paging machine as a way to allocate from larger address
> > space.
> >
> > By the same logic we can allow allocation for cases where addr is below
> > (1UL << 47), but addr+size is above the limit.
>
> Makes some sense, but it would be nice to have this documented exactly in
> arch_get_unmapped_area_topdown(), i.e. the function where you are adding
> the border check to. Otherwise 3 month from now somebody will look at that
> and ask exactly the same question again.
Okay, I'll update the patch.
--
Kirill A. Shutemov
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply [flat|nested] 24+ messages in thread