From: Catalin Marinas <catalin.marinas@arm.com>
To: Vincenzo Frascino <vincenzo.frascino@arm.com>
Cc: linux-arch@vger.kernel.org, Mark Rutland <mark.rutland@arm.com>,
Will Deacon <will.deacon@arm.com>,
linux-arm-kernel@lists.infradead.org,
Jann Horn <jannh@google.com>
Subject: Re: [PATCH 1/5] arm64: compat: Alloc separate pages for vectors and sigpage
Date: Fri, 29 Mar 2019 12:12:14 +0000 [thread overview]
Message-ID: <20190329121211.gv7i7fqt74h3rtls@mbp> (raw)
In-Reply-To: <20190319151542.19557-2-vincenzo.frascino@arm.com>
On Tue, Mar 19, 2019 at 03:15:38PM +0000, Vincenzo Frascino wrote:
> +static int __init aarch32_alloc_vdso_pages(void)
> {
> extern char __kuser_helper_start[], __kuser_helper_end[];
> extern char __aarch32_sigret_code_start[], __aarch32_sigret_code_end[];
>
> int kuser_sz = __kuser_helper_end - __kuser_helper_start;
> int sigret_sz = __aarch32_sigret_code_end - __aarch32_sigret_code_start;
> - unsigned long vpage;
> + unsigned long vdso_pages[2];
>
> - vpage = get_zeroed_page(GFP_ATOMIC);
> + vdso_pages[0] = get_zeroed_page(GFP_ATOMIC);
> + if (!vdso_pages[0])
> + return -ENOMEM;
>
> - if (!vpage)
> + vdso_pages[1] = get_zeroed_page(GFP_ATOMIC);
> + if (!vdso_pages[1])
> return -ENOMEM;
>
> /* kuser helpers */
> - memcpy((void *)vpage + 0x1000 - kuser_sz, __kuser_helper_start,
> - kuser_sz);
> + memcpy((void *)(vdso_pages[0] + 0x1000 - kuser_sz),
> + __kuser_helper_start,
> + kuser_sz);
>
> /* sigreturn code */
> - memcpy((void *)vpage + AARCH32_KERN_SIGRET_CODE_OFFSET,
> - __aarch32_sigret_code_start, sigret_sz);
> + memcpy((void *)vdso_pages[1],
> + __aarch32_sigret_code_start,
> + sigret_sz);
>
> - flush_icache_range(vpage, vpage + PAGE_SIZE);
> - vectors_page[0] = virt_to_page(vpage);
> + flush_icache_range(vdso_pages[0], vdso_pages[0] + PAGE_SIZE);
> + flush_icache_range(vdso_pages[1], vdso_pages[1] + PAGE_SIZE);
I wonder whether we still need the flush_icache_range() calls here.
Normally set_pte_at() handles cache maintenance automatically if
PG_dcache_clean is not set. We could probably just call
flush_dcache_page() here.
--
Catalin
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-03-29 12:12 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-19 15:15 [PATCH 0/5] arm64: compat: Reduce address limit Vincenzo Frascino
2019-03-19 15:15 ` [PATCH 1/5] arm64: compat: Alloc separate pages for vectors and sigpage Vincenzo Frascino
2019-03-29 12:12 ` Catalin Marinas [this message]
2019-04-01 9:00 ` Vincenzo Frascino
2019-03-19 15:15 ` [PATCH 2/5] arm64: compat: Split kuser32 Vincenzo Frascino
2019-03-19 15:15 ` [PATCH 3/5] arm64: compat: Refactor aarch32_alloc_vdso_pages() Vincenzo Frascino
2019-03-19 15:15 ` [PATCH 4/5] arm64: compat: Add KUSER_HELPERS config option Vincenzo Frascino
2019-03-29 12:22 ` Catalin Marinas
2019-03-19 15:15 ` [PATCH 5/5] arm64: compat: Reduce address limit Vincenzo Frascino
2019-03-29 15:59 ` Catalin Marinas
2019-04-01 9:13 ` Vincenzo Frascino
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=20190329121211.gv7i7fqt74h3rtls@mbp \
--to=catalin.marinas@arm.com \
--cc=jannh@google.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=vincenzo.frascino@arm.com \
--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;
as well as URLs for NNTP newsgroup(s).