quoted

I think I understand what you mean. I agree that it is possible for a
concurrent walk to see an invalid TLBI state, if it is on the same TLB
that the repaint is happening on. For other TLBs, the flush has not yet
propagated our invalidated PTEs (from `__ptep_get_and_clear()`) though?

What I am saying is: if there is no TLB entry yet, HW will walk the page
table to find no present PTE and trigger a fault.

Yes, that is 100% correct. I believe that this is unavoidable.

quoted

That invalidation will only be seen by other TLBs after the
`__flush_tlb_range()`, so we should save a few faults because only
"local" threads will ever see the invalid entry, as opposed to all
threads that try to read our modified range?

So what you say is, that deferring the flush means that if there is already
a TLB entry, flushing deferred reduces the likelihood that a page table walk
is triggered that could find no present PTE: consequently, reducing the
likelihood that a page fault is triggered.

(I use the word likelihood, because I assume other action could result in a
TLB entry getting flushed in the meantime, such as TLB entry reuse)

Correct?

Yes, and your language here is clearer than the original commit message
(and cover letter). Will amend it to be closer to your wording.

-- 
Kind regards,
Mikołaj Lenczewski