Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753455AbbH3MmU (ORCPT ); Sun, 30 Aug 2015 08:42:20 -0400 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:60180 "EHLO e23smtp02.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753324AbbH3MmT (ORCPT ); Sun, 30 Aug 2015 08:42:19 -0400 X-Helo: d23dlp03.au.ibm.com X-MailFrom: aneesh.kumar@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org From: "Aneesh Kumar K.V" To: Andrey Ryabinin Cc: Benjamin Herrenschmidt , paulus@samba.org, mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, LKML Subject: Re: [PATCH V2 05/10] kasan: Enable arch to hook into kasan callbacks. In-Reply-To: References: <1440577578-15813-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> <1440577578-15813-6-git-send-email-aneesh.kumar@linux.vnet.ibm.com> User-Agent: Notmuch/0.17 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Sun, 30 Aug 2015 18:11:07 +0530 Message-ID: <878u8tq78c.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15083012-0005-0000-0000-000002607271 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3274 Lines: 109 Andrey Ryabinin writes: > 2015-08-26 11:26 GMT+03:00 Aneesh Kumar K.V : >> We add enable/disable callbacks in this patch which architecture >> can implemement. We will use this in the later patches for architecture >> like ppc64, that cannot have early zero page kasan shadow region for the >> entire virtual address space. Such architectures also cannot use >> inline kasan support. >> >> Signed-off-by: Aneesh Kumar K.V >> --- >> mm/kasan/kasan.c | 9 +++++++++ >> mm/kasan/kasan.h | 15 +++++++++++++++ >> 2 files changed, 24 insertions(+) >> >> diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c >> index 7b28e9cdf1c7..e4d33afd0eaf 100644 >> --- a/mm/kasan/kasan.c >> +++ b/mm/kasan/kasan.c >> @@ -43,6 +43,9 @@ static void kasan_poison_shadow(const void *address, size_t size, u8 value) >> { >> void *shadow_start, *shadow_end; >> >> + if (!kasan_enabled()) >> + return; >> + > > By the time this function called we already should have shadow, > so it should be safe to remove this check. > I remember hitting that call before enabling kasan completely. Will check that again. > >> shadow_start = kasan_mem_to_shadow(address); >> shadow_end = kasan_mem_to_shadow(address + size); >> >> @@ -51,6 +54,9 @@ static void kasan_poison_shadow(const void *address, size_t size, u8 value) >> >> void kasan_unpoison_shadow(const void *address, size_t size) >> { >> + if (!kasan_enabled()) >> + return; >> + > > Ditto. > >> kasan_poison_shadow(address, size, 0); >> >> if (size & KASAN_SHADOW_MASK) { >> @@ -238,6 +244,9 @@ static __always_inline void check_memory_region(unsigned long addr, >> { >> struct kasan_access_info info; >> >> + if (!kasan_enabled()) >> + return; >> + >> if (unlikely(size == 0)) >> return; >> >> diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h >> index a6b46cc94907..deb547d5a916 100644 >> --- a/mm/kasan/kasan.h >> +++ b/mm/kasan/kasan.h >> @@ -68,6 +68,21 @@ static inline bool kasan_report_enabled(void) >> return !current->kasan_depth; >> } >> >> +#ifndef kasan_enabled >> +/* >> + * Some archs may want to disable kasan callbacks. >> + */ >> +static inline bool kasan_enabled(void) >> +{ >> + return true; >> +} >> +#define kasan_enabled kasan_enabled > > Why we need this define? That is to make sure that we don't endup with different definition of kasan_enabled due to header include errors. Once we select a particular definition of the overloaded function, it is always good to mark the function as defined, so that checks like #ifndef kasan_enabled will always fail. > >> +#else >> +#ifdef CONFIG_KASAN_INLINE >> +#error "Kasan inline support cannot work with KASAN arch hooks" >> +#endif >> +#endif >> + >> void kasan_report(unsigned long addr, size_t size, >> bool is_write, unsigned long ip); >> >> -- >> 2.5.0 >> -aneesh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/