Re: kern/60377: x86 cpu_uarea_alloc: pmap_update before freeing redzone pages

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

I'm confused by this one.

The logic here, condensed and paraphrased, is:

1. allocate [va1, ..., vaN] and [pa1, ..., paN] with uvm_km_alloc
2. pmap_kremove the vaN->paN mapping (but keep 1 through N-1)
3. free paN
4. pmap_update

(The purpose is to make vaN a guard page to catch kernel bugs.)

Note that there is no question about freeing or reusing _virtual_
addresses -- only about freeing and potentially reusing _physical_
addresses.

If I understand correctly, the idea of moving pmap_update earlier is
to ensure that any loads or stores prior to pmap_kremove won't
accidentally read or write data in paN _after_ it has been repurposed
for something else, leaking or corrupting a kernel data structure.

But I don't see how it could be possible -- barring critical bugs
elsewhere in the kernel -- for any other CPUs or threads or interrupt
handlers to load from or store to vaN.  And we certainly don't load
from or store to vaN in this function.

So what's the harm in freeing paN before pmap_update?  We've made a
page table entry that we break, but nobody can possibly be using vaN,
so the physical page shouldn't be affected by any of this.