[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b2327ee-5f30-e412-7359-32a7a38b4c8d@arm.com>
Date: Thu, 8 Oct 2020 19:24:12 +0100
From: Vincenzo Frascino <vincenzo.frascino@....com>
To: Catalin Marinas <catalin.marinas@....com>,
Andrey Konovalov <andreyknvl@...gle.com>
Cc: Dmitry Vyukov <dvyukov@...gle.com>, kasan-dev@...glegroups.com,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Alexander Potapenko <glider@...gle.com>,
Marco Elver <elver@...gle.com>,
Evgenii Stepanov <eugenis@...gle.com>,
Elena Petrova <lenaptr@...gle.com>,
Branislav Rankov <Branislav.Rankov@....com>,
Kevin Brodsky <kevin.brodsky@....com>,
Will Deacon <will.deacon@....com>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-arm-kernel@...ts.infradead.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 29/39] arm64: mte: Switch GCR_EL1 in kernel entry and
exit
Hi Catalin,
On 10/2/20 3:06 PM, Catalin Marinas wrote:
> On Fri, Oct 02, 2020 at 01:10:30AM +0200, Andrey Konovalov wrote:
>> 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);
> Otherwise it looks fine.
>
> Reviewed-by: Catalin Marinas <catalin.marinas@....com>
>
--
Regards,
Vincenzo
Powered by blists - more mailing lists