Re: Hangs in libhugetlbfs tests in -next

From: Catalin Marinas
Date: Thu Jan 29 2015 - 11:42:31 EST


On Thu, Jan 29, 2015 at 04:02:27PM +0000, Steve Capper wrote:
> On 28 January 2015 at 15:24, Mark Brown <broonie@xxxxxxxxxx> 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?

pte_file() check is removed in commit 7823d501c417fc but I can't tell
exactly why, I haven't followed the patch series. But Mel's commit
removes pte_present_nonuma() entirely, I think it should have been
replaced with pte_present().

--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/