* [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-29 13:06 ` Roman Gushchin
0 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-29 13:06 UTC (permalink / raw)
To: linux-mm
Cc: linux-kernel, Roman Gushchin, Andrew Morton, Andrew Shewmaker,
Rik van Riel, Konstantin Khlebnikov, stable
I noticed, that "allowed" can easily overflow by falling below 0,
because (total_vm / 32) can be larger than "allowed". The problem
occurs in OVERCOMMIT_NONE mode.
In this case, a huge allocation can success and overcommit the system
(despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
(system-wide), so system become unusable.
The problem was masked out by commit c9b1d0981fcc
("mm: limit growth of 3% hardcoded other user reserve"),
but it's easy to reproduce it on older kernels:
1) set overcommit_memory sysctl to 2
2) mmap() large file multiple times (with VM_SHARED flag)
3) try to malloc() large amount of memory
It also can be reproduced on newer kernels, but miss-configured
sysctl_user_reserve_kbytes is required.
Fix this issue by switching to signed arithmetic here.
Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Shewmaker <agshew@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: stable@vger.kernel.org
---
mm/mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f684d5..5aa8dfe 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
*/
int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
{
- unsigned long free, allowed, reserve;
+ long free, allowed, reserve;
VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
-(s64)vm_committed_as_batch * num_online_cpus(),
@@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
*/
if (mm) {
reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
- allowed -= min(mm->total_vm / 32, reserve);
+ allowed -= min((long)mm->total_vm / 32, reserve);
}
if (percpu_counter_read_positive(&vm_committed_as) < allowed)
--
2.1.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-29 13:06 ` Roman Gushchin
0 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-29 13:06 UTC (permalink / raw)
To: linux-mm
Cc: linux-kernel, Roman Gushchin, Andrew Morton, Andrew Shewmaker,
Rik van Riel, Konstantin Khlebnikov, stable
I noticed, that "allowed" can easily overflow by falling below 0,
because (total_vm / 32) can be larger than "allowed". The problem
occurs in OVERCOMMIT_NONE mode.
In this case, a huge allocation can success and overcommit the system
(despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
(system-wide), so system become unusable.
The problem was masked out by commit c9b1d0981fcc
("mm: limit growth of 3% hardcoded other user reserve"),
but it's easy to reproduce it on older kernels:
1) set overcommit_memory sysctl to 2
2) mmap() large file multiple times (with VM_SHARED flag)
3) try to malloc() large amount of memory
It also can be reproduced on newer kernels, but miss-configured
sysctl_user_reserve_kbytes is required.
Fix this issue by switching to signed arithmetic here.
Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Shewmaker <agshew@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: stable@vger.kernel.org
---
mm/mmap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mmap.c b/mm/mmap.c
index 7f684d5..5aa8dfe 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
*/
int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
{
- unsigned long free, allowed, reserve;
+ long free, allowed, reserve;
VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
-(s64)vm_committed_as_batch * num_online_cpus(),
@@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
*/
if (mm) {
reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
- allowed -= min(mm->total_vm / 32, reserve);
+ allowed -= min((long)mm->total_vm / 32, reserve);
}
if (percpu_counter_read_positive(&vm_committed_as) < allowed)
--
2.1.0
--
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 related [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
2015-01-29 13:06 ` Roman Gushchin
@ 2015-01-29 19:57 ` Andrew Shewmaker
-1 siblings, 0 replies; 10+ messages in thread
From: Andrew Shewmaker @ 2015-01-29 19:57 UTC (permalink / raw)
To: Roman Gushchin
Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
Konstantin Khlebnikov, stable
On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
> I noticed, that "allowed" can easily overflow by falling below 0,
> because (total_vm / 32) can be larger than "allowed". The problem
> occurs in OVERCOMMIT_NONE mode.
>
> In this case, a huge allocation can success and overcommit the system
> (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
> (system-wide), so system become unusable.
>
> The problem was masked out by commit c9b1d0981fcc
> ("mm: limit growth of 3% hardcoded other user reserve"),
> but it's easy to reproduce it on older kernels:
> 1) set overcommit_memory sysctl to 2
> 2) mmap() large file multiple times (with VM_SHARED flag)
> 3) try to malloc() large amount of memory
>
> It also can be reproduced on newer kernels, but miss-configured
> sysctl_user_reserve_kbytes is required.
>
> Fix this issue by switching to signed arithmetic here.
>
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: stable@vger.kernel.org
> ---
> mm/mmap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7f684d5..5aa8dfe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
> */
> int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> {
> - unsigned long free, allowed, reserve;
> + long free, allowed, reserve;
>
> VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
> -(s64)vm_committed_as_batch * num_online_cpus(),
> @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> */
> if (mm) {
> reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
> - allowed -= min(mm->total_vm / 32, reserve);
> + allowed -= min((long)mm->total_vm / 32, reserve);
> }
>
> if (percpu_counter_read_positive(&vm_committed_as) < allowed)
> --
> 2.1.0
>
Makes sense to me. Please fix mm/nommu.c also.
If a caller passes in a big negative value for pages,
then vm_acct_memory() would decrement vm_committed_as, possibly
causing percpu_counter_read_positive(&vm_committed_as) and
__vm_enough_memory to return 0. Maybe that's okay? Callers
won't be passing in a negative pages anyway. Is there a reason
to let them, though?
-Andrew
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-29 19:57 ` Andrew Shewmaker
0 siblings, 0 replies; 10+ messages in thread
From: Andrew Shewmaker @ 2015-01-29 19:57 UTC (permalink / raw)
To: Roman Gushchin
Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
Konstantin Khlebnikov, stable
On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
> I noticed, that "allowed" can easily overflow by falling below 0,
> because (total_vm / 32) can be larger than "allowed". The problem
> occurs in OVERCOMMIT_NONE mode.
>
> In this case, a huge allocation can success and overcommit the system
> (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
> (system-wide), so system become unusable.
>
> The problem was masked out by commit c9b1d0981fcc
> ("mm: limit growth of 3% hardcoded other user reserve"),
> but it's easy to reproduce it on older kernels:
> 1) set overcommit_memory sysctl to 2
> 2) mmap() large file multiple times (with VM_SHARED flag)
> 3) try to malloc() large amount of memory
>
> It also can be reproduced on newer kernels, but miss-configured
> sysctl_user_reserve_kbytes is required.
>
> Fix this issue by switching to signed arithmetic here.
>
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: stable@vger.kernel.org
> ---
> mm/mmap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7f684d5..5aa8dfe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
> */
> int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> {
> - unsigned long free, allowed, reserve;
> + long free, allowed, reserve;
>
> VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
> -(s64)vm_committed_as_batch * num_online_cpus(),
> @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> */
> if (mm) {
> reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
> - allowed -= min(mm->total_vm / 32, reserve);
> + allowed -= min((long)mm->total_vm / 32, reserve);
> }
>
> if (percpu_counter_read_positive(&vm_committed_as) < allowed)
> --
> 2.1.0
>
Makes sense to me. Please fix mm/nommu.c also.
If a caller passes in a big negative value for pages,
then vm_acct_memory() would decrement vm_committed_as, possibly
causing percpu_counter_read_positive(&vm_committed_as) and
__vm_enough_memory to return 0. Maybe that's okay? Callers
won't be passing in a negative pages anyway. Is there a reason
to let them, though?
-Andrew
--
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] 10+ messages in thread
* [PATCH] mm/nommu.c: fix arithmetic overflow in __vm_enough_memory()
2015-01-29 19:57 ` Andrew Shewmaker
(?)
@ 2015-01-30 13:09 ` Roman Gushchin
-1 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-30 13:09 UTC (permalink / raw)
To: linux-mm
Cc: linux-kernel, Roman Gushchin, Andrew Morton, Andrew Shewmaker,
Rik van Riel, Konstantin Khlebnikov, stable
I noticed, that "allowed" can easily overflow by falling below 0,
because (total_vm / 32) can be larger than "allowed". The problem
occurs in OVERCOMMIT_NONE mode.
In this case, a huge allocation can success and overcommit the system
(despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
(system-wide), so system become unusable.
The problem was masked out by commit c9b1d0981fcc
("mm: limit growth of 3% hardcoded other user reserve"),
but it's easy to reproduce it on older kernels:
1) set overcommit_memory sysctl to 2
2) mmap() large file multiple times (with VM_SHARED flag)
3) try to malloc() large amount of memory
It also can be reproduced on newer kernels, but miss-configured
sysctl_user_reserve_kbytes is required.
Fix this issue by switching to signed arithmetic here.
Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Shewmaker <agshew@gmail.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: stable@vger.kernel.org
---
mm/nommu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/nommu.c b/mm/nommu.c
index b51eadf..e1fd67b 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -1894,7 +1894,7 @@ EXPORT_SYMBOL(unmap_mapping_range);
*/
int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
{
- unsigned long free, allowed, reserve;
+ long free, allowed, reserve;
vm_acct_memory(pages);
@@ -1958,7 +1958,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
*/
if (mm) {
reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
- allowed -= min(mm->total_vm / 32, reserve);
+ allowed -= min_t(long, mm->total_vm / 32, reserve);
}
if (percpu_counter_read_positive(&vm_committed_as) < allowed)
--
2.1.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
2015-01-29 19:57 ` Andrew Shewmaker
(?)
@ 2015-01-30 13:14 ` Roman Gushchin
-1 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-30 13:14 UTC (permalink / raw)
To: Andrew Shewmaker
Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
Konstantin Khlebnikov, stable
29.01.2015, 22:57, "Andrew Shewmaker" <agshew@gmail.com>:
> On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
>> I noticed, that "allowed" can easily overflow by falling below 0,
>> because (total_vm / 32) can be larger than "allowed". The problem
>> occurs in OVERCOMMIT_NONE mode.
>>
> Makes sense to me. Please fix mm/nommu.c also.
Thanks!
I sent a patch for nommu.c.
>
> If a caller passes in a big negative value for pages,
> then vm_acct_memory() would decrement vm_committed_as, possibly
> causing percpu_counter_read_positive(&vm_committed_as) and
> __vm_enough_memory to return 0. Maybe that's okay? Callers
> won't be passing in a negative pages anyway. Is there a reason
> to let them, though?
I think, it isn't a problem, since no one will commit negative values (I hope).
R.
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-30 13:14 ` Roman Gushchin
0 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-30 13:14 UTC (permalink / raw)
To: Andrew Shewmaker
Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
Konstantin Khlebnikov, stable
29.01.2015, 22:57, "Andrew Shewmaker" <agshew@gmail.com>:
> On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
>> О©╫I noticed, that "allowed" can easily overflow by falling below 0,
>> О©╫because (total_vm / 32) can be larger than "allowed". The problem
>> О©╫occurs in OVERCOMMIT_NONE mode.
>>
> Makes sense to me. Please fix mm/nommu.c also.
Thanks!
I sent a patch for nommu.c.
>
> If a caller passes in a big negative value for pages,
> then vm_acct_memory() would decrement vm_committed_as, possibly
> causing percpu_counter_read_positive(&vm_committed_as) and
> __vm_enough_memory to return 0. Maybe that's okay? Callers
> won't be passing in a negative pages anyway. Is there a reason
> to let them, though?
I think, it isn't a problem, since no one will commit negative values (I hope).
R.
--
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] 10+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-01-30 13:14 ` Roman Gushchin
0 siblings, 0 replies; 10+ messages in thread
From: Roman Gushchin @ 2015-01-30 13:14 UTC (permalink / raw)
To: Andrew Shewmaker
Cc: linux-mm, linux-kernel, Andrew Morton, Rik van Riel,
Konstantin Khlebnikov, stable
29.01.2015, 22:57, "Andrew Shewmaker" <agshew@gmail.com>:
> On Thu, Jan 29, 2015 at 04:06:03PM +0300, Roman Gushchin wrote:
>> ?I noticed, that "allowed" can easily overflow by falling below 0,
>> ?because (total_vm / 32) can be larger than "allowed". The problem
>> ?occurs in OVERCOMMIT_NONE mode.
>>
> Makes sense to me. Please fix mm/nommu.c also.
Thanks!
I sent a patch for nommu.c.
>
> If a caller passes in a big negative value for pages,
> then vm_acct_memory() would decrement vm_committed_as, possibly
> causing percpu_counter_read_positive(&vm_committed_as) and
> __vm_enough_memory to return 0. Maybe that's okay? Callers
> won't be passing in a negative pages anyway. Is there a reason
> to let them, though?
I think, it isn't a problem, since no one will commit negative values (I hope).
R.
--
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] 10+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
2015-01-29 13:06 ` Roman Gushchin
@ 2015-02-03 13:29 ` Michal Hocko
-1 siblings, 0 replies; 10+ messages in thread
From: Michal Hocko @ 2015-02-03 13:29 UTC (permalink / raw)
To: Roman Gushchin
Cc: linux-mm, linux-kernel, Andrew Morton, Andrew Shewmaker,
Rik van Riel, Konstantin Khlebnikov, stable
On Thu 29-01-15 16:06:03, Roman Gushchin wrote:
> I noticed, that "allowed" can easily overflow by falling below 0,
> because (total_vm / 32) can be larger than "allowed". The problem
> occurs in OVERCOMMIT_NONE mode.
s@OVERCOMMIT_NONE@OVERCOMMIT_NEVER@
> In this case, a huge allocation can success and overcommit the system
> (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
> (system-wide), so system become unusable.
>
> The problem was masked out by commit c9b1d0981fcc
> ("mm: limit growth of 3% hardcoded other user reserve"),
> but it's easy to reproduce it on older kernels:
> 1) set overcommit_memory sysctl to 2
> 2) mmap() large file multiple times (with VM_SHARED flag)
> 3) try to malloc() large amount of memory
>
> It also can be reproduced on newer kernels, but miss-configured
> sysctl_user_reserve_kbytes is required.
>
> Fix this issue by switching to signed arithmetic here.
>
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: stable@vger.kernel.org
With Andrew min -> min_t fixup
Reviewed-by: Michal Hocko <mhocko@suse.cz>
> ---
> mm/mmap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7f684d5..5aa8dfe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
> */
> int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> {
> - unsigned long free, allowed, reserve;
> + long free, allowed, reserve;
>
> VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
> -(s64)vm_committed_as_batch * num_online_cpus(),
> @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> */
> if (mm) {
> reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
> - allowed -= min(mm->total_vm / 32, reserve);
> + allowed -= min((long)mm->total_vm / 32, reserve);
> }
>
> if (percpu_counter_read_positive(&vm_committed_as) < allowed)
> --
> 2.1.0
>
> --
> 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>
--
Michal Hocko
SUSE Labs
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH] mm: fix arithmetic overflow in __vm_enough_memory()
@ 2015-02-03 13:29 ` Michal Hocko
0 siblings, 0 replies; 10+ messages in thread
From: Michal Hocko @ 2015-02-03 13:29 UTC (permalink / raw)
To: Roman Gushchin
Cc: linux-mm, linux-kernel, Andrew Morton, Andrew Shewmaker,
Rik van Riel, Konstantin Khlebnikov, stable
On Thu 29-01-15 16:06:03, Roman Gushchin wrote:
> I noticed, that "allowed" can easily overflow by falling below 0,
> because (total_vm / 32) can be larger than "allowed". The problem
> occurs in OVERCOMMIT_NONE mode.
s@OVERCOMMIT_NONE@OVERCOMMIT_NEVER@
> In this case, a huge allocation can success and overcommit the system
> (despite OVERCOMMIT_NONE mode). All subsequent allocations will fall
> (system-wide), so system become unusable.
>
> The problem was masked out by commit c9b1d0981fcc
> ("mm: limit growth of 3% hardcoded other user reserve"),
> but it's easy to reproduce it on older kernels:
> 1) set overcommit_memory sysctl to 2
> 2) mmap() large file multiple times (with VM_SHARED flag)
> 3) try to malloc() large amount of memory
>
> It also can be reproduced on newer kernels, but miss-configured
> sysctl_user_reserve_kbytes is required.
>
> Fix this issue by switching to signed arithmetic here.
>
> Signed-off-by: Roman Gushchin <klamm@yandex-team.ru>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Shewmaker <agshew@gmail.com>
> Cc: Rik van Riel <riel@redhat.com>
> Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> Cc: stable@vger.kernel.org
With Andrew min -> min_t fixup
Reviewed-by: Michal Hocko <mhocko@suse.cz>
> ---
> mm/mmap.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 7f684d5..5aa8dfe 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -152,7 +152,7 @@ EXPORT_SYMBOL_GPL(vm_memory_committed);
> */
> int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> {
> - unsigned long free, allowed, reserve;
> + long free, allowed, reserve;
>
> VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
> -(s64)vm_committed_as_batch * num_online_cpus(),
> @@ -220,7 +220,7 @@ int __vm_enough_memory(struct mm_struct *mm, long pages, int cap_sys_admin)
> */
> if (mm) {
> reserve = sysctl_user_reserve_kbytes >> (PAGE_SHIFT - 10);
> - allowed -= min(mm->total_vm / 32, reserve);
> + allowed -= min((long)mm->total_vm / 32, reserve);
> }
>
> if (percpu_counter_read_positive(&vm_committed_as) < allowed)
> --
> 2.1.0
>
> --
> 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>
--
Michal Hocko
SUSE Labs
--
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] 10+ messages in thread
end of thread, other threads:[~2015-02-03 13:29 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-29 13:06 [PATCH] mm: fix arithmetic overflow in __vm_enough_memory() Roman Gushchin
2015-01-29 13:06 ` Roman Gushchin
2015-01-29 19:57 ` Andrew Shewmaker
2015-01-29 19:57 ` Andrew Shewmaker
2015-01-30 13:09 ` [PATCH] mm/nommu.c: " Roman Gushchin
2015-01-30 13:14 ` [PATCH] mm: " Roman Gushchin
2015-01-30 13:14 ` Roman Gushchin
2015-01-30 13:14 ` Roman Gushchin
2015-02-03 13:29 ` Michal Hocko
2015-02-03 13:29 ` Michal Hocko
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.