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

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

[Mark Brown]

[-- Attachment #1.1: Type: text/plain, Size: 1116 bytes --]

On Mon, Aug 22, 2022 at 03:06:30PM +0000, Liam Howlett wrote:
> From: "Matthew Wilcox (Oracle)" <willy@infradead.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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Liam Howlett]

* Mark Brown <broonie@kernel.org> [220824 20:34]:
> On Mon, Aug 22, 2022 at 03:06:30PM +0000, Liam Howlett wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.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.

Cheers,
Liam
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Catalin Marinas]

On Thu, Aug 25, 2022 at 01:21:01PM +0000, Liam Howlett wrote:
> * Mark Brown <broonie@kernel.org> [220824 20:34]:
> > On Mon, Aug 22, 2022 at 03:06:30PM +0000, Liam Howlett wrote:
> > > From: "Matthew Wilcox (Oracle)" <willy@infradead.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).

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Liam Howlett]

* Catalin Marinas <catalin.marinas@arm.com> [220825 11:20]:
> On Thu, Aug 25, 2022 at 01:21:01PM +0000, Liam Howlett wrote:
> > * Mark Brown <broonie@kernel.org> [220824 20:34]:
> > > On Mon, Aug 22, 2022 at 03:06:30PM +0000, Liam Howlett wrote:
> > > > From: "Matthew Wilcox (Oracle)" <willy@infradead.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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel