Hangs in libhugetlbfs tests in -next
Subsystems (2)
Mark Brown
maintainerFor 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/df17921d/attachment.sig>
Quoted 13 lines · Mark Brown
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
Quoted 5 lines
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 reproduced this on Juno, it looks like hugtlb_fault is being called repeatedly in the mlock test.
I'll investigate further.
Cheers,
Signature · 1 line
Steve
Quoted 13 lines · Mark Brown
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
Quoted 5 lines
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,
Signature · 1 line
Steve
Quoted 34 lines · Steve Capper
Quoted 13 lines · Mark Brown
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): PASSQuoted 5 lines
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 helpersEssentially the mlock unit test from libhugetlbfs then fails with
hugetlbf_faultbeing called in an infinite loop.After this commit is applied we get the following definition of:
static inline intis_swap_pte(pte_t pte){ return !pte_none(pte); }rather than:
static inline intis_swap_pte(pte_t pte)
Quoted 8 lines
{ return !pte_none(pte) && !pte_present_nonuma(pte); }(note here that
pte_present_nonuma==pte_presenton 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().
Signature · 1 line
Catalin
PATCH 1/1 mm: remove remaining references to NUMA hinting bits and helpers -fix
In reply to Steve CapperThe patch "mm: remove remaining references to NUMA hinting bits and helpers" was meant to remove NUMA hinting bits and helpers but broke is_swap_pte.
Quoted 1 line
From the original bug report
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
This patch should address the problem and is a fix to the mmotm patch mm-remove-remaining-references-to-numa-hinting-bits-and-helpers.patch
--- include/linux/swapops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/swapops.h +1 -1
@@ -54,7 +54,7 @@ static inline pgoff_t swp_offset(swp_entry_t entry)/* check whether a pte points to a swap entry */ static inline int is_swap_pte (pte_t pte) { -return !pte_none (pte); +return !pte_none (pte) && !pte_present (pte); }#endif
Re: [PATCH] mm: remove remaining references to NUMA hinting bits and helpers -fix
Quoted 17 lines · Mel Gorman
The patch "mm: remove remaining references to NUMA hinting bits and helpers" was meant to remove NUMA hinting bits and helpers but broke
is_swap_pte. From the original bug reportFor 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
Quoted 5 lines
This patch should address the problem and is a fix to the mmotm patch mm-remove-remaining-references-to-numa-hinting-bits-and-helpers.patch
Reported-by Mark Brown <[email protected]>Signed-off-by Mel Gorman <[email protected]>
Quoted 17 lines
--- include/linux/swapops.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/linux/swapops.h +1
-1@@ -54,7 +54,7 @@ static inline pgoff_t swp_offset(swp_entry_t entry)/* check whether a pte points to a swap entry */ static inline int is_swap_pte (pte_t pte) { -return !pte_none (pte); +return !pte_none (pte) && !pte_present (pte); }#endif