On 2024/2/7 20:21, Mark Rutland wrote:
On Sat, Jan 13, 2024 at 05:44:35PM +0800, Nanyong Sun wrote:
Implement vmemmap_update_pmd and vmemmap_update_pte on arm64 to do
BBM(break-before-make) logic when change the page table of vmemmap
address, they will under the init_mm.page_table_lock.
If a translation fault of vmemmap address concurrently happened after
pte/pmd cleared, vmemmap page fault handler will acquire the
init_mm.page_table_lock to wait for vmemmap update to complete,
by then the virtual address is valid again, so PF can return and
access can continue.
Is that wait bounded? ... and is it event guaranteed to make progress?
Under a hypervisor, the vCPU doing the BBM could be preempted between the break
and the make, so the thread waiting might be waiting a long time for that to
come back and finish the make step.
Further, under PREEMPT_RT regular spinlocks don't inhibit preemption, and I suspect
that means this can deadlock on RT -- the thread doing the BBM could be
preempted, the newly-scheduled thread could try to access the vmemmap, and then
get stuck in the fault handler (e.g. on a single CPU system). There's nothing
below describing how that's prevented.
I've concerned this may be subtly broken, and it feels like this is going to be
*very* painful to maintain and test. IMO this is trying to be overly clever and
I'd much rather that we avoided the transient broken step. On CPUs with
FEAT_BBM level 2 we can avoid that broken step, can we make this depend
dynamically on whether the CPU has FEAT_BBM?
If I understand correctly, FEAT_BBM is only used for changing block
size. But in HVO
we not only need changing block size in vmemmap_split_pmd(), but also
need changing
output address of PTE in vmemmap_remap_pte().
So I would like to ask if FEAT_BBM can cover these scenarios?
In other case, do the traditional kernel fault.
Implement vmemmap_flush_tlb_all/range on arm64 with nothing
to do because tlb already flushed in every single BBM.
Signed-off-by: Nanyong Sun <sunnanyong@xxxxxxxxxx>
---
+
+/*
+ * PMD mapped vmemmap should has been split as PTE mapped
+ * by HVO now, here we only check this case, other cases
+ * should fail.
Sorry, I can't parse what this is trying to say.
+ * Also should check the addr is healthy enough that will not cause
+ * a level2 or level3 translation fault again after page fault
+ * handled with success, so we need check both bits[1:0] of PMD and
+ * PTE as ARM Spec mentioned below:
Which spec? Iassume you mean the ARM ARM? Are you referring to a specific part
within that?
Yes, I referenced section D5.8.1 "Types of MMU faults" from Arm ARM.
+ * A Translation fault is generated if bits[1:0] of a translation
+ * table descriptor identify the descriptor as either a Fault
+ * encoding or a reserved encoding.
+ */
+static inline bool vmemmap_addr_healthy(unsigned long addr)
+{
+ pmd_t *pmdp, pmd;
+ pte_t *ptep, pte;
+
+ pmdp = pmd_off_k(addr);
+ pmd = pmdp_get(pmdp);
+ if (!pmd_table(pmd))
+ return false;
Is a block (i.e. hugetlb) entry not considered healthy? I thought the whole
point of this optimization was that you'd use a block PMD entry?
Yes, this patch only condiser the user is HVO and then recheck here, and
in HVO, only PMD split and
PTE remap can happen. Any other scenarios should be treated as regular
kernel fault and then panic.
+
+ ptep = pte_offset_kernel(pmdp, addr);
+ pte = ptep_get(ptep);
+ return (pte_val(pte) & PTE_TYPE_MASK) == PTE_TYPE_PAGE;
+}
+
+static bool vmemmap_handle_page_fault(unsigned long addr,
+ unsigned long esr)
+{
+ bool ret;
+
+ if (likely(!vmemmap_fault_may_fixup(addr, esr)))
+ return false;
+
+ spin_lock(&init_mm.page_table_lock);
+ ret = vmemmap_addr_healthy(addr);
+ spin_unlock(&init_mm.page_table_lock);
As above, I'm pretty sure this is only safe is the code doing the BBM has IRQs
disabled, otherwise the thread can be preempted, and we can get stuck in here
while the entry is broken.
So at minimum this needs some explanation of why that doesn't happen in a
comment.
As above, if this happens with IRQs unmasked, the thread can potentially be
preempted and we can get stuck in the fault handler (at least on RT).
I can't tell whether this is safe, and I think that at minimum this needs
comments and/or lockdep assertions, but I'd much rather we didn't try to play
this sort of game.
Mark.
.
For IRQ context problem, I wonder if take a new spin lock with irq
disabled can solve it?
eg.
+void vmemmap_update_pte(unsigned long addr, pte_t *ptep, pte_t pte)
+{
+ spin_lock_irq(NEW_LOCK);
+ pte_clear(&init_mm, addr, ptep);
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+ set_pte_at(&init_mm, addr, ptep, pte);
+ spin_unlock_irq(NEW_LOCK);
+}
