[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whD9MrPwPMBgVG16T_u+my8xYtZg2tUGz932HeodVX7Bg@mail.gmail.com>
Date: Mon, 28 Oct 2024 09:05:44 -1000
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Mark Brown <broonie@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>, Jann Horn <jannh@...gle.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Peter Xu <peterx@...hat.com>, linux-arm-kernel@...ts.infradead.org,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
Aishwarya TCV <Aishwarya.TCV@....com>
Subject: Re: [PATCH hotfix 6.12 v2 4/8] mm: resolve faulty mmap_region() error
path behaviour
On Mon, 28 Oct 2024 at 08:57, Lorenzo Stoakes
<lorenzo.stoakes@...cle.com> wrote:
>
> So likely hook on your mapping changes flags to set VM_MTE | VM_MTE_ALLOWED and
> expects this to be checked after (ugh).
Gaah. Yes. mm/shmem.c: shmem_mmap() does
/* arm64 - allow memory tagging on RAM-based files */
vm_flags_set(vma, VM_MTE_ALLOWED);
and while I found the equivalent hack for the VM_SPARC_ADI case, I
hadn't noticed that MTE thing.
How very annoying.
So the arch_validate_flags() case does need to be done after the ->mmap() call.
How about just finalizing everything, and then doing a regular
munmap() afterwards and returning an error (all still holding the mmap
semaphore, of course).
That still avoids the whole "partially completed mmap" case.
Linus
Powered by blists - more mailing lists