On 10/9/20 11:16 AM, Catalin Marinas wrote:

On Fri, Oct 09, 2020 at 10:56:02AM +0100, Vincenzo Frascino wrote:

quoted

On 10/9/20 9:11 AM, Catalin Marinas wrote:

quoted

On Thu, Oct 08, 2020 at 07:24:12PM +0100, Vincenzo Frascino wrote:

quoted

On 10/2/20 3:06 PM, Catalin Marinas wrote:

quoted

On Fri, Oct 02, 2020 at 01:10:30AM +0200, Andrey Konovalov wrote:

quoted

diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index 7c67ac6f08df..d1847f29f59b 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c

@@ -23,6 +23,8 @@
 #include <asm/ptrace.h>
 #include <asm/sysreg.h>
 
+u64 gcr_kernel_excl __ro_after_init;
+
 static void mte_sync_page_tags(struct page *page, pte_t *ptep, bool check_swap)
 {
 	pte_t old_pte = READ_ONCE(*ptep);

@@ -120,6 +122,13 @@ void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag)
 	return ptr;
 }
 
+void mte_init_tags(u64 max_tag)
+{
+	u64 incl = GENMASK(max_tag & MTE_TAG_MAX, 0);

Nitpick: it's not obvious that MTE_TAG_MAX is a mask, so better write
this as GENMASK(min(max_tag, MTE_TAG_MAX), 0).

The two things do not seem equivalent because the format of the tags in KASAN is
0xFF and in MTE is 0xF, hence if extract the minimum whatever is the tag passed
by KASAN it will always be MTE_TAG_MAX.

To make it cleaner I propose: GENMASK(FIELD_GET(MTE_TAG_MAX, max_tag), 0);

I don't think that's any clearer since FIELD_GET still assumes that
MTE_TAG_MAX is a mask. I think it's better to add a comment on why this
is needed, as you explained above that the KASAN tags go to 0xff.

If you want to get rid of MTE_TAG_MAX altogether, just do a

	max_tag &= (1 << MAX_TAG_SIZE) - 1;

before setting incl (a comment is still useful).

Agree, but still think we should use FIELD_GET here since it is common language
in the kernel.

How about we get rid of MTE_TAG_MAX and we do something like:

GENMASK(FIELD_GET(MTE_TAG_MASK >> MTE_TAG_SHIFT, max_tag), 0);

It works for me and you can drop the MTE_TAG_MAX definition (I think
it's only used here).

Yes indeed, I will drop it.

-- 
Regards,
Vincenzo

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