[PATCH 2/2] arm64: Mark kernel page ranges contiguous
Jeremy Linton
jeremy.linton at arm.com
Fri Feb 12 09:35:05 PST 2016
On 02/12/2016 10:57 AM, Mark Rutland wrote:
(trimming)
> On Fri, Feb 12, 2016 at 10:06:48AM -0600, Jeremy Linton wrote:
>> +static void clear_cont_pte_range(pte_t *pte, unsigned long addr)
>> +{
>> + int i;
>> +
>> + pte -= CONT_RANGE_OFFSET(addr);
>> + for (i = 0; i < CONT_PTES; i++) {
>> + if (pte_cont(*pte))
>> + set_pte(pte, pte_mknoncont(*pte));
>> + pte++;
>> + }
>> + flush_tlb_all();
>> +}
>
> As far as I can tell, "splitting" contiguous entries comes with the same
> caveats as splitting sections. In the absence of a BBM sequence we might
> end up with conflicting TLB entries.
As I mentioned a couple weeks ago, I'm not sure that inverting a BBM to
a full "make partial copy of the whole table->break TTBR to copy
sequence" is so bad if the copy process maintains references to the
original table entries when they aren't in the modification path. It
might even work with all the CPU's spun up because the break sequence
would just be IPI's to the remaining cpu's to replace their TTBR/flush
with a new value. I think you mentioned the ugly part is arbitrating
access to the update functionality (and all the implied rules of when it
could be done). But doing it that way doesn't require stalling the CPU's
during the "make partial copy" portion.
> However, I think we're OK for now.
>
> The way we consistently map/unmap/modify image/linear "chunks" should
> prevent us from trying to split those, and if/when we do this for the
> EFI runtime page tables thy aren't live.
>
> It would be good to figure out how to get rid of the splitting entirely.
Well we could hoist some of it earlier by taking the
create_mapping_late() calls and doing them earlier with RWX permissions,
and then applying the RO,ROX,RW later as necessarily.
Which is ugly, but it might solve particular late splitting cases.
More information about the linux-arm-kernel
mailing list