public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Jan Stancek <jstancek@redhat.com>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH] max_map_count: fix error by using runtime check
Date: Wed, 23 Mar 2016 06:22:39 -0400 (EDT)	[thread overview]
Message-ID: <1242994016.13404335.1458728559657.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <56F259A7.1080908@huawei.com>





----- Original Message -----
> From: "Cui Bixuan" <cuibixuan@huawei.com>
> To: "Cyril Hrubis" <chrubis@suse.cz>
> Cc: zhuyanpeng@huawei.com, zhanyongming@huawei.com, ltp@lists.linux.it
> Sent: Wednesday, 23 March, 2016 9:53:59 AM
> Subject: [LTP]  [PATCH] max_map_count: fix error by using runtime check
> 
> There is a error when compile the case to 32bit binary and
> run it on 64bit arm kernel, which will wrongly skip one mapping.
> 
> Do runtimg check using the machine from uname(2) to fix it.
> 
> Signed-off-by: Cui Bixuan <cuibixuan@huawei.com>
> Signed-off-by: Cyril Hrubis <chrubis@suse.cz>
> ---
>  testcases/kernel/mem/tunable/max_map_count.c | 32
>  +++++++++++++++++-----------
>  1 file changed, 19 insertions(+), 13 deletions(-)
> 
> diff --git a/testcases/kernel/mem/tunable/max_map_count.c
> b/testcases/kernel/mem/tunable/max_map_count.c
> index 295a47b..a69e560 100644
> --- a/testcases/kernel/mem/tunable/max_map_count.c
> +++ b/testcases/kernel/mem/tunable/max_map_count.c
> @@ -59,6 +59,7 @@
>  #include <stdbool.h>
>  #include <stdio.h>
>  #include <stdlib.h>
> +#include <sys/utsname.h>
>  #include "test.h"
>  #include "mem.h"
> 
> @@ -70,6 +71,7 @@ int TST_TOTAL = 1;
> 
>  static long old_max_map_count;
>  static long old_overcommit;
> +struct utsname un;
> 
>  static long count_maps(pid_t pid);
>  static void max_map_count_test(void);
> @@ -104,6 +106,9 @@ void setup(void)
>  	old_max_map_count = get_sys_tune("max_map_count");
>  	old_overcommit = get_sys_tune("overcommit_memory");
>  	set_sys_tune("overcommit_memory", 2, 1);
> +
> +	if (uname(&un) != 0)
> +		tst_brkm(TBROK | TERRNO, NULL, "uname error");
>  }
> 
>  void cleanup(void)
> @@ -124,19 +129,20 @@ static bool filter_map(const char *line)
>  	if (ret != 1)
>  		return false;
> 
> -#if defined(__x86_64__) || defined(__x86__)
> -	/* On x86, there's an old compat vsyscall page */
> -	if (!strcmp(buf, "[vsyscall]"))
> -		return true;
> -#elif defined(__ia64__)
> -	/* On ia64, the vdso is not a proper mapping */
> -	if (!strcmp(buf, "[vdso]"))
> -		return true;
> -#elif defined(__arm__)
> -	/* Older arm kernels didn't label their vdso maps */
> -	if (!strncmp(line, "ffff0000-ffff1000", 17))
> -		return true;
> -#endif
> +	if (strstr(un.machine, "x86") != NULL)

What if uname contains i386?

Can we relax the pass condition to allow map_count to be
within some tolerance? Then we wouldn't have to worry so much about
all arch specifics.


> +		/* On x86, there's an old compat vsyscall page */
> +		if (!strcmp(buf, "[vsyscall]"))
> +			return true;
> +
> +	if (strstr(un.machine, "ia64") != NULL)
> +		/* On ia64, the vdso is not a proper mapping */
> +		if (!strcmp(buf, "[vdso]"))
> +			return true;
> +
> +	if (strstr(un.machine, "armv") != NULL)
> +		/* Older arm kernels didn't label their vdso maps */
> +		if (!strncmp(line, "ffff0000-ffff1000", 17))
> +			return true;
> 
>  	return false;
>  }
> --
> 1.8.3.4
> 
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp
> 

  reply	other threads:[~2016-03-23 10:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-07 11:08 [LTP] max_map_count fail in arm64 system which support lib32 Cui Bixuan
2016-03-22 10:29 ` Cyril Hrubis
2016-03-22 13:49   ` Cui Bixuan
2016-03-22 14:28     ` Cyril Hrubis
2016-03-23  8:53       ` [LTP] [PATCH] max_map_count: fix error by using runtime check Cui Bixuan
2016-03-23 10:22         ` Jan Stancek [this message]
2016-03-23 11:59           ` Cui Bixuan
2016-03-31 12:07           ` Cyril Hrubis
2016-04-05 11:47             ` Cui Bixuan
2016-04-11 17:03               ` Cyril Hrubis
2016-04-12  7:15                 ` [LTP] [PATCH v2] " Cui Bixuan
2016-04-12 13:07                   ` Cyril Hrubis
2016-03-23  9:00       ` [LTP] max_map_count fail in arm64 system which support lib32 Cui Bixuan
2016-12-16  8:25 ` [LTP] [PATCH] max_map_count: fix a mistake and support it for aarch64_be Cui Bixuan
2016-12-16 10:15   ` [LTP] we can ignore it and discuss the problem at 'Fix wrong checking of aarch64' from the_hoang0709@yahoo.com Cui Bixuan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1242994016.13404335.1458728559657.JavaMail.zimbra@redhat.com \
    --to=jstancek@redhat.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox