All of lore.kernel.org
 help / color / mirror / Atom feed
* [LTP] [PATCH 1/2] ltp: typos correction
@ 2017-10-25  3:30 Li Wang
  2017-10-25  3:30 ` [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch Li Wang
  2017-10-25  7:16 ` [LTP] [PATCH 1/2] ltp: typos correction Cyril Hrubis
  0 siblings, 2 replies; 10+ messages in thread
From: Li Wang @ 2017-10-25  3:30 UTC (permalink / raw)
  To: ltp

Signed-off-by: Li Wang <liwang@redhat.com>
---
 include/tst_safe_macros.h                                     | 2 +-
 testcases/kernel/syscalls/clock_nanosleep/clock_nanosleep02.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/tst_safe_macros.h b/include/tst_safe_macros.h
index 9562005..ed9c73c 100644
--- a/include/tst_safe_macros.h
+++ b/include/tst_safe_macros.h
@@ -406,7 +406,7 @@ static inline sighandler_t safe_signal(const char *file, const int lineno,
 #define SAFE_EXECL(file, arg, ...) do {				\
        execl((file), (arg), ##__VA_ARGS__);			\
        tst_brk_(__FILE__, __LINE__, TBROK | TERRNO,		\
-                "execlp(%s, %s, ...) failed", file, arg); 	\
+                "execl(%s, %s, ...) failed", file, arg); 	\
        } while (0)
 
 int safe_getpriority(const char *file, const int lineno, int which, id_t who);
diff --git a/testcases/kernel/syscalls/clock_nanosleep/clock_nanosleep02.c b/testcases/kernel/syscalls/clock_nanosleep/clock_nanosleep02.c
index f114013..f52d853 100644
--- a/testcases/kernel/syscalls/clock_nanosleep/clock_nanosleep02.c
+++ b/testcases/kernel/syscalls/clock_nanosleep/clock_nanosleep02.c
@@ -36,7 +36,7 @@ int sample_fn(int clk_id, long long usec)
 
 	if (TEST_RETURN != 0) {
 		tst_res(TFAIL | TERRNO,
-			"nanosleep() returned %li", TEST_RETURN);
+			"clock_nanosleep() returned %li", TEST_RETURN);
 		return 1;
 	}
 
@@ -44,6 +44,6 @@ int sample_fn(int clk_id, long long usec)
 }
 
 static struct tst_test test = {
-	.tid = "nanosleep()",
+	.tid = "clock_nanosleep()",
 	.sample = sample_fn,
 };
-- 
2.9.3


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

