All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v3] mm: warn about VmData over RLIMIT_DATA
@ 2016-01-23 20:52 ` Konstantin Khlebnikov
  0 siblings, 0 replies; 6+ messages in thread
From: Konstantin Khlebnikov @ 2016-01-23 20:52 UTC (permalink / raw)
  To: Cyrill Gorcunov, linux-mm, Linus Torvalds, Andrew Morton, linux-kernel
  Cc: Vegard Nossum, Peter Zijlstra, Vladimir Davydov, Andy Lutomirski,
	Quentin Casasnovas, Kees Cook, Willy Tarreau, Pavel Emelyanov

This patch fixes 84638335900f ("mm: rework virtual memory accounting")

Before that commit RLIMIT_DATA have control only over size of the brk region.
But that change have caused problems with all existing versions of valgrind,
because it set RLIMIT_DATA to zero.

This patch fixes rlimit check (limit actually in bytes, not pages)
and by default turns it into warning which prints at first VmData misuse:
"mmap: top (795): VmData 516096 exceed data ulimit 512000. Will be forbidden soon."

Behavior is controlled by boot param ignore_rlimit_data=y/n and by sysfs
/sys/module/kernel/parameters/ignore_rlimit_data. For now it set to "y".

Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Link: http://lkml.kernel.org/r/20151228211015.GL2194@uranus
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 Documentation/kernel-parameters.txt |    5 +++++
 mm/internal.h                       |   16 ++++++++++++++++
 mm/mmap.c                           |   23 +++++++++++++++++------
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index cfb2c0f1a4a8..e3507c2e14b0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1461,6 +1461,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			could change it dynamically, usually by
 			/sys/module/printk/parameters/ignore_loglevel.
 
+	ignore_rlimit_data
+			Ignore RLIMIT_DATA setting for data mappings,
+			print warning at first misuse. Could be changed by
+			/sys/module/kernel/parameters/ignore_rlimit_data.
+
 	ihash_entries=	[KNL]
 			Set number of hash buckets for inode cache.
 
diff --git a/mm/internal.h b/mm/internal.h
index ed8b5ffcf9b1..6e976302ddd8 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -216,6 +216,22 @@ static inline bool is_cow_mapping(vm_flags_t flags)
 	return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
 }
 
+static inline bool is_exec_mapping(vm_flags_t flags)
+{
+	return (flags & (VM_EXEC | VM_WRITE)) == VM_EXEC;
+}
+
+static inline bool is_stack_mapping(vm_flags_t flags)
+{
+	return (flags & (VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN))) != 0;
+}
+
+static inline bool is_data_mapping(vm_flags_t flags)
+{
+	return (flags & ((VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN)) |
+					VM_WRITE | VM_SHARED)) == VM_WRITE;
+}
+
 /* mm/util.c */
 void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
 		struct vm_area_struct *prev, struct rb_node *rb_parent);
diff --git a/mm/mmap.c b/mm/mmap.c
index 84b12624ceb0..cfc0cdca421e 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -42,6 +42,7 @@
 #include <linux/memory.h>
 #include <linux/printk.h>
 #include <linux/userfaultfd_k.h>
+#include <linux/moduleparam.h>
 
 #include <asm/uaccess.h>
 #include <asm/cacheflush.h>
@@ -69,6 +70,8 @@ const int mmap_rnd_compat_bits_max = CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX;
 int mmap_rnd_compat_bits __read_mostly = CONFIG_ARCH_MMAP_RND_COMPAT_BITS;
 #endif
 
+static bool ignore_rlimit_data = true;
+core_param(ignore_rlimit_data, ignore_rlimit_data, bool, 0644);
 
 static void unmap_region(struct mm_struct *mm,
 		struct vm_area_struct *vma, struct vm_area_struct *prev,
@@ -2982,9 +2985,17 @@ bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long npages)
 	if (mm->total_vm + npages > rlimit(RLIMIT_AS) >> PAGE_SHIFT)
 		return false;
 
-	if ((flags & (VM_WRITE | VM_SHARED | (VM_STACK_FLAGS &
-				(VM_GROWSUP | VM_GROWSDOWN)))) == VM_WRITE)
-		return mm->data_vm + npages <= rlimit(RLIMIT_DATA);
+	if (is_data_mapping(flags) &&
+	    mm->data_vm + npages > rlimit(RLIMIT_DATA) >> PAGE_SHIFT) {
+		if (ignore_rlimit_data)
+			pr_warn_once("%s (%d): VmData %lu exceed data ulimit "
+				     "%lu. Will be forbidden soon.\n",
+				     current->comm, current->pid,
+				     (mm->data_vm + npages) << PAGE_SHIFT,
+				     rlimit(RLIMIT_DATA));
+		else
+			return false;
+	}
 
 	return true;
 }
@@ -2993,11 +3004,11 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
 {
 	mm->total_vm += npages;
 
-	if ((flags & (VM_EXEC | VM_WRITE)) == VM_EXEC)
+	if (is_exec_mapping(flags))
 		mm->exec_vm += npages;
-	else if (flags & (VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN)))
+	else if (is_stack_mapping(flags))
 		mm->stack_vm += npages;
-	else if ((flags & (VM_WRITE | VM_SHARED)) == VM_WRITE)
+	else if (is_data_mapping(flags))
 		mm->data_vm += npages;
 }
 

^ permalink raw reply related	[flat|nested] 6+ messages in thread

* [PATCH v3] mm: warn about VmData over RLIMIT_DATA
@ 2016-01-23 20:52 ` Konstantin Khlebnikov
  0 siblings, 0 replies; 6+ messages in thread
From: Konstantin Khlebnikov @ 2016-01-23 20:52 UTC (permalink / raw)
  To: Cyrill Gorcunov, linux-mm, Linus Torvalds, Andrew Morton, linux-kernel
  Cc: Vegard Nossum, Peter Zijlstra, Vladimir Davydov, Andy Lutomirski,
	Quentin Casasnovas, Kees Cook, Willy Tarreau, Pavel Emelyanov

This patch fixes 84638335900f ("mm: rework virtual memory accounting")

Before that commit RLIMIT_DATA have control only over size of the brk region.
But that change have caused problems with all existing versions of valgrind,
because it set RLIMIT_DATA to zero.

This patch fixes rlimit check (limit actually in bytes, not pages)
and by default turns it into warning which prints at first VmData misuse:
"mmap: top (795): VmData 516096 exceed data ulimit 512000. Will be forbidden soon."

Behavior is controlled by boot param ignore_rlimit_data=y/n and by sysfs
/sys/module/kernel/parameters/ignore_rlimit_data. For now it set to "y".

Signed-off-by: Konstantin Khlebnikov <koct9i@gmail.com>
Link: http://lkml.kernel.org/r/20151228211015.GL2194@uranus
Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
---
 Documentation/kernel-parameters.txt |    5 +++++
 mm/internal.h                       |   16 ++++++++++++++++
 mm/mmap.c                           |   23 +++++++++++++++++------
 3 files changed, 38 insertions(+), 6 deletions(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index cfb2c0f1a4a8..e3507c2e14b0 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1461,6 +1461,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			could change it dynamically, usually by
 			/sys/module/printk/parameters/ignore_loglevel.
 
+	ignore_rlimit_data
+			Ignore RLIMIT_DATA setting for data mappings,
+			print warning at first misuse. Could be changed by
+			/sys/module/kernel/parameters/ignore_rlimit_data.
+
 	ihash_entries=	[KNL]
 			Set number of hash buckets for inode cache.
 
diff --git a/mm/internal.h b/mm/internal.h
index ed8b5ffcf9b1..6e976302ddd8 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -216,6 +216,22 @@ static inline bool is_cow_mapping(vm_flags_t flags)
 	return (flags & (VM_SHARED | VM_MAYWRITE)) == VM_MAYWRITE;
 }
 
