[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YwbDmKyQxWHfRg97@sirena.org.uk>
Date: Thu, 25 Aug 2022 01:34:32 +0100
From: Mark Brown <broonie@...nel.org>
To: Liam Howlett <liam.howlett@...cle.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>
Cc: "maple-tree@...ts.infradead.org" <maple-tree@...ts.infradead.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
"Matthew Wilcox (Oracle)" <willy@...radead.org>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v13 57/70] mm/mlock: use vma iterator and maple state
instead of vma linked list
On Mon, Aug 22, 2022 at 03:06:30PM +0000, Liam Howlett wrote:
> From: "Matthew Wilcox (Oracle)" <willy@...radead.org>
>
> Handle overflow checking in count_mm_mlocked_page_nr() differently.
Our QA team found that since next-20220823 we're seeing a couple of test
failures in the check_mmap_options kselftest on arm64 platforms with MTE
that aren't present in mainline:
# # FAIL: mprotect not ignoring clear PROT_MTE property
# not ok 21 Check clear PROT_MTE flags with private mapping, sync error mode and mmap memory
# # FAIL: mprotect not ignoring clear PROT_MTE property
# not ok 22 Check clear PROT_MTE flags with private mapping and sync error mode and mmap/mprotect memory
I bisected this using qemu[1] which landed on 4ceb4bca479d41a
("mm/mprotect: use maple tree navigation instead of vma linked list"),
though I'm not 100% sure I trust the specific identification of the
commit I'm pretty confident it's at the very least in this series. I've
not done any analysis of the failure beyond getting this bisect result.
[1] qemu -smp cpus=4 -cpu max -machine virt,gic-version=3,mte=on
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists