[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170812115736.GC16374@remoulade>
Date: Sat, 12 Aug 2017 12:57:37 +0100
From: Mark Rutland <mark.rutland@....com>
To: Tycho Andersen <tycho@...ker.com>
Cc: linux-kernel@...r.kernel.org, linux-mm@...ck.org,
kernel-hardening@...ts.openwall.com,
Marco Benatto <marco.antonio.780@...il.com>,
Juerg Haefliger <juerg.haefliger@...onical.com>,
Juerg Haefliger <juerg.haefliger@....com>
Subject: Re: [PATCH v5 07/10] arm64/mm: Don't flush the
data cache if the page is unmapped by XPFO
On Wed, Aug 09, 2017 at 02:07:52PM -0600, Tycho Andersen wrote:
> From: Juerg Haefliger <juerg.haefliger@....com>
>
> If the page is unmapped by XPFO, a data cache flush results in a fatal
> page fault. So don't flush in that case.
Do you have an example callchain where that happens? We might need to shuffle
things around to cater for that case.
> @@ -30,7 +31,9 @@ void sync_icache_aliases(void *kaddr, unsigned long len)
> unsigned long addr = (unsigned long)kaddr;
>
> if (icache_is_aliasing()) {
> - __clean_dcache_area_pou(kaddr, len);
> + /* Don't flush if the page is unmapped by XPFO */
> + if (!xpfo_page_is_unmapped(virt_to_page(kaddr)))
> + __clean_dcache_area_pou(kaddr, len);
> __flush_icache_all();
> } else {
> flush_icache_range(addr, addr + len);
I don't think this patch is correct. If data cache maintenance is required in
the absence of XPFO, I don't see why it wouldn't be required in the presence of
XPFO.
I'm not immediately sure why the non-aliasing case misses data cache
maintenance. I couldn't spot where that happens otherwise.
On a more general note, in future it would be good to Cc the arm64 maintainers
and the linux-arm-kernel mailing list for patches affecting arm64.
Thanks,
Mark.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
