linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: christophe leroy <christophe.leroy@c-s.fr>,
	aneesh.kumar@linux.ibm.com, bsingharora@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.vnet.ibm.com>,
	kasan-dev@googlegroups.com
Subject: Re: [RFC PATCH 3/5] kasan: allow architectures to provide an outline readiness check
Date: Mon, 18 Feb 2019 17:13:42 +1100	[thread overview]
Message-ID: <87zhqt39pl.fsf@dja-thinkpad.axtens.net> (raw)
In-Reply-To: <dd65d283-5f6b-8e07-37ba-8ebc24cd5294@c-s.fr>

christophe leroy <christophe.leroy@c-s.fr> writes:

> Le 15/02/2019 à 01:04, Daniel Axtens a écrit :
>> In powerpc (as I understand it), we spend a lot of time in boot
>> running in real mode before MMU paging is initalised. During
>> this time we call a lot of generic code, including printk(). If
>> we try to access the shadow region during this time, things fail.
>> 
>> My attempts to move early init before the first printk have not
>> been successful. (Both previous RFCs for ppc64 - by 2 different
>> people - have needed this trick too!)
>> 
>> So, allow architectures to define a check_return_arch_not_ready()
>> hook that bails out of check_memory_region_inline() unless the
>> arch has done all of the init.
>> 
>> Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
>> Link: https://patchwork.ozlabs.org/patch/795211/      # ppc radix series
>> Originally-by: Balbir Singh <bsingharora@gmail.com>
>> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
>> Signed-off-by: Daniel Axtens <dja@axtens.net>
>> ---
>>   include/linux/kasan.h | 4 ++++
>>   mm/kasan/generic.c    | 2 ++
>>   2 files changed, 6 insertions(+)
>> 
>> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
>> index f6261840f94c..83edc5e2b6a0 100644
>> --- a/include/linux/kasan.h
>> +++ b/include/linux/kasan.h
>> @@ -14,6 +14,10 @@ struct task_struct;
>>   #include <asm/kasan.h>
>>   #include <asm/pgtable.h>
>>   
>> +#ifndef check_return_arch_not_ready
>> +#define check_return_arch_not_ready()	do { } while (0)
>> +#endif
>
> A static inline would be better I believe.
>
> Something like
>
> #ifndef kasan_arch_is_ready
> static inline bool kasan_arch_is_ready {return true;}
> #endif
>
>> +
>>   extern unsigned char kasan_early_shadow_page[PAGE_SIZE];
>>   extern pte_t kasan_early_shadow_pte[PTRS_PER_PTE];
>>   extern pmd_t kasan_early_shadow_pmd[PTRS_PER_PMD];
>> diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
>> index bafa2f986660..4c18bbd09a20 100644
>> --- a/mm/kasan/generic.c
>> +++ b/mm/kasan/generic.c
>> @@ -170,6 +170,8 @@ static __always_inline void check_memory_region_inline(unsigned long addr,
>>   						size_t size, bool write,
>>   						unsigned long ret_ip)
>>   {
>> +	check_return_arch_not_ready();
>> +
>
> Not good for readibility that the above macro embeds a return, something 
> like below would be better I think:
>
> 	if (!kasan_arch_is_ready())
> 		return;
>
> Unless somebody minds, I'll do the change and take this patch in my 
> series in order to handle the case of book3s/32 hash.

Please do; feel free to take as many of the patches as you would like
and I'll rebase whatever is left on the next version of your series.

The idea with the macro magic was to take advantage of the speed of
static keys (I think, I borrowed it from Balbir's patch). Perhaps an
inline function will achieve this anyway, but given that KASAN with
outline instrumentation is inevitably slow, I guess it doesn't matter
much either way.

Regards,
Daniel
>
> Christophe
>
>>   	if (unlikely(size == 0))
>>   		return;
>>   
>> 
>
> ---
> L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
> https://www.avast.com/antivirus

  reply	other threads:[~2019-02-18  6:15 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-15  0:04 [RFC PATCH 0/5] powerpc: KASAN for 64-bit Book3E Daniel Axtens
2019-02-15  0:04 ` [RFC PATCH 1/5] kasan: do not open-code addr_has_shadow Daniel Axtens
2019-02-15  0:12   ` Andrew Donnellan
2019-02-15  8:21     ` Dmitry Vyukov
2019-02-15  0:04 ` [RFC PATCH 2/5] kasan: allow architectures to manage the memory-to-shadow mapping Daniel Axtens
2019-02-15  6:35   ` Dmitry Vyukov
2019-02-15  0:04 ` [RFC PATCH 3/5] kasan: allow architectures to provide an outline readiness check Daniel Axtens
2019-02-15  8:25   ` Dmitry Vyukov
2019-02-17 12:05   ` christophe leroy
2019-02-18  6:13     ` Daniel Axtens [this message]
2019-02-25 14:01       ` Christophe Leroy
2019-02-26  0:14         ` Daniel Axtens
2019-02-15  0:04 ` [RFC PATCH 4/5] powerpc: move KASAN into its own subdirectory Daniel Axtens
2019-02-15  0:24   ` Andrew Donnellan
2019-02-17 16:29   ` christophe leroy
2019-02-18  9:14     ` Michael Ellerman
2019-02-18 12:27       ` Christophe Leroy
2019-02-19  0:44         ` Michael Ellerman
2019-02-15  0:04 ` [RFC PATCH 5/5] powerpc: KASAN for 64bit Book3E Daniel Axtens
2019-02-15  8:28   ` Dmitry Vyukov
2019-02-19  6:37     ` Daniel Axtens
2019-02-17 14:06   ` christophe leroy
2019-02-18 19:26   ` Christophe Leroy
2019-02-19  0:14     ` Daniel Axtens
2019-02-15 16:39 ` [RFC PATCH 0/5] powerpc: KASAN for 64-bit Book3E Christophe Leroy
2019-02-17  6:34 ` Balbir Singh
2019-02-19  6:35   ` Daniel Axtens

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87zhqt39pl.fsf@dja-thinkpad.axtens.net \
    --to=dja@axtens.net \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=bsingharora@gmail.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=kasan-dev@googlegroups.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).