powerpc/64s: slb comment update
authorNicholas Piggin <npiggin@gmail.com>
Sat, 30 Jan 2021 13:08:27 +0000 (23:08 +1000)
committerMichael Ellerman <mpe@ellerman.id.au>
Mon, 8 Feb 2021 13:02:10 +0000 (00:02 +1100)
This makes a small improvement to the description of the SLB interrupt
environment. Move the memory access restrictions into one paragraph,
and the interrupt restrictions into the next rather than mix them.

Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210130130852.2952424-18-npiggin@gmail.com
arch/powerpc/mm/book3s64/slb.c

index c581548..14c62b6 100644 (file)
@@ -825,19 +825,21 @@ long do_slb_fault(struct pt_regs *regs)
                return -EINVAL;
 
        /*
-        * SLB kernel faults must be very careful not to touch anything
-        * that is not bolted. E.g., PACA and global variables are okay,
-        * mm->context stuff is not.
-        *
-        * SLB user faults can access all of kernel memory, but must be
-        * careful not to touch things like IRQ state because it is not
-        * "reconciled" here. The difficulty is that we must use
-        * fast_exception_return to return from kernel SLB faults without
-        * looking at possible non-bolted memory. We could test user vs
-        * kernel faults in the interrupt handler asm and do a full fault,
-        * reconcile, ret_from_except for user faults which would make them
-        * first class kernel code. But for performance it's probably nicer
-        * if they go via fast_exception_return too.
+        * SLB kernel faults must be very careful not to touch anything that is
+        * not bolted. E.g., PACA and global variables are okay, mm->context
+        * stuff is not. SLB user faults may access all of memory (and induce
+        * one recursive SLB kernel fault), so the kernel fault must not
+        * trample on the user fault state at those points.
+        */
+
+       /*
+        * The interrupt state is not reconciled, for performance, so that
+        * fast_interrupt_return can be used. The handler must not touch local
+        * irq state, or schedule. We could test for usermode and upgrade to a
+        * normal process context (synchronous) interrupt for those, which
+        * would make them first-class kernel code and able to be traced and
+        * instrumented, although performance would suffer a bit, it would
+        * probably be a good tradeoff.
         */
        if (id >= LINEAR_MAP_REGION_ID) {
                long err;