On Wed, Oct 30, 2024 at 10:18:27AM +0100, Vlastimil Babka wrote:
> On 10/29/24 19:11, Lorenzo Stoakes wrote:
> > --- a/arch/arm64/include/asm/mman.h
> > +++ b/arch/arm64/include/asm/mman.h
> > @@ -6,6 +6,8 @@
> >
> > #ifndef BUILD_VDSO
> > #include <linux/compiler.h>
> > +#include <linux/fs.h>
> > +#include <linux/shmem_fs.h>
> > #include <linux/types.h>
> >
> > static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot,
> > @@ -31,19 +33,21 @@ static inline unsigned long arch_calc_vm_prot_bits(unsigned long prot,
> > }
> > #define arch_calc_vm_prot_bits(prot, pkey) arch_calc_vm_prot_bits(prot, pkey)
> >
> > -static inline unsigned long arch_calc_vm_flag_bits(unsigned long flags)
> > +static inline unsigned long arch_calc_vm_flag_bits(struct file *file,
> > + unsigned long flags)
> > {
> > /*
> > * Only allow MTE on anonymous mappings as these are guaranteed to be
> > * backed by tags-capable memory. The vm_flags may be overridden by a
> > * filesystem supporting MTE (RAM-based).
>
> We should also eventually remove the last sentence or even replace it with
> its negation, or somebody might try reintroducing the pattern that won't
> work anymore (wasn't there such a hugetlbfs thing in -next?).
I agree, we should update this comment as well though as a fix this
patch is fine for now.
There is indeed a hugetlbfs change in -next adding VM_MTE_ALLOWED. It
should still work after the above change but we'd need to move it over
here (and fix the comment at the same time). We'll probably do it around
-rc1 or maybe earlier once this fix hits mainline. I don't think we have
an equivalent of shmem_file() for hugetlbfs, we'll need to figure
something out.
> > */
> > - if (system_supports_mte() && (flags & MAP_ANONYMOUS))
> > + if (system_supports_mte() &&
> > + ((flags & MAP_ANONYMOUS) || shmem_file(file)))
> > return VM_MTE_ALLOWED;
> >
> > return 0;
> > }
This will conflict with the arm64 for-next/core tree as it's adding
a MAP_HUGETLB check. Trivial resolution though, Stephen will handle it.
--
Catalin