* [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch
  2017-10-25  3:30 [LTP] [PATCH 1/2] ltp: typos correction Li Wang
@ 2017-10-25  3:30 ` Li Wang
  2017-11-08  8:13   ` Jan Stancek
  2017-10-25  7:16 ` [LTP] [PATCH 1/2] ltp: typos correction Cyril Hrubis
  1 sibling, 1 reply; 10+ messages in thread
From: Li Wang @ 2017-10-25  3:30 UTC (permalink / raw)
  To: ltp

The kernel commit 1aea9b3f92 (s390/mm: implement 5 level pages tables)
enlarge the maximum address in the tasks address space from (1UL << 53)
to (-PAGE_SIZE) on s390 platform.

We have to increase the HIGH_ADDR in ltp testcases accordingly otherwise
that would be failed with succeeded mmap into high region:

mmap15.c:
mmap15  1  TFAIL  :  mmap15.c:77: mmap into high region succeeded unexpectedly

mmapstress03.c:
mmapstress03: errno = 25: really large mmap didn't fail
mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit
mmapstress03    1  TFAIL  :  mmapstress03.c:212: Test failed

Signed-off-by: Li Wang <liwang@redhat.com>
---
 testcases/kernel/mem/mmapstress/mmapstress03.c | 3 +--
 testcases/kernel/syscalls/mmap/mmap15.c        | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/testcases/kernel/mem/mmapstress/mmapstress03.c b/testcases/kernel/mem/mmapstress/mmapstress03.c
index 0012eeb..f8541e1 100644
--- a/testcases/kernel/mem/mmapstress/mmapstress03.c
+++ b/testcases/kernel/mem/mmapstress/mmapstress03.c
@@ -141,8 +141,7 @@ int main(void)
 	}
 
 	/* Ask for a ridiculously large mmap region at a high address */
-	if (mmap((void*) (((uintptr_t)1) << ((sizeof(void*)<<3) - 1)) - pagesize,
-		 (size_t) ((1ULL << (kernel_bits - 1)) - pagesize),
+	if (mmap((void*) (-pagesize), (size_t) ((1ULL << (kernel_bits - 1)) - pagesize),
 		 PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_FIXED | MAP_SHARED,
 		 0, 0)
 	    != (void*) - 1) {
diff --git a/testcases/kernel/syscalls/mmap/mmap15.c b/testcases/kernel/syscalls/mmap/mmap15.c
index 7e917bd..e1dbca2 100644
--- a/testcases/kernel/syscalls/mmap/mmap15.c
+++ b/testcases/kernel/syscalls/mmap/mmap15.c
@@ -43,7 +43,7 @@ int TST_TOTAL = 1;
 #ifdef __ia64__
 # define HIGH_ADDR (void *)(0xa000000000000000UL)
 #else
-# define HIGH_ADDR (void *)(1L << 53)
+# define HIGH_ADDR (void *)(0xfffffffffffff000UL)
 #endif
 
 static long map_sz;
-- 
2.9.3


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

* [LTP] [PATCH 1/2] ltp: typos correction
  2017-10-25  3:30 [LTP] [PATCH 1/2] ltp: typos correction Li Wang
  2017-10-25  3:30 ` [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch Li Wang
@ 2017-10-25  7:16 ` Cyril Hrubis
  2017-10-25  7:34   ` Li Wang
  1 sibling, 1 reply; 10+ messages in thread
From: Cyril Hrubis @ 2017-10-25  7:16 UTC (permalink / raw)
  To: ltp

Hi!
>  static struct tst_test test = {
> -	.tid = "nanosleep()",
> +	.tid = "clock_nanosleep()",
>  	.sample = sample_fn,

The .tid field should not be set in the tests since a5bf5254ca9
(tst_test.c: set the test id automatically).

Just remove it from the test structure here.

I guess that we may as well remove it from the test structure completely
and keep it hidden in the test library.

-- 
Cyril Hrubis
chrubis@suse.cz

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

* [LTP] [PATCH 1/2] ltp: typos correction
  2017-10-25  7:16 ` [LTP] [PATCH 1/2] ltp: typos correction Cyril Hrubis
@ 2017-10-25  7:34   ` Li Wang
  0 siblings, 0 replies; 10+ messages in thread
From: Li Wang @ 2017-10-25  7:34 UTC (permalink / raw)
  To: ltp

On Wed, Oct 25, 2017 at 3:16 PM, Cyril Hrubis <chrubis@suse.cz> wrote:
> Hi!
>>  static struct tst_test test = {
>> -     .tid = "nanosleep()",
>> +     .tid = "clock_nanosleep()",
>>       .sample = sample_fn,
>
> The .tid field should not be set in the tests since a5bf5254ca9
> (tst_test.c: set the test id automatically).

Yes!

I thought if there are some special meaning there before. Because you
put the function
tst_timer_test_setup(tst_test) in the front of get_tid(argv) in tst_test.c.

>
> Just remove it from the test structure here.
>
> I guess that we may as well remove it from the test structure completely
> and keep it hidden in the test library.

Agree!

if so, the code changes in library should be like:

$ git diff
diff --git a/lib/tst_test.c b/lib/tst_test.c
index f8b3fb4..a8a2115 100644
--- a/lib/tst_test.c
+++ b/lib/tst_test.c
@@ -688,12 +688,12 @@ static void do_setup(int argc, char *argv[])

        assert_test_fn();

-       if (tst_test->sample)
-               tst_test = tst_timer_test_setup(tst_test);
-
        if (!tst_test->tid)
                tst_test->tid = get_tid(argv);

+       if (tst_test->sample)
+               tst_test = tst_timer_test_setup(tst_test);
+
        parse_opts(argc, argv);

        if (tst_test->needs_root && geteuid() != 0)


If you don't have more suggestion, I will re-write a new patch V2 do that.



-- 
Li Wang
liwang@redhat.com

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

* [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch
  2017-10-25  3:30 ` [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch Li Wang
@ 2017-11-08  8:13   ` Jan Stancek
  2017-11-10  3:18     ` Li Wang
                       ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Jan Stancek @ 2017-11-08  8:13 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> The kernel commit 1aea9b3f92 (s390/mm: implement 5 level pages tables)
> enlarge the maximum address in the tasks address space from (1UL << 53)
> to (-PAGE_SIZE) on s390 platform.
> 
> We have to increase the HIGH_ADDR in ltp testcases accordingly otherwise
> that would be failed with succeeded mmap into high region:
> 
> mmap15.c:
> mmap15  1  TFAIL  :  mmap15.c:77: mmap into high region succeeded
> unexpectedly
> 
> mmapstress03.c:
> mmapstress03: errno = 25: really large mmap didn't fail
> mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit

                                     Isn't this the problem? ^^

> mmapstress03    1  TFAIL  :  mmapstress03.c:212: Test failed
> 

Regards,
Jan

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

* [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch
  2017-11-08  8:13   ` Jan Stancek
@ 2017-11-10  3:18     ` Li Wang
  2017-11-10  7:45       ` Jan Stancek
  2017-11-10  6:04     ` Li Wang
  2017-11-10  6:04     ` Li Wang
  2 siblings, 1 reply; 10+ messages in thread
From: Li Wang @ 2017-11-10  3:18 UTC (permalink / raw)
  To: ltp

On Wed, Nov 8, 2017 at 4:13 PM, Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
>> The kernel commit 1aea9b3f92 (s390/mm: implement 5 level pages tables)
>> enlarge the maximum address in the tasks address space from (1UL << 53)
>> to (-PAGE_SIZE) on s390 platform.
>>
>> We have to increase the HIGH_ADDR in ltp testcases accordingly otherwise
>> that would be failed with succeeded mmap into high region:
>>
>> mmap15.c:
>> mmap15  1  TFAIL  :  mmap15.c:77: mmap into high region succeeded
>> unexpectedly
>>
>> mmapstress03.c:
>> mmapstress03: errno = 25: really large mmap didn't fail
>> mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit
>
>                                      Isn't this the problem? ^^

No, It is an misinformation (for s390 platform) from LTP
tst_kernel_bits() function.

====
# uname -r
3.10.0-514.el7.s390x

# readelf -h mmapstress03
ELF Header:
  Magic:   7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, big endian
  Version:                           1 (current)
...

# ./mmapstress03
mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit
mmapstress03    1  TPASS  :  Test passed



I'd suggest to fix this as:

$ git diff
diff --git a/lib/tst_kernel.c b/lib/tst_kernel.c
index fd648b1..6d6fd38 100644
--- a/lib/tst_kernel.c
+++ b/lib/tst_kernel.c
@@ -35,7 +35,8 @@ int tst_kernel_bits(void)
         * ARM64 (aarch64) defines 32-bit compatibility modes as
         * armv8l and armv8b (little and big endian).
         */
-       if (!strcmp(buf.machine, "armv8l") || !strcmp(buf.machine, "armv8b"))
+       if (!strcmp(buf.machine, "armv8l") || !strcmp(buf.machine, "armv8b")
+                       || !strcmp(buf.machine, "s390x"))
                kernel_bits = 64;

        tst_resm(TINFO, "uname.machine=%s kernel is %ibit",



-- 
Li Wang
liwang@redhat.com

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

* [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch
  2017-11-08  8:13   ` Jan Stancek
  2017-11-10  3:18     ` Li Wang
@ 2017-11-10  6:04     ` Li Wang
  2017-11-10  6:04     ` Li Wang
  2 siblings, 0 replies; 10+ messages in thread
From: Li Wang @ 2017-11-10  6:04 UTC (permalink / raw)
  To: ltp

On Wed, Nov 8, 2017 at 4:13 PM, Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
>> The kernel commit 1aea9b3f92 (s390/mm: implement 5 level pages tables)
>> enlarge the maximum address in the tasks address space from (1UL << 53)
>> to (-PAGE_SIZE) on s390 platform.
>>
>> We have to increase the HIGH_ADDR in ltp testcases accordingly otherwise
>> that would be failed with succeeded mmap into high region:
>>
>> mmap15.c:
>> mmap15  1  TFAIL  :  mmap15.c:77: mmap into high region succeeded
>> unexpectedly
>>
>> mmapstress03.c:
>> mmapstress03: errno = 25: really large mmap didn't fail
>> mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit
>
>                                      Isn't this the problem? ^^

I did more test on s390x platform with upstream kernel-v4.14-rc8. It
has been proved that the mmapstress03.c failures was only caused by
wrong kernel_bits value.

So I think we have no need to raise the mmap high address in
mmapstress03.c test, but mmap15 testcase should be fixed at least.

Just adding debugging sentence temporarily to show something:
==============
--- a/testcases/kernel/mem/mmapstress/mmapstress03.c
+++ b/testcases/kernel/mem/mmapstress/mmapstress03.c
@@ -140,6 +140,14 @@ int main(void)
                anyfail();
        }

+# define HIGH_ADDR_MAX (void *)(-pagesize)
+printf("HIGH_ADDR_MAX = %p\n", HIGH_ADDR_MAX);
+
+void * map_addr = (void*) (((uintptr_t)1) << ((sizeof(void*)<<3) -
1)) - pagesize;
+size_t map_size = (size_t) (1ULL << (kernel_bits - 1)) - pagesize;
+printf("map_addr = %p\n", map_addr);
+printf("map_size = %p\n", map_size);
+
        /* Ask for a ridiculously large mmap region@a high address */
        if (mmap((void*) (((uintptr_t)1) << ((sizeof(void*)<<3) - 1))
- pagesize,
                 (size_t) ((1ULL << (kernel_bits - 1)) - pagesize),



============
# uname -rm
4.14.0-rc8+ s390x

# ./mmapstress03
mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 64bit
HIGH_ADDR_MAX = 0xfffffffffffff000
map_addr = 0x7ffffffffffff000
map_size = 0x7ffffffffffff000
mmapstress03    1  TPASS  :  Test passed


I'd like to format two new patches for kernel-bit detection and mmap15 issue.

-- 
Li Wang
liwang@redhat.com

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

* [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch
  2017-11-08  8:13   ` Jan Stancek
  2017-11-10  3:18     ` Li Wang
  2017-11-10  6:04     ` Li Wang
@ 2017-11-10  6:04     ` Li Wang
  2 siblings, 0 replies; 10+ messages in thread
From: Li Wang @ 2017-11-10  6:04 UTC (permalink / raw)
  To: ltp

On Wed, Nov 8, 2017 at 4:13 PM, Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
>> The kernel commit 1aea9b3f92 (s390/mm: implement 5 level pages tables)
>> enlarge the maximum address in the tasks address space from (1UL << 53)
>> to (-PAGE_SIZE) on s390 platform.
>>
>> We have to increase the HIGH_ADDR in ltp testcases accordingly otherwise
>> that would be failed with succeeded mmap into high region:
>>
>> mmap15.c:
>> mmap15  1  TFAIL  :  mmap15.c:77: mmap into high region succeeded
>> unexpectedly
>>
>> mmapstress03.c:
>> mmapstress03: errno = 25: really large mmap didn't fail
>> mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit
>
>                                      Isn't this the problem? ^^

I did some more test on s390x platform with upstream kernel-v4.14-rc8.
Seems the mmapstress03.c failures was caused by wrong kernel_bits value.

# uname -rm
4.14.0-rc8+ s390x






-- 
Li Wang
liwang@redhat.com

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

* [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch
  2017-11-10  3:18     ` Li Wang
@ 2017-11-10  7:45       ` Jan Stancek
  2017-11-10  8:19         ` Li Wang
  0 siblings, 1 reply; 10+ messages in thread
From: Jan Stancek @ 2017-11-10  7:45 UTC (permalink / raw)
  To: ltp



----- Original Message -----
> On Wed, Nov 8, 2017 at 4:13 PM, Jan Stancek <jstancek@redhat.com> wrote:
> >
> >
> > ----- Original Message -----
> >> The kernel commit 1aea9b3f92 (s390/mm: implement 5 level pages tables)
> >> enlarge the maximum address in the tasks address space from (1UL << 53)
> >> to (-PAGE_SIZE) on s390 platform.
> >>
> >> We have to increase the HIGH_ADDR in ltp testcases accordingly otherwise
> >> that would be failed with succeeded mmap into high region:
> >>
> >> mmap15.c:
> >> mmap15  1  TFAIL  :  mmap15.c:77: mmap into high region succeeded
> >> unexpectedly
> >>
> >> mmapstress03.c:
> >> mmapstress03: errno = 25: really large mmap didn't fail
> >> mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit
> >
> >                                      Isn't this the problem? ^^
> 
> No, It is an misinformation (for s390 platform) from LTP
> tst_kernel_bits() function.

That number is used to calculate size for mmap in mmapstress03.
Are you saying that after commit 1aea9b3f92, mmap for size "(1 << 63) - pagesize"
will succeed?

Regards,
Jan

> 
> ====
> # uname -r
> 3.10.0-514.el7.s390x
> 
> # readelf -h mmapstress03
> ELF Header:
>   Magic:   7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
>   Class:                             ELF64
>   Data:                              2's complement, big endian
>   Version:                           1 (current)
> ...
> 
> # ./mmapstress03
> mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit
> mmapstress03    1  TPASS  :  Test passed
> 
> 
> 
> I'd suggest to fix this as:
> 
> $ git diff
> diff --git a/lib/tst_kernel.c b/lib/tst_kernel.c
> index fd648b1..6d6fd38 100644
> --- a/lib/tst_kernel.c
> +++ b/lib/tst_kernel.c
> @@ -35,7 +35,8 @@ int tst_kernel_bits(void)
>          * ARM64 (aarch64) defines 32-bit compatibility modes as
>          * armv8l and armv8b (little and big endian).
>          */
> -       if (!strcmp(buf.machine, "armv8l") || !strcmp(buf.machine, "armv8b"))
> +       if (!strcmp(buf.machine, "armv8l") || !strcmp(buf.machine, "armv8b")
> +                       || !strcmp(buf.machine, "s390x"))
>                 kernel_bits = 64;
> 
>         tst_resm(TINFO, "uname.machine=%s kernel is %ibit",
> 
> 
> 
> --
> Li Wang
> liwang@redhat.com
> 

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

* [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch
  2017-11-10  7:45       ` Jan Stancek
@ 2017-11-10  8:19         ` Li Wang
  0 siblings, 0 replies; 10+ messages in thread
From: Li Wang @ 2017-11-10  8:19 UTC (permalink / raw)
  To: ltp

On Fri, Nov 10, 2017 at 3:45 PM, Jan Stancek <jstancek@redhat.com> wrote:
>
>
> ----- Original Message -----
>> On Wed, Nov 8, 2017 at 4:13 PM, Jan Stancek <jstancek@redhat.com> wrote:
>> >
>> >
>> > ----- Original Message -----
>> >> The kernel commit 1aea9b3f92 (s390/mm: implement 5 level pages tables)
>> >> enlarge the maximum address in the tasks address space from (1UL << 53)
>> >> to (-PAGE_SIZE) on s390 platform.
>> >>
>> >> We have to increase the HIGH_ADDR in ltp testcases accordingly otherwise
>> >> that would be failed with succeeded mmap into high region:
>> >>
>> >> mmap15.c:
>> >> mmap15  1  TFAIL  :  mmap15.c:77: mmap into high region succeeded
>> >> unexpectedly
>> >>
>> >> mmapstress03.c:
>> >> mmapstress03: errno = 25: really large mmap didn't fail
>> >> mmapstress03    0  TINFO  :  uname.machine=s390x kernel is 32bit
>> >
>> >                                      Isn't this the problem? ^^
>>
>> No, It is an misinformation (for s390 platform) from LTP
>> tst_kernel_bits() function.
>
> That number is used to calculate size for mmap in mmapstress03.
> Are you saying that after commit 1aea9b3f92, mmap for size "(1 << 63) - pagesize"
> will succeed?

Hmm no, mmap for size "(1 << 63) - pagesize" still failed as we
expected on kernel-v4.14-rc8.
Indeed, now we have no need to change anything in mmapstress03.c.


-- 
Li Wang
liwang@redhat.com

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

end of thread, other threads:[~2017-11-10  8:19 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-25  3:30 [LTP] [PATCH 1/2] ltp: typos correction Li Wang
2017-10-25  3:30 ` [LTP] [PATCH 2/2] mm: enlarge mmap HIGH_ADDR value for s390 arch Li Wang
2017-11-08  8:13   ` Jan Stancek
2017-11-10  3:18     ` Li Wang
2017-11-10  7:45       ` Jan Stancek
2017-11-10  8:19         ` Li Wang
2017-11-10  6:04     ` Li Wang
2017-11-10  6:04     ` Li Wang
2017-10-25  7:16 ` [LTP] [PATCH 1/2] ltp: typos correction Cyril Hrubis
2017-10-25  7:34   ` Li Wang

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.