* [LTP] [PATCH] max_map_count: corrected max_map_count condition
@ 2013-07-30 13:47 Stanislav Kholmanskikh
2013-07-31 3:03 ` Caspar Zhang
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Stanislav Kholmanskikh @ 2013-07-30 13:47 UTC (permalink / raw)
To: ltp-list; +Cc: bob.picco
From: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
* kernel test for max_map_count_sysctl is:
/* Too many mappings? */
if (mm->map_count > sysctl_max_map_count)
return -ENOMEM;
so in LTP test map_count should be greater than max_map_count by 1
* only [vsyscall] is allocated without incrementing mm->map_count
Author: Bob Picco <bob.picco@oracle.com>
Signed-off-by: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
---
testcases/kernel/mem/tunable/max_map_count.c | 41 +++++++++++++++++--------
1 files changed, 28 insertions(+), 13 deletions(-)
diff --git a/testcases/kernel/mem/tunable/max_map_count.c b/testcases/kernel/mem/tunable/max_map_count.c
index e948868..01fbe5e 100644
--- a/testcases/kernel/mem/tunable/max_map_count.c
+++ b/testcases/kernel/mem/tunable/max_map_count.c
@@ -14,20 +14,16 @@
* The program trys to invoke mmap() endless until triggering MAP_FAILED,
* then read the process's maps file /proc/[pid]/maps, save the line number
* to map_count variable, and compare it with /proc/sys/vm/max_map_count,
- * map_count should less than max_map_count.
- * Note: There are two special vmas VDSO and VSYSCALL, which are allocated
- * via install_special_mapping(), install_specail_mapping() allows the VMAs
- * to be allocated and inserted without checking the sysctl_map_map_count,
- * and each /proc/<pid>/maps has both at the end:
- * # cat /proc/self/maps
+ * map_count should be greater than max_map_count by 1;
+ *
+ * Note: On some architectures there is a special vma VSYSCALL, which
+ * is allocated without incrementing mm->map_count variable. On these
+ * architectures each /proc/<pid>/maps has at the end:
* ...
* ...
- * 7fff7b9ff000-7fff7ba00000 r-xp 00000000 00:00 0 [vdso]
* ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
*
- * so during comparing with map_count and /proc/sys/vm/max_map_count,
- * we should except the two special vmas from map_count:
- * map_count -= 2;
+ * so we ignore this line during /proc/[pid]/maps reading.
*
* ********************************************************************
* Copyright (C) 2012 Red Hat, Inc.
@@ -121,6 +117,21 @@ void cleanup(void)
TEST_CLEANUP;
}
+/* This is a filter to exclude map entries which aren't accounted
+ * for in the vm_area_struct's map_count.
+ */
+#if defined(__x86_64__) || defined(__x86__)
+static int filter_map(char *buf)
+{
+ return strcmp(buf, "[vsyscall]") == 0;
+}
+#else
+static int filter_map(char *buf)
+{
+ return 0;
+}
+#endif
+
static long count_maps(pid_t pid)
{
FILE *fp;
@@ -136,8 +147,7 @@ static long count_maps(pid_t pid)
while (getline(&line, &len, fp) != -1) {
/* exclude vdso and vsyscall */
if (sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf) ==
- 1 && ((strcmp(buf, "[vdso]") == 0) ||
- (strcmp(buf, "[vsyscall]") == 0)))
+ 1 && filter_map(buf))
continue;
map_count++;
}
@@ -202,7 +212,12 @@ static void max_map_count_test(void)
tst_brkm(TBROK, cleanup, "child did not stopped");
map_count = count_maps(pid);
- if (map_count == max_maps)
+ /* Note max_maps will be exceeded by one for
+ * the sysctl setting of max_map_count. This
+ * is the mm failure point at the time of
+ * writing this COMMENT!
+ */
+ if (map_count == (max_maps + 1))
tst_resm(TPASS, "%ld map entries in total "
"as expected.", max_maps);
else
--
1.7.1
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition
2013-07-30 13:47 [LTP] [PATCH] max_map_count: corrected max_map_count condition Stanislav Kholmanskikh
@ 2013-07-31 3:03 ` Caspar Zhang
2013-08-05 3:16 ` Zhouping Liu
2013-08-05 15:41 ` chrubis
2 siblings, 0 replies; 7+ messages in thread
From: Caspar Zhang @ 2013-07-31 3:03 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: ltp-list, bob.picco
On 07/30/2013 09:47 PM, Stanislav Kholmanskikh wrote:
> From: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
>
> * kernel test for max_map_count_sysctl is:
> /* Too many mappings? */
> if (mm->map_count > sysctl_max_map_count)
> return -ENOMEM;
> so in LTP test map_count should be greater than max_map_count by 1
>
> * only [vsyscall] is allocated without incrementing mm->map_count
>
> Author: Bob Picco <bob.picco@oracle.com>
>
> Signed-off-by: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
Acked-by: Caspar Zhang <caspar@casparzhang.com>
> ---
> testcases/kernel/mem/tunable/max_map_count.c | 41 +++++++++++++++++--------
> 1 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/testcases/kernel/mem/tunable/max_map_count.c b/testcases/kernel/mem/tunable/max_map_count.c
> index e948868..01fbe5e 100644
> --- a/testcases/kernel/mem/tunable/max_map_count.c
> +++ b/testcases/kernel/mem/tunable/max_map_count.c
> @@ -14,20 +14,16 @@
> * The program trys to invoke mmap() endless until triggering MAP_FAILED,
> * then read the process's maps file /proc/[pid]/maps, save the line number
> * to map_count variable, and compare it with /proc/sys/vm/max_map_count,
> - * map_count should less than max_map_count.
> - * Note: There are two special vmas VDSO and VSYSCALL, which are allocated
> - * via install_special_mapping(), install_specail_mapping() allows the VMAs
> - * to be allocated and inserted without checking the sysctl_map_map_count,
> - * and each /proc/<pid>/maps has both at the end:
> - * # cat /proc/self/maps
> + * map_count should be greater than max_map_count by 1;
> + *
> + * Note: On some architectures there is a special vma VSYSCALL, which
> + * is allocated without incrementing mm->map_count variable. On these
> + * architectures each /proc/<pid>/maps has at the end:
> * ...
> * ...
> - * 7fff7b9ff000-7fff7ba00000 r-xp 00000000 00:00 0 [vdso]
> * ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
> *
> - * so during comparing with map_count and /proc/sys/vm/max_map_count,
> - * we should except the two special vmas from map_count:
> - * map_count -= 2;
> + * so we ignore this line during /proc/[pid]/maps reading.
> *
> * ********************************************************************
> * Copyright (C) 2012 Red Hat, Inc.
> @@ -121,6 +117,21 @@ void cleanup(void)
> TEST_CLEANUP;
> }
>
> +/* This is a filter to exclude map entries which aren't accounted
> + * for in the vm_area_struct's map_count.
> + */
> +#if defined(__x86_64__) || defined(__x86__)
> +static int filter_map(char *buf)
> +{
> + return strcmp(buf, "[vsyscall]") == 0;
> +}
> +#else
> +static int filter_map(char *buf)
> +{
> + return 0;
> +}
> +#endif
> +
> static long count_maps(pid_t pid)
> {
> FILE *fp;
> @@ -136,8 +147,7 @@ static long count_maps(pid_t pid)
> while (getline(&line, &len, fp) != -1) {
> /* exclude vdso and vsyscall */
> if (sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf) ==
> - 1 && ((strcmp(buf, "[vdso]") == 0) ||
> - (strcmp(buf, "[vsyscall]") == 0)))
> + 1 && filter_map(buf))
> continue;
> map_count++;
> }
> @@ -202,7 +212,12 @@ static void max_map_count_test(void)
> tst_brkm(TBROK, cleanup, "child did not stopped");
>
> map_count = count_maps(pid);
> - if (map_count == max_maps)
> + /* Note max_maps will be exceeded by one for
> + * the sysctl setting of max_map_count. This
> + * is the mm failure point at the time of
> + * writing this COMMENT!
> + */
> + if (map_count == (max_maps + 1))
> tst_resm(TPASS, "%ld map entries in total "
> "as expected.", max_maps);
> else
>
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition
2013-07-30 13:47 [LTP] [PATCH] max_map_count: corrected max_map_count condition Stanislav Kholmanskikh
2013-07-31 3:03 ` Caspar Zhang
@ 2013-08-05 3:16 ` Zhouping Liu
2013-08-06 7:08 ` Stanislav Kholmanskikh
2013-08-05 15:41 ` chrubis
2 siblings, 1 reply; 7+ messages in thread
From: Zhouping Liu @ 2013-08-05 3:16 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: ltp-list, bob.picco
On 07/30/2013 09:47 PM, Stanislav Kholmanskikh wrote:
> From: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
>
> * kernel test for max_map_count_sysctl is:
> /* Too many mappings? */
> if (mm->map_count > sysctl_max_map_count)
> return -ENOMEM;
> so in LTP test map_count should be greater than max_map_count by 1
>
> * only [vsyscall] is allocated without incrementing mm->map_count
>
> Author: Bob Picco <bob.picco@oracle.com>
>
> Signed-off-by: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
> ---
> testcases/kernel/mem/tunable/max_map_count.c | 41 +++++++++++++++++--------
> 1 files changed, 28 insertions(+), 13 deletions(-)
>
> diff --git a/testcases/kernel/mem/tunable/max_map_count.c b/testcases/kernel/mem/tunable/max_map_count.c
> index e948868..01fbe5e 100644
> --- a/testcases/kernel/mem/tunable/max_map_count.c
> +++ b/testcases/kernel/mem/tunable/max_map_count.c
> @@ -14,20 +14,16 @@
> * The program trys to invoke mmap() endless until triggering MAP_FAILED,
> * then read the process's maps file /proc/[pid]/maps, save the line number
> * to map_count variable, and compare it with /proc/sys/vm/max_map_count,
> - * map_count should less than max_map_count.
> - * Note: There are two special vmas VDSO and VSYSCALL, which are allocated
> - * via install_special_mapping(), install_specail_mapping() allows the VMAs
> - * to be allocated and inserted without checking the sysctl_map_map_count,
> - * and each /proc/<pid>/maps has both at the end:
> - * # cat /proc/self/maps
> + * map_count should be greater than max_map_count by 1;
> + *
> + * Note: On some architectures there is a special vma VSYSCALL, which
> + * is allocated without incrementing mm->map_count variable. On these
> + * architectures each /proc/<pid>/maps has at the end:
> * ...
> * ...
> - * 7fff7b9ff000-7fff7ba00000 r-xp 00000000 00:00 0 [vdso]
Why you removed VDSO map? AFAIK VDSO map is also calculated by
install_special_maping(),
so the VMA is allocated and inserted without checking the
sysctl_max_map_count.
Thanks,
Zhouping
> * ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall]
> *
> - * so during comparing with map_count and /proc/sys/vm/max_map_count,
> - * we should except the two special vmas from map_count:
> - * map_count -= 2;
> + * so we ignore this line during /proc/[pid]/maps reading.
> *
> * ********************************************************************
> * Copyright (C) 2012 Red Hat, Inc.
> @@ -121,6 +117,21 @@ void cleanup(void)
> TEST_CLEANUP;
> }
>
> +/* This is a filter to exclude map entries which aren't accounted
> + * for in the vm_area_struct's map_count.
> + */
> +#if defined(__x86_64__) || defined(__x86__)
> +static int filter_map(char *buf)
> +{
> + return strcmp(buf, "[vsyscall]") == 0;
> +}
> +#else
> +static int filter_map(char *buf)
> +{
> + return 0;
> +}
> +#endif
> +
> static long count_maps(pid_t pid)
> {
> FILE *fp;
> @@ -136,8 +147,7 @@ static long count_maps(pid_t pid)
> while (getline(&line, &len, fp) != -1) {
> /* exclude vdso and vsyscall */
> if (sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf) ==
> - 1 && ((strcmp(buf, "[vdso]") == 0) ||
> - (strcmp(buf, "[vsyscall]") == 0)))
> + 1 && filter_map(buf))
> continue;
> map_count++;
> }
> @@ -202,7 +212,12 @@ static void max_map_count_test(void)
> tst_brkm(TBROK, cleanup, "child did not stopped");
>
> map_count = count_maps(pid);
> - if (map_count == max_maps)
> + /* Note max_maps will be exceeded by one for
> + * the sysctl setting of max_map_count. This
> + * is the mm failure point at the time of
> + * writing this COMMENT!
> + */
> + if (map_count == (max_maps + 1))
> tst_resm(TPASS, "%ld map entries in total "
> "as expected.", max_maps);
> else
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition
2013-07-30 13:47 [LTP] [PATCH] max_map_count: corrected max_map_count condition Stanislav Kholmanskikh
2013-07-31 3:03 ` Caspar Zhang
2013-08-05 3:16 ` Zhouping Liu
@ 2013-08-05 15:41 ` chrubis
[not found] ` <52009D26.4030609@oracle.com>
2 siblings, 1 reply; 7+ messages in thread
From: chrubis @ 2013-08-05 15:41 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: ltp-list, bob.picco
Hi!
> * kernel test for max_map_count_sysctl is:
> /* Too many mappings? */
> if (mm->map_count > sysctl_max_map_count)
> return -ENOMEM;
Hmm, that looks like we allow the map_count to became one greater than
max_map_count, is this known bug?
> so in LTP test map_count should be greater than max_map_count by 1
>
> * only [vsyscall] is allocated without incrementing mm->map_count
That also looks strange, do you know why one is allocated without
incrementing it and another with?
--
Cyril Hrubis
chrubis@suse.cz
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition
2013-08-05 3:16 ` Zhouping Liu
@ 2013-08-06 7:08 ` Stanislav Kholmanskikh
0 siblings, 0 replies; 7+ messages in thread
From: Stanislav Kholmanskikh @ 2013-08-06 7:08 UTC (permalink / raw)
To: Zhouping Liu; +Cc: ltp-list, bob.picco
On 08/05/2013 07:16 AM, Zhouping Liu wrote:
> On 07/30/2013 09:47 PM, Stanislav Kholmanskikh wrote:
>> From: Stanislav kholmanskikh <stanislav.kholmanskikh@oracle.com>
>>
>> * kernel test for max_map_count_sysctl is:
>> /* Too many mappings? */
>> if (mm->map_count > sysctl_max_map_count)
>> return -ENOMEM;
>> so in LTP test map_count should be greater than max_map_count by 1
>>
>> * only [vsyscall] is allocated without incrementing mm->map_count
>>
>> Author: Bob Picco <bob.picco@oracle.com>
>>
>> Signed-off-by: Stanislav kholmanskikh
>> <stanislav.kholmanskikh@oracle.com>
>> ---
>> testcases/kernel/mem/tunable/max_map_count.c | 41
>> +++++++++++++++++--------
>> 1 files changed, 28 insertions(+), 13 deletions(-)
>>
>> diff --git a/testcases/kernel/mem/tunable/max_map_count.c
>> b/testcases/kernel/mem/tunable/max_map_count.c
>> index e948868..01fbe5e 100644
>> --- a/testcases/kernel/mem/tunable/max_map_count.c
>> +++ b/testcases/kernel/mem/tunable/max_map_count.c
>> @@ -14,20 +14,16 @@
>> * The program trys to invoke mmap() endless until triggering
>> MAP_FAILED,
>> * then read the process's maps file /proc/[pid]/maps, save the
>> line number
>> * to map_count variable, and compare it with
>> /proc/sys/vm/max_map_count,
>> - * map_count should less than max_map_count.
>> - * Note: There are two special vmas VDSO and VSYSCALL, which are
>> allocated
>> - * via install_special_mapping(), install_specail_mapping() allows
>> the VMAs
>> - * to be allocated and inserted without checking the
>> sysctl_map_map_count,
>> - * and each /proc/<pid>/maps has both at the end:
>> - * # cat /proc/self/maps
>> + * map_count should be greater than max_map_count by 1;
>> + *
>> + * Note: On some architectures there is a special vma VSYSCALL, which
>> + * is allocated without incrementing mm->map_count variable. On these
>> + * architectures each /proc/<pid>/maps has at the end:
>> * ...
>> * ...
>> - * 7fff7b9ff000-7fff7ba00000 r-xp 00000000 00:00 0 [vdso]
>
>
> Why you removed VDSO map? AFAIK VDSO map is also calculated by
> install_special_maping(),
> so the VMA is allocated and inserted without checking the
> sysctl_max_map_count.
>
Sorry, I've missed your message. Please take a look at my message to
Cyril about this.
> Thanks,
> Zhouping
>
>> * ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
>> [vsyscall]
>> *
>> - * so during comparing with map_count and /proc/sys/vm/max_map_count,
>> - * we should except the two special vmas from map_count:
>> - * map_count -= 2;
>> + * so we ignore this line during /proc/[pid]/maps reading.
>> *
>> *
>> ********************************************************************
>> * Copyright (C) 2012 Red Hat, Inc.
>> @@ -121,6 +117,21 @@ void cleanup(void)
>> TEST_CLEANUP;
>> }
>> +/* This is a filter to exclude map entries which aren't accounted
>> + * for in the vm_area_struct's map_count.
>> + */
>> +#if defined(__x86_64__) || defined(__x86__)
>> +static int filter_map(char *buf)
>> +{
>> + return strcmp(buf, "[vsyscall]") == 0;
>> +}
>> +#else
>> +static int filter_map(char *buf)
>> +{
>> + return 0;
>> +}
>> +#endif
>> +
>> static long count_maps(pid_t pid)
>> {
>> FILE *fp;
>> @@ -136,8 +147,7 @@ static long count_maps(pid_t pid)
>> while (getline(&line, &len, fp) != -1) {
>> /* exclude vdso and vsyscall */
>> if (sscanf(line, "%*p-%*p %*4s %*p %*2d:%*2d %*d %s", buf) ==
>> - 1 && ((strcmp(buf, "[vdso]") == 0) ||
>> - (strcmp(buf, "[vsyscall]") == 0)))
>> + 1 && filter_map(buf))
>> continue;
>> map_count++;
>> }
>> @@ -202,7 +212,12 @@ static void max_map_count_test(void)
>> tst_brkm(TBROK, cleanup, "child did not stopped");
>> map_count = count_maps(pid);
>> - if (map_count == max_maps)
>> + /* Note max_maps will be exceeded by one for
>> + * the sysctl setting of max_map_count. This
>> + * is the mm failure point at the time of
>> + * writing this COMMENT!
>> + */
>> + if (map_count == (max_maps + 1))
>> tst_resm(TPASS, "%ld map entries in total "
>> "as expected.", max_maps);
>> else
>
------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition
[not found] ` <520A34B4.3020502@oracle.com>
@ 2013-08-13 14:52 ` chrubis
[not found] ` <520AFFFB.6040708@redhat.com>
1 sibling, 0 replies; 7+ messages in thread
From: chrubis @ 2013-08-13 14:52 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: ltp-list, bob.picco
Hi!
> Guys, could anybody approve or disapprove this? I'm not sure where to go
> to complete this subject.
I have this in my TODO, stay tuned.
--
Cyril Hrubis
chrubis@suse.cz
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [LTP] [PATCH] max_map_count: corrected max_map_count condition
[not found] ` <520B3FC4.5020809@redhat.com>
@ 2013-08-19 1:32 ` Wanlong Gao
0 siblings, 0 replies; 7+ messages in thread
From: Wanlong Gao @ 2013-08-19 1:32 UTC (permalink / raw)
To: Stanislav Kholmanskikh; +Cc: ltp-list, bob.picco
On 08/14/2013 04:28 PM, Zhouping Liu wrote:
> On 08/14/2013 01:32 PM, Stanislav Kholmanskikh wrote:
>>
>> On 08/14/2013 07:56 AM, Zhouping Liu wrote:
>>> On 08/13/2013 09:29 PM, Stanislav Kholmanskikh wrote:
>>>>
>>>> On 08/06/2013 10:52 AM, Stanislav Kholmanskikh wrote:
>>>>> On 08/05/2013 07:41 PM, chrubis@suse.cz wrote:
>>>>>> Hi!
>>>>> Hi, Cyril.
>>>>>>> * kernel test for max_map_count_sysctl is:
>>>>>>> /* Too many mappings? */
>>>>>>> if (mm->map_count > sysctl_max_map_count)
>>>>>>> return -ENOMEM;
>>>>>> Hmm, that looks like we allow the map_count to became one greater
>>>>>> than
>>>>>> max_map_count, is this known bug?
>>>>> I'm not sure whether this is a bug or feature but in fact mm/mmap.c
>>>>> contains
>>>>> this strict condition.
>>>>>
>>>>>>> so in LTP test map_count should be greater than max_map_count
>>>>>>> by 1
>>>>>>>
>>>>>>> * only [vsyscall] is allocated without incrementing mm->map_count
>>>>>> That also looks strange, do you know why one is allocated without
>>>>>> incrementing it and another with?
>>>>>>
>>>>> [vdso] is allocated this way:
>>>>> 1) load_elf_binary (fs/binfmt_elf.c)
>>>>> 2) arch_setup_additional_pages (arch/x86/vdso/vdso32-setup.c)
>>>>> 3) install_special_mapping (mm/mmap.c)
>>>>> 4) insert_vm_struct (mm/mmap.c)
>>>>> 5) vma_link (mm/mmap.c) increases mm->map_count++
>>>
>>> Sorry for lately replying, as I'm a little busy these days...
>>>
>>> we all know (you have explained) VDSO vma is inserted by
>>> install_special_mapping(), and the sysctl_max_map_count
>>> don't check the special vma, that's the reason why map_count is to
>>> became one greater than max_map_count,
>>
>> The function install_special_mapping() __does__ increase mm->map_count.
>> [vdso] is mapped one of the first vmas when a binary is executed so
>> it's not a problem or bug that sysctl_max_map_count is not checked in
>> install_special_mapping().
>
> yeah, it sounds reasonable.
>
>>
>> So we should not filter out [vdso] string from /proc/[pid]/maps (as we
>> have in git test version).
>>
>> I mean that the reason why map_count could be one greater than
>> max_map_count is not related to [vdso] or [vsyscall]. It's caused by
>> the kernel
>> test I posted above.
>
> I think so after I recheck the code again and again... sorry for the
> misunderstanding.
>
> so your patch looks good for me.
>
> Reviewed-by: Zhouping Liu <zliu@redhat.com>
Applied, thank you all involved.
Wanlong Gao
>
> Thanks,
> Zhouping
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> Ltp-list mailing list
> Ltp-list@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ltp-list
>
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2013-08-19 1:33 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-30 13:47 [LTP] [PATCH] max_map_count: corrected max_map_count condition Stanislav Kholmanskikh
2013-07-31 3:03 ` Caspar Zhang
2013-08-05 3:16 ` Zhouping Liu
2013-08-06 7:08 ` Stanislav Kholmanskikh
2013-08-05 15:41 ` chrubis
[not found] ` <52009D26.4030609@oracle.com>
[not found] ` <520A34B4.3020502@oracle.com>
2013-08-13 14:52 ` chrubis
[not found] ` <520AFFFB.6040708@redhat.com>
[not found] ` <520B1666.6010808@oracle.com>
[not found] ` <520B3FC4.5020809@redhat.com>
2013-08-19 1:32 ` Wanlong Gao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox