lkml.org 
[lkml]   [2015]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Hangs in libhugetlbfs tests in -next
From
On 28 January 2015 at 15:24, Mark Brown <broonie@kernel.org> wrote:
> For at least the past couple of days tests of libhugetlbfs have been
> hanging on mustang in the mlock test running ARMv8 defconfig with both
> 32 bit and 64 bit userspace - after the mprotect test (the one before
> it) we get no console output for several hours so it appears that the
> test has deadlocked. The tail of the log is:
>
> | find_path (2M: 64): PASS
> | unlinked_fd (2M: 64): PASS
> | readback (2M: 64): PASS
> | truncate (2M: 64): PASS
> | shared (2M: 64): PASS
> | mprotect (2M: 64): PASS
>
> and then a timeout.
>
> This may be a generic bug but my ability to run these tests on other
> platforms with huge page support using the infrastructure I'm using is
> limited so I've not been able to test elsewhere and confirm.

I've bisected this problem down to commit:
f2c0507 mm: remove remaining references to NUMA hinting bits and helpers

Essentially the mlock unit test from libhugetlbfs then fails with
hugetlbf_fault being called in an infinite loop.

After this commit is applied we get the following definition of:
static inline int is_swap_pte(pte_t pte)
{
return !pte_none(pte);
}

rather than:
static inline int is_swap_pte(pte_t pte)
{
return !pte_none(pte) && !pte_present_nonuma(pte);
}

(note here that pte_present_nonuma == pte_present on arm64)

I think this is a typo in the patch, as entries should be checked for
present before being determined to be swap or file?

Cheers,
--
Steve


\
 
 \ /
  Last update: 2015-01-29 17:21    [W:0.209 / U:0.472 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site