mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: glider@google.com
Cc: catalin.marinas@arm.com, will.deacon@arm.com,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, keescook@chromium.org,
	akpm@linux-foundation.org
Subject: Re: [PATCH] arm64: define __alloc_zeroed_user_highpage
Date: Thu, 12 Mar 2020 16:49:22 +0000	[thread overview]
Message-ID: <20200312164922.GC21120@lakrids.cambridge.arm.com> (raw)
In-Reply-To: <20200312155920.50067-1-glider@google.com>

On Thu, Mar 12, 2020 at 04:59:20PM +0100, glider@google.com wrote:
> When running the kernel with init_on_alloc=1, calling the default
> implementation of __alloc_zeroed_user_highpage() from include/linux/highmem.h
> leads to double-initialization of the allocated page (first by the page
> allocator, then by clear_user_page().
> Calling alloc_page_vma() with __GFP_ZERO, similarly to e.g. x86, seems
> to be enough to ensure the user page is zeroed only once.

Just to check, is there a functional ussue beyond the redundant zeroing,
or is this jsut a performance issue?

On architectures with real highmem, does GFP_HIGHUSER prevent the
allocator from zeroing the page in this case, or is the architecture
prevented from allocating from highmem?

This feels like something we should be able to fix in the generic
implementation of __alloc_zeroed_user_highpage(), with an additional
check to see if init_on_alloc is in use.

Thanks,
Mark.

> 
> Signed-off-by: Alexander Potapenko <glider@google.com>
> ---
>  arch/arm64/include/asm/page.h | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
> index d39ddb258a049..75d6cd23a6790 100644
> --- a/arch/arm64/include/asm/page.h
> +++ b/arch/arm64/include/asm/page.h
> @@ -21,6 +21,10 @@ extern void __cpu_copy_user_page(void *to, const void *from,
>  extern void copy_page(void *to, const void *from);
>  extern void clear_page(void *to);
>  
> +#define __alloc_zeroed_user_highpage(movableflags, vma, vaddr) \
> +	alloc_page_vma(GFP_HIGHUSER | __GFP_ZERO | movableflags, vma, vaddr)
> +#define __HAVE_ARCH_ALLOC_ZEROED_USER_HIGHPAGE
> +
>  #define clear_user_page(addr,vaddr,pg)  __cpu_clear_user_page(addr, vaddr)
>  #define copy_user_page(to,from,vaddr,pg) __cpu_copy_user_page(to, from, vaddr)
>  
> -- 
> 2.25.1.481.gfbce0eb801-goog
> 

  reply	other threads:[~2020-03-12 16:49 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-12 15:59 glider
2020-03-12 16:49 ` Mark Rutland [this message]
2020-03-12 19:59   ` Alexander Potapenko
2020-03-13 15:03     ` Catalin Marinas
2020-03-17 18:37 ` Catalin Marinas

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=20200312164922.GC21120@lakrids.cambridge.arm.com \
    --to=mark.rutland@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=glider@google.com \
    --cc=keescook@chromium.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=will.deacon@arm.com \
    /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

all inboxes | Powered by JetHome®