linux-kernel - Re: Hangs in libhugetlbfs tests in -next

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 29 Jan 2015 16:02:27 +0000
From:	Steve Capper <steve.capper@...aro.org>
To:	Mark Brown <broonie@...nel.org>
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will.deacon@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mel Gorman <mgorman@...e.de>, linux-next@...r.kernel.org
Subject: Re: Hangs in libhugetlbfs tests in -next

On 28 January 2015 at 15:24, Mark Brown <broonie@...nel.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/