lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Fri, 9 Jan 2015 00:30:06 +0300
From:	Andrey Skvortsov <andrej.skvortzov@...il.com>
To:	Shuah Khan <shuahkh@....samsung.com>
Cc:	Konstantin Khlebnikov <koct9i@...il.com>,
	linux-api@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] selftests/vm: fix link error for transhuge-stress test

On Thu, Jan 08, 2015 at 08:55:25AM -0700, Shuah Khan wrote:

> On 01/07/2015 01:10 PM, Andrey Skvortsov wrote:
> > man page for clock_gettime says 'Link with -lrt'. So I think the
> > error message is correct.
> > 
> 
> Thanks for fixing it. Applied to linux-kselftest fixes branch
> 


Hi Shuah,

thanks for taking the patch.

sorry for the late reply. I've just checked e-mail. Different
timezone. =)

I have couple questions about selftests/vm/hugetlbfstest. It is called by
make run_tests, but fails always on my machine.
What does it actually test? if I understand the code right,
it tests whether RSS (read from /proc/self/statm) grows/shrinks not much during
allocation/deallocation of 16Mb. 

Here are couple of questions about some tests in the code.
1)
hugetlbfstest.c:75
	do_mmap(-1, MAP_ANONYMOUS, 1);

it does not use hugetlbfs. So it does not correspond to the
actual test name. That confused me a little. Does it test usage of
transparent huge pages? 

2) 
hugetlbfstest.c:78
	do_mmap(hugefd, 0, 1);

Despite the fact, that hugefd is open at wrong location
(run_tests script mounts hugetlbfs at ./huge) the test actually does
use hugetlbfs. Unfortunately on my machine it fails always too. 
RSS does not grow after allocation, but is the same as before.
So assertion 'llabs(after - before - length) < 0x40000' fails.
But hugepages are definitely allocated, I can see that HugePages_Free decreases in
/proc/meminfo. To find this out I placed delays in the test code.
Does rss field in /proc/statm counts only normal non-huge pages? 

        
-- 
Best regards,
Andrey Skvortsov

Secure e-mail with gnupg: See http://www.gnupg.org/
PGP Key ID: 0x57A3AEAD



Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