[LTP] LTP: futex_wake04 hangs forever on i386

[Rafael David Tinoco <rafael.tinoco@linaro.org>]

>> And there wasn't a second thread task id inside:
>>
>> /proc/<pid>/task/{<pid>, <tid1>, <tid2>}
>>
>> like it should.
>>
>> Likely the task creation (because of error ? check last part) logic here
>> was faster than wait_for_threads() logic could expect... causing a race
>> for the test's logic.
> 
> That shouldn't really happen, the wait_for_threads(2) function is called
> in a loop until there are two sleeping threads under the
> /proc/$pid/task/ directory (minus the main thread). So unless there is a
> problem with starting a thread or locking on a futex the loop will end
> eventually and the futexes are unlocked only after this loop finishes.

Yes, I'll check why.

>> Reading hugetlb_report_meminfo() in hugetlb.c, I am not sure (struct
>> hstat *h)->nr_huge_pages should change that much (through new hugepages
>> being asked for, sysctl, or numa balance, among other options). I'll try
>> to trace this tomorrow to see who is touching the HugePages_Total during
>> the test.
> 
> That is because the test modifies the size of the huge pages pool itself
> in the test setup so that it can run on a systems where the default is
> set to 0. I guess that we should change it so that it check if the
> orig_hugepages is non-zero or not and only change the value if it's
> zero.

Hum, I missed that =), tks. Will get back to you soon on this.