linux-kernel - Re: [PATCH v13 57/70] mm/mlock: use vma iterator and maple state instead of vma linked list

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]

Message-ID: <20220825202128.6a4pzhdntc7xsok4@revolver>
Date:   Thu, 25 Aug 2022 20:21:35 +0000
From:   Liam Howlett <liam.howlett@...cle.com>
To:     Catalin Marinas <catalin.marinas@....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

* Catalin Marinas <catalin.marinas@....com> [220825 11:20]:
> 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, &current->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).
> 

Thanks Catalin for testing this.

I can confirm this fixes test 21 and 22 above:
ok 21 Check clear PROT_MTE flags with private mapping, sync error mode
and mmap memory
ok 22 Check clear PROT_MTE flags with private mapping and sync error
mode and mmap/mprotect memory
# Totals: pass:22 fail:0 xfail:0 xpass:0 skip:0 error:0

I will send out an update patch shortly.

Regards,
Liam