LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Hangs in libhugetlbfs tests in -next
@ 2015-01-28 15:24 Mark Brown
  2015-01-29 12:29 ` Steve Capper
  2015-01-29 16:02 ` Steve Capper
  0 siblings, 2 replies; 6+ messages in thread
From: Mark Brown @ 2015-01-28 15:24 UTC (permalink / raw)
  To: Catalin Marinas, Will Deacon, Steve Capper; +Cc: linux-arm-kernel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Hangs in libhugetlbfs tests in -next
  2015-01-28 15:24 Hangs in libhugetlbfs tests in -next Mark Brown
@ 2015-01-29 12:29 ` Steve Capper
  2015-01-29 16:02 ` Steve Capper
  1 sibling, 0 replies; 6+ messages in thread
From: Steve Capper @ 2015-01-29 12:29 UTC (permalink / raw)
  To: Mark Brown; +Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, linux-kernel

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 reproduced this on Juno, it looks like hugtlb_fault is being
called repeatedly in the mlock test.

I'll investigate further.

Cheers,
-- 
Steve

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Hangs in libhugetlbfs tests in -next
  2015-01-28 15:24 Hangs in libhugetlbfs tests in -next Mark Brown
  2015-01-29 12:29 ` Steve Capper
@ 2015-01-29 16:02 ` Steve Capper
  2015-01-29 16:42   ` Catalin Marinas
  2015-01-30 10:04   ` [PATCH] mm: remove remaining references to NUMA hinting bits and helpers -fix Mel Gorman
  1 sibling, 2 replies; 6+ messages in thread
From: Steve Capper @ 2015-01-29 16:02 UTC (permalink / raw)
  To: Mark Brown
  Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, linux-kernel,
	Mel Gorman, linux-next

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Hangs in libhugetlbfs tests in -next
  2015-01-29 16:02 ` Steve Capper
@ 2015-01-29 16:42   ` Catalin Marinas
  2015-01-30 10:04   ` [PATCH] mm: remove remaining references to NUMA hinting bits and helpers -fix Mel Gorman
  1 sibling, 0 replies; 6+ messages in thread
From: Catalin Marinas @ 2015-01-29 16:42 UTC (permalink / raw)
  To: Steve Capper
  Cc: Mark Brown, Will Deacon, linux-arm-kernel, linux-kernel,
	Mel Gorman, linux-next

On Thu, Jan 29, 2015 at 04:02:27PM +0000, Steve Capper wrote:
> 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?

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

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [PATCH] mm: remove remaining references to NUMA hinting bits and helpers -fix
  2015-01-29 16:02 ` Steve Capper
  2015-01-29 16:42   ` Catalin Marinas
@ 2015-01-30 10:04   ` Mel Gorman
  2015-01-31  9:11     ` Steve Capper
  1 sibling, 1 reply; 6+ messages in thread
From: Mel Gorman @ 2015-01-30 10:04 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Mark Brown, Catalin Marinas, Will Deacon, Steve Capper,
	linux-arm-kernel, linux-kernel, linux-next

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 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

Reported-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Mel Gorman <mgorman@suse.de>
---
 include/linux/swapops.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index 73ca28070a92..cedf3d3c373f 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -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
 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] mm: remove remaining references to NUMA hinting bits and helpers -fix
  2015-01-30 10:04   ` [PATCH] mm: remove remaining references to NUMA hinting bits and helpers -fix Mel Gorman
@ 2015-01-31  9:11     ` Steve Capper
  0 siblings, 0 replies; 6+ messages in thread
From: Steve Capper @ 2015-01-31  9:11 UTC (permalink / raw)
  To: Mel Gorman
  Cc: Andrew Morton, Mark Brown, Catalin Marinas, Will Deacon,
	linux-arm-kernel, linux-kernel, linux-next

On Fri, Jan 30, 2015 at 10:04:06AM +0000, Mel Gorman wrote:
> 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 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
> 
> Reported-by: Mark Brown <broonie@kernel.org>
> Signed-off-by: Mel Gorman <mgorman@suse.de>

Acked-by: Steve Capper <steve.capper@linaro.org>

> ---
>  include/linux/swapops.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/swapops.h b/include/linux/swapops.h
> index 73ca28070a92..cedf3d3c373f 100644
> --- a/include/linux/swapops.h
> +++ b/include/linux/swapops.h
> @@ -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
>  

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2015-01-31  9:12 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-28 15:24 Hangs in libhugetlbfs tests in -next Mark Brown
2015-01-29 12:29 ` Steve Capper
2015-01-29 16:02 ` Steve Capper
2015-01-29 16:42   ` Catalin Marinas
2015-01-30 10:04   ` [PATCH] mm: remove remaining references to NUMA hinting bits and helpers -fix Mel Gorman
2015-01-31  9:11     ` Steve Capper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).