r350004 changed data_abort() such that it generally invokes pmap_fault() on virtual addresses within the kernel pmap. (Previously, pmap_fault() was only invoked on kernel virtual addresses within the direct map.)
During the window of time when pmap_update_entry() is performing the "break-before-make" sequence, the affected pmap is locked and the only data being accessed is either within a page table page or the underlying thread's stack. Neither the mapping to the page table page nor the mapping to the thread's stack could be undergoing concurrent promotion or demotion. In particular, the kernel pmap lock would prevent the concurrent demotion of the direct map entry that provides access to the page table page that is being modified by pmap_update_entry().
And, because the kernel pmap is locked during promotion, if another processor traps during the "break-before-make" sequence, it is delayed by the pmap lock in pmap_fault() until the "make" has completed.