[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220825132054.ymenz4cewiemsxw7@revolver>
Date: Thu, 25 Aug 2022 13:21:01 +0000
From: Liam Howlett <liam.howlett@...cle.com>
To: Mark Brown <broonie@...nel.org>
CC: Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>,
"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"
<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
* Mark Brown <broonie@...nel.org> [220824 20:34]:
> 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
Thanks.
>
> 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
This helps a lot. I think your bisect is accurate:
...
struct mmu_gather tlb;
+ MA_STATE(mas, ¤t->mm->mm_mt, start, start);
start = untagged_addr(start);
...
It looks like I search against the tagged address. I should initialize
the state to 0 and mas_set(&mas, start) after untagging the address.
I'll send out a patch once I have recreated and verified this is the
issue.
Cheers,
Liam
Powered by blists - more mailing lists