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
| ||
|
Date: Thu, 25 Aug 2022 16:20:08 +0100 From: Catalin Marinas <catalin.marinas@....com> To: Liam Howlett <liam.howlett@...cle.com> Cc: Mark Brown <broonie@...nel.org>, 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 On Thu, Aug 25, 2022 at 01:21:01PM +0000, Liam Howlett wrote: > * 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. Thanks. I did a quick test and untagging start seems to fix the issue (I was wondering why mprotect() returned -ENOMEM when failing). -- Catalin
Powered by blists - more mailing lists