[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAAeHK+yrPEaHe=ifhhP2BYPCCo1zuqsH-in4qTfMqNYCh-yxWw@mail.gmail.com>
Date: Tue, 19 Jan 2021 21:56:49 +0100
From: Andrey Konovalov <andreyknvl@...gle.com>
To: Vincenzo Frascino <vincenzo.frascino@....com>
Cc: Catalin Marinas <catalin.marinas@....com>,
LKML <linux-kernel@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>,
Leon Romanovsky <leonro@...lanox.com>,
Alexander Potapenko <glider@...gle.com>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
Andrey Ryabinin <aryabinin@...tuozzo.com>,
Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH] kasan: Add explicit preconditions to kasan_report()
On Tue, Jan 19, 2021 at 9:32 PM Vincenzo Frascino
<vincenzo.frascino@....com> wrote:
>
> This seems not working on arm64 because according to virt_addr_valid 0 is a
> valid virtual address, in fact:
>
> __is_lm_address(0) == true && pfn_valid(virt_to_pfn(0)) == true.
>
> An option could be to make an exception for virtual address 0 in
> addr_has_metadata() something like:
>
> static inline bool addr_has_metadata(const void *addr)
> {
> if ((u64)addr == 0)
> return false;
This sounds good to me, but we need to check for < PAGE_SIZE or
something like that, right? There's some limit below which accesses
are considered null-ptr-derefs.
> return (is_vmalloc_addr(addr) || virt_addr_valid(addr));
Do we need is_vmalloc_addr()? As we don't yet have vmalloc support for HW_TAGS.
Powered by blists - more mailing lists