From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756083AbbA2Qm2 (ORCPT ); Thu, 29 Jan 2015 11:42:28 -0500 Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:46113 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755880AbbA2Qm1 (ORCPT ); Thu, 29 Jan 2015 11:42:27 -0500 Date: Thu, 29 Jan 2015 16:42:17 +0000 From: Catalin Marinas To: Steve Capper Cc: Mark Brown , Will Deacon , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Mel Gorman , "linux-next@vger.kernel.org" Subject: Re: Hangs in libhugetlbfs tests in -next Message-ID: <20150129164217.GK8951@e104818-lin.cambridge.arm.com> References: <20150128152412.GX21293@sirena.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 29, 2015 at 04:02:27PM +0000, Steve Capper wrote: > On 28 January 2015 at 15:24, Mark Brown 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Catalin Marinas Subject: Re: Hangs in libhugetlbfs tests in -next Date: Thu, 29 Jan 2015 16:42:17 +0000 Message-ID: <20150129164217.GK8951@e104818-lin.cambridge.arm.com> References: <20150128152412.GX21293@sirena.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:46113 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755880AbbA2Qm1 (ORCPT ); Thu, 29 Jan 2015 11:42:27 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-next-owner@vger.kernel.org List-ID: To: Steve Capper Cc: Mark Brown , Will Deacon , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Mel Gorman , "linux-next@vger.kernel.org" On Thu, Jan 29, 2015 at 04:02:27PM +0000, Steve Capper wrote: > On 28 January 2015 at 15:24, Mark Brown 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: catalin.marinas@arm.com (Catalin Marinas) Date: Thu, 29 Jan 2015 16:42:17 +0000 Subject: Hangs in libhugetlbfs tests in -next In-Reply-To: References: <20150128152412.GX21293@sirena.org.uk> Message-ID: <20150129164217.GK8951@e104818-lin.cambridge.arm.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thu, Jan 29, 2015 at 04:02:27PM +0000, Steve Capper wrote: > On 28 January 2015 at 15:24, Mark Brown 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