From: Catalin Marinas <catalin.marinas@arm.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Linus Torvalds <torvalds@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Mark Brown <broonie@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Jann Horn <jannh@google.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Peter Xu <peterx@redhat.com>,
linux-arm-kernel@lists.infradead.org,
Will Deacon <will@kernel.org>,
Aishwarya TCV <Aishwarya.TCV@arm.com>
Subject: Re: [PATCH hotfix 6.12 v2 4/8] mm: resolve faulty mmap_region() error path behaviour
Date: Tue, 29 Oct 2024 15:04:41 +0000 [thread overview]
Message-ID: <ZyD5iXikMzotl9mU@arm.com> (raw)
In-Reply-To: <cf1deb9b-c5c4-4e85-891d-62ecf9a04e0f@lucifer.local>
Hi Lorenzo,
Thanks for trying to fix this.
On Mon, Oct 28, 2024 at 10:14:50PM +0000, Lorenzo Stoakes wrote:
> From 247003cd2a4b5f4fc2dac97f5ef7e473a47f4324 Mon Sep 17 00:00:00 2001
> From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Date: Mon, 28 Oct 2024 22:05:44 +0000
> Subject: [PATCH] mm: perform MTE check within arm64 hook entirely
>
> It doesn't make sense to have shmem explicitly check this one arch-specific
> case, it is arch-specific, so the arch should handle it. We know shmem is a
> case in which we want to permit MTE, so simply check for this directly.
>
> This also fixes the issue with checking arch_validate_flags() early, which
> would otherwise break mmap_region().
>
> In order to implement this we must pass a file pointer, and additionally
> update the sparc code to accept this parameter too.
>
> We'd ideally like to have eliminated the arch_calc_vm_flag_bits() case, but
> we risk inadvertently changing behaviour as we do not have mmap() flags
> available at the point of the arch_validate_flags() check and a MAP_ANON |
> MAP_HUGETLB case would be accepted for MTE currently, but a MAP_SHARED |
> MAP_HUGETLB would not.
>
> This is likely an oversight but we want to try to keep behaviour identical
> to before in this patch.
MAP_HUGETLB support for MTE is only in -next currently, so there
wouldn't be any ABI change if we also allowed MAP_SHARED | MAP_HUGETLB.
In 6.12, MAP_HUGETLB is not allowed to have PROT_MTE.
> So continue to check VM_MTE_ALLOWED which arch_calc_vm_flag_bits() sets if
> MAP_ANON.
[...]
> diff --git a/mm/shmem.c b/mm/shmem.c
> index 4ba1d00fabda..e87f5d6799a7 100644
> --- a/mm/shmem.c
> +++ b/mm/shmem.c
> @@ -2733,9 +2733,6 @@ static int shmem_mmap(struct file *file, struct vm_area_struct *vma)
> if (ret)
> return ret;
>
> - /* arm64 - allow memory tagging on RAM-based files */
> - vm_flags_set(vma, VM_MTE_ALLOWED);
This breaks arm64 KVM if the VMM uses shared mappings for the memory
slots (which is possible). We have kvm_vma_mte_allowed() that checks for
the VM_MTE_ALLOWED flag as the VMM may not use PROT_MTE/VM_MTE directly.
I need to read this thread properly but why not pass the file argument
to arch_calc_vm_flag_bits() and set VM_MTE_ALLOWED in there?
--
Catalin
next prev parent reply other threads:[~2024-10-29 15:08 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-23 20:38 [PATCH v2 0/8] fix error handling in mmap_region() and refactor Lorenzo Stoakes
2024-10-23 20:38 ` [PATCH hotfix 6.12 v2 1/8] mm: avoid unsafe VMA hook invocation when error arises on mmap hook Lorenzo Stoakes
2024-10-23 20:38 ` [PATCH hotfix 6.12 v2 2/8] mm: unconditionally close VMAs on error Lorenzo Stoakes
2024-10-23 20:38 ` [PATCH hotfix 6.12 v2 3/8] mm: refactor map_deny_write_exec() Lorenzo Stoakes
2024-10-23 20:38 ` [PATCH hotfix 6.12 v2 4/8] mm: resolve faulty mmap_region() error path behaviour Lorenzo Stoakes
2024-10-28 18:29 ` Mark Brown
2024-10-28 18:57 ` Lorenzo Stoakes
2024-10-28 19:05 ` Linus Torvalds
2024-10-28 19:14 ` Lorenzo Stoakes
2024-10-28 19:50 ` Liam R. Howlett
2024-10-28 20:00 ` Liam R. Howlett
2024-10-28 20:17 ` Lorenzo Stoakes
2024-10-28 20:22 ` Linus Torvalds
2024-10-28 20:43 ` Lorenzo Stoakes
2024-10-28 21:04 ` Liam R. Howlett
2024-10-28 21:05 ` Mark Brown
2024-10-28 21:28 ` Lorenzo Stoakes
2024-10-28 21:00 ` Vlastimil Babka
2024-10-28 21:19 ` Linus Torvalds
2024-10-28 21:28 ` Vlastimil Babka
2024-10-28 22:14 ` Lorenzo Stoakes
2024-10-29 7:50 ` Vlastimil Babka
2024-10-29 10:23 ` Lorenzo Stoakes
2024-10-29 12:33 ` Mark Brown
2024-10-29 12:41 ` Lorenzo Stoakes
2024-10-29 15:04 ` Catalin Marinas [this message]
2024-10-29 15:16 ` Lorenzo Stoakes
2024-10-29 16:22 ` Catalin Marinas
2024-10-29 16:36 ` Lorenzo Stoakes
2024-10-29 17:02 ` Catalin Marinas
2024-10-29 17:28 ` Lorenzo Stoakes
2024-10-29 17:32 ` Catalin Marinas
2024-10-28 20:51 ` Mark Brown
2024-10-23 20:38 ` [PATCH v2 5/8] tools: testing: add additional vma_internal.h stubs Lorenzo Stoakes
2024-10-23 20:38 ` [PATCH v2 6/8] mm: isolate mmap internal logic to mm/vma.c Lorenzo Stoakes
2024-10-24 17:23 ` Vlastimil Babka
2024-10-23 20:38 ` [PATCH v2 7/8] mm: refactor __mmap_region() Lorenzo Stoakes
2024-10-25 8:35 ` Vlastimil Babka
2024-10-25 10:19 ` Lorenzo Stoakes
2024-10-25 10:23 ` Vlastimil Babka
2024-10-23 20:38 ` [PATCH v2 8/8] mm: defer second attempt at merge on mmap() Lorenzo Stoakes
2024-10-25 9:43 ` Vlastimil Babka
2024-10-25 10:20 ` Lorenzo Stoakes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZyD5iXikMzotl9mU@arm.com \
--to=catalin.marinas@arm.com \
--cc=Aishwarya.TCV@arm.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=broonie@kernel.org \
--cc=jannh@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=peterx@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=vbabka@suse.cz \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.