+static inline bool is_exec_mapping(vm_flags_t flags)
+{
+	return (flags & (VM_EXEC | VM_WRITE)) == VM_EXEC;
+}
+
+static inline bool is_stack_mapping(vm_flags_t flags)
+{
+	return (flags & (VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN))) != 0;
+}
+
+static inline bool is_data_mapping(vm_flags_t flags)
+{
+	return (flags & ((VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN)) |
+					VM_WRITE | VM_SHARED)) == VM_WRITE;
+}
+
 /* mm/util.c */
 void __vma_link_list(struct mm_struct *mm, struct vm_area_struct *vma,
 		struct vm_area_struct *prev, struct rb_node *rb_parent);
diff --git a/mm/mmap.c b/mm/mmap.c
index 84b12624ceb0..cfc0cdca421e 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -42,6 +42,7 @@
 #include <linux/memory.h>
 #include <linux/printk.h>
 #include <linux/userfaultfd_k.h>
+#include <linux/moduleparam.h>
 
 #include <asm/uaccess.h>
 #include <asm/cacheflush.h>
@@ -69,6 +70,8 @@ const int mmap_rnd_compat_bits_max = CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX;
 int mmap_rnd_compat_bits __read_mostly = CONFIG_ARCH_MMAP_RND_COMPAT_BITS;
 #endif
 
+static bool ignore_rlimit_data = true;
+core_param(ignore_rlimit_data, ignore_rlimit_data, bool, 0644);
 
 static void unmap_region(struct mm_struct *mm,
 		struct vm_area_struct *vma, struct vm_area_struct *prev,
@@ -2982,9 +2985,17 @@ bool may_expand_vm(struct mm_struct *mm, vm_flags_t flags, unsigned long npages)
 	if (mm->total_vm + npages > rlimit(RLIMIT_AS) >> PAGE_SHIFT)
 		return false;
 
-	if ((flags & (VM_WRITE | VM_SHARED | (VM_STACK_FLAGS &
-				(VM_GROWSUP | VM_GROWSDOWN)))) == VM_WRITE)
-		return mm->data_vm + npages <= rlimit(RLIMIT_DATA);
+	if (is_data_mapping(flags) &&
+	    mm->data_vm + npages > rlimit(RLIMIT_DATA) >> PAGE_SHIFT) {
+		if (ignore_rlimit_data)
+			pr_warn_once("%s (%d): VmData %lu exceed data ulimit "
+				     "%lu. Will be forbidden soon.\n",
+				     current->comm, current->pid,
+				     (mm->data_vm + npages) << PAGE_SHIFT,
+				     rlimit(RLIMIT_DATA));
+		else
+			return false;
+	}
 
 	return true;
 }
@@ -2993,11 +3004,11 @@ void vm_stat_account(struct mm_struct *mm, vm_flags_t flags, long npages)
 {
 	mm->total_vm += npages;
 
-	if ((flags & (VM_EXEC | VM_WRITE)) == VM_EXEC)
+	if (is_exec_mapping(flags))
 		mm->exec_vm += npages;
-	else if (flags & (VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN)))
+	else if (is_stack_mapping(flags))
 		mm->stack_vm += npages;
-	else if ((flags & (VM_WRITE | VM_SHARED)) == VM_WRITE)
+	else if (is_data_mapping(flags))
 		mm->data_vm += npages;
 }
 

--
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] 6+ messages in thread

* Re: [PATCH v3] mm: warn about VmData over RLIMIT_DATA
  2016-01-23 20:52 ` Konstantin Khlebnikov
@ 2016-01-26 22:49   ` Andrew Morton
  -1 siblings, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2016-01-26 22:49 UTC (permalink / raw)
  To: Konstantin Khlebnikov
  Cc: Cyrill Gorcunov, linux-mm, Linus Torvalds, Andrew Morton,
	linux-kernel, Vegard Nossum, Peter Zijlstra, Vladimir Davydov,
	Andy Lutomirski, Quentin Casasnovas, Kees Cook, Willy Tarreau,
	Pavel Emelyanov

On Sat, 23 Jan 2016 23:52:29 +0300 Konstantin Khlebnikov <koct9i@gmail.com> wrote:

> This patch fixes 84638335900f ("mm: rework virtual memory accounting")

uh, I think I'll rewrite this to

: This patch provides a way of working around a slight regression introduced
: by 84638335900f ("mm: rework virtual memory accounting").

> Before that commit RLIMIT_DATA have control only over size of the brk region.
> But that change have caused problems with all existing versions of valgrind,
> because it set RLIMIT_DATA to zero.
> 
> This patch fixes rlimit check (limit actually in bytes, not pages)
> and by default turns it into warning which prints at first VmData misuse:
> "mmap: top (795): VmData 516096 exceed data ulimit 512000. Will be forbidden soon."
> 
> Behavior is controlled by boot param ignore_rlimit_data=y/n and by sysfs
> /sys/module/kernel/parameters/ignore_rlimit_data. For now it set to "y".
> 
> 
> ...
>
> +static inline bool is_data_mapping(vm_flags_t flags)
> +{
> +	return (flags & ((VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN)) |
> +					VM_WRITE | VM_SHARED)) == VM_WRITE;
> +}

This (copied from existing code) hurts my brain.  We're saying "if it
isn't stack and it's unshared and writable, it's data", yes?

hm.  I guess that's because with a shared mapping we don't know who to
blame for the memory consumption so we blame nobody.  But what about
non-shared read-only mappings?

Can we please have a comment here fully explaining the thinking?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] mm: warn about VmData over RLIMIT_DATA
@ 2016-01-26 22:49   ` Andrew Morton
  0 siblings, 0 replies; 6+ messages in thread
From: Andrew Morton @ 2016-01-26 22:49 UTC (permalink / raw)
  To: Konstantin Khlebnikov
  Cc: Cyrill Gorcunov, linux-mm, Linus Torvalds, Andrew Morton,
	linux-kernel, Vegard Nossum, Peter Zijlstra, Vladimir Davydov,
	Andy Lutomirski, Quentin Casasnovas, Kees Cook, Willy Tarreau,
	Pavel Emelyanov

On Sat, 23 Jan 2016 23:52:29 +0300 Konstantin Khlebnikov <koct9i@gmail.com> wrote:

> This patch fixes 84638335900f ("mm: rework virtual memory accounting")

uh, I think I'll rewrite this to

: This patch provides a way of working around a slight regression introduced
: by 84638335900f ("mm: rework virtual memory accounting").

> Before that commit RLIMIT_DATA have control only over size of the brk region.
> But that change have caused problems with all existing versions of valgrind,
> because it set RLIMIT_DATA to zero.
> 
> This patch fixes rlimit check (limit actually in bytes, not pages)
> and by default turns it into warning which prints at first VmData misuse:
> "mmap: top (795): VmData 516096 exceed data ulimit 512000. Will be forbidden soon."
> 
> Behavior is controlled by boot param ignore_rlimit_data=y/n and by sysfs
> /sys/module/kernel/parameters/ignore_rlimit_data. For now it set to "y".
> 
> 
> ...
>
> +static inline bool is_data_mapping(vm_flags_t flags)
> +{
> +	return (flags & ((VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN)) |
> +					VM_WRITE | VM_SHARED)) == VM_WRITE;
> +}

This (copied from existing code) hurts my brain.  We're saying "if it
isn't stack and it's unshared and writable, it's data", yes?

hm.  I guess that's because with a shared mapping we don't know who to
blame for the memory consumption so we blame nobody.  But what about
non-shared read-only mappings?

Can we please have a comment here fully explaining the thinking?

--
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] 6+ messages in thread

* Re: [PATCH v3] mm: warn about VmData over RLIMIT_DATA
  2016-01-26 22:49   ` Andrew Morton
@ 2016-01-27  9:09     ` Konstantin Khlebnikov
  -1 siblings, 0 replies; 6+ messages in thread
From: Konstantin Khlebnikov @ 2016-01-27  9:09 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Cyrill Gorcunov, linux-mm, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Vegard Nossum, Peter Zijlstra,
	Vladimir Davydov, Andy Lutomirski, Quentin Casasnovas, Kees Cook,
	Willy Tarreau, Pavel Emelyanov

On Wed, Jan 27, 2016 at 1:49 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Sat, 23 Jan 2016 23:52:29 +0300 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
>
>> This patch fixes 84638335900f ("mm: rework virtual memory accounting")
>
> uh, I think I'll rewrite this to
>
> : This patch provides a way of working around a slight regression introduced
> : by 84638335900f ("mm: rework virtual memory accounting").

Sure.

As you see I keept this in "ignore and warn" state by default.
During testing in linux-next it was able to cauch only small limits
like 0 in case of valgrind decause bug in pages/bytes units.
I think it's a bad idea to enfornce limit in the middle of merge window.
So let's change default to "block" in the next release.

>
>> Before that commit RLIMIT_DATA have control only over size of the brk region.
>> But that change have caused problems with all existing versions of valgrind,
>> because it set RLIMIT_DATA to zero.
>>
>> This patch fixes rlimit check (limit actually in bytes, not pages)
>> and by default turns it into warning which prints at first VmData misuse:
>> "mmap: top (795): VmData 516096 exceed data ulimit 512000. Will be forbidden soon."
>>
>> Behavior is controlled by boot param ignore_rlimit_data=y/n and by sysfs
>> /sys/module/kernel/parameters/ignore_rlimit_data. For now it set to "y".
>>
>>
>> ...
>>
>> +static inline bool is_data_mapping(vm_flags_t flags)
>> +{
>> +     return (flags & ((VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN)) |
>> +                                     VM_WRITE | VM_SHARED)) == VM_WRITE;
>> +}
>
> This (copied from existing code) hurts my brain.  We're saying "if it
> isn't stack and it's unshared and writable, it's data", yes?

Yes. Data vma supposed to be private, writable and without GROWSDOWN/UP.
We could make it more redable if define macro for stack growing direction.

Or redefine that data shouldn't grow in any direction and any growable
vma is a "stack",
but RLIMIT_STACK is enforced only in one direction (or not? not sure).
Anyway only few arches actually have flag VM_GROWSUP.

VM_WRITE separates Data and Code - Data can be executable, Code
should't be writable.
VM_GROWS separates Data and Stack - Stack grows automaticallly, Data is not.

Probaly stack should be writable too, but some applications  might
remaps pieces of stack as read-only.

For now (except parisc and metag)

VM_GROWSDOWN | VM_EXEC is a code
VM_GROWSDOWN | VM_EXEC | VM_WRITE is a stack
VM_GROWSUP | VM_EXEC | VM_WRITE is a data (for ia64)

And yes, this hurts my brain too. But much less than previous version
of accounting.

>
> hm.  I guess that's because with a shared mapping we don't know who to
> blame for the memory consumption so we blame nobody.  But what about
> non-shared read-only mappings?

I have no Idea. There's a lot stange combinations. But since VmData is
supposed to be limited with RLIMIT_DATA it safer to leave them alone.
User will see them in total VmSize and able to limit with RLIMIT_AS.

To be honest RLMIT_DATA cannot limit memory consumption at all.
RLIMIT_AS cannot do anything too: applicataion can keep any
amount of data in unlinked tmpfs file and mmap them as needed.
Only memory controller can solve this.

>
> Can we please have a comment here fully explaining the thinking?
>

Ok. I'll tie this together in a form of patch.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH v3] mm: warn about VmData over RLIMIT_DATA
@ 2016-01-27  9:09     ` Konstantin Khlebnikov
  0 siblings, 0 replies; 6+ messages in thread
From: Konstantin Khlebnikov @ 2016-01-27  9:09 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Cyrill Gorcunov, linux-mm, Linus Torvalds, Andrew Morton,
	Linux Kernel Mailing List, Vegard Nossum, Peter Zijlstra,
	Vladimir Davydov, Andy Lutomirski, Quentin Casasnovas, Kees Cook,
	Willy Tarreau, Pavel Emelyanov

On Wed, Jan 27, 2016 at 1:49 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Sat, 23 Jan 2016 23:52:29 +0300 Konstantin Khlebnikov <koct9i@gmail.com> wrote:
>
>> This patch fixes 84638335900f ("mm: rework virtual memory accounting")
>
> uh, I think I'll rewrite this to
>
> : This patch provides a way of working around a slight regression introduced
> : by 84638335900f ("mm: rework virtual memory accounting").

Sure.

As you see I keept this in "ignore and warn" state by default.
During testing in linux-next it was able to cauch only small limits
like 0 in case of valgrind decause bug in pages/bytes units.
I think it's a bad idea to enfornce limit in the middle of merge window.
So let's change default to "block" in the next release.

>
>> Before that commit RLIMIT_DATA have control only over size of the brk region.
>> But that change have caused problems with all existing versions of valgrind,
>> because it set RLIMIT_DATA to zero.
>>
>> This patch fixes rlimit check (limit actually in bytes, not pages)
>> and by default turns it into warning which prints at first VmData misuse:
>> "mmap: top (795): VmData 516096 exceed data ulimit 512000. Will be forbidden soon."
>>
>> Behavior is controlled by boot param ignore_rlimit_data=y/n and by sysfs
>> /sys/module/kernel/parameters/ignore_rlimit_data. For now it set to "y".
>>
>>
>> ...
>>
>> +static inline bool is_data_mapping(vm_flags_t flags)
>> +{
>> +     return (flags & ((VM_STACK_FLAGS & (VM_GROWSUP | VM_GROWSDOWN)) |
>> +                                     VM_WRITE | VM_SHARED)) == VM_WRITE;
>> +}
>
> This (copied from existing code) hurts my brain.  We're saying "if it
> isn't stack and it's unshared and writable, it's data", yes?

Yes. Data vma supposed to be private, writable and without GROWSDOWN/UP.
We could make it more redable if define macro for stack growing direction.

Or redefine that data shouldn't grow in any direction and any growable
vma is a "stack",
but RLIMIT_STACK is enforced only in one direction (or not? not sure).
Anyway only few arches actually have flag VM_GROWSUP.

VM_WRITE separates Data and Code - Data can be executable, Code
should't be writable.
VM_GROWS separates Data and Stack - Stack grows automaticallly, Data is not.

Probaly stack should be writable too, but some applications  might
remaps pieces of stack as read-only.

For now (except parisc and metag)

VM_GROWSDOWN | VM_EXEC is a code
VM_GROWSDOWN | VM_EXEC | VM_WRITE is a stack
VM_GROWSUP | VM_EXEC | VM_WRITE is a data (for ia64)

And yes, this hurts my brain too. But much less than previous version
of accounting.

>
> hm.  I guess that's because with a shared mapping we don't know who to
> blame for the memory consumption so we blame nobody.  But what about
> non-shared read-only mappings?

I have no Idea. There's a lot stange combinations. But since VmData is
supposed to be limited with RLIMIT_DATA it safer to leave them alone.
User will see them in total VmSize and able to limit with RLIMIT_AS.

To be honest RLMIT_DATA cannot limit memory consumption at all.
RLIMIT_AS cannot do anything too: applicataion can keep any
amount of data in unlinked tmpfs file and mmap them as needed.
Only memory controller can solve this.

>
> Can we please have a comment here fully explaining the thinking?
>

Ok. I'll tie this together in a form of patch.

--
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] 6+ messages in thread

end of thread, other threads:[~2016-01-27  9:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-23 20:52 [PATCH v3] mm: warn about VmData over RLIMIT_DATA Konstantin Khlebnikov
2016-01-23 20:52 ` Konstantin Khlebnikov
2016-01-26 22:49 ` Andrew Morton
2016-01-26 22:49   ` Andrew Morton
2016-01-27  9:09   ` Konstantin Khlebnikov
2016-01-27  9:09     ` Konstantin Khlebnikov

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.