In D33597#759863, @kib wrote:

In D33597#759857, @alc wrote:

Should we introduce analogous functions on amd64 and riscv?

For amd64, which function would it replace? We typically use the step-walk style functions, like pmap_pdpde_to_pde(), pmap_pde_to_pte(), in amd64 pmap, which both makes explicit level argument not useful (and IMO even quite inconvenient to use), and minimizes full-walk functions use (pmap_pte() as is is used twice) . Also we access resulting paging element right away, which means that we panic on NULL accesses without explicit asserts.

Should we introduce analogous functions on amd64 and riscv?

Update comment. Add level KASSERT.

As an aside, while reviewing all of the callers to pmap_pte(), I noticed that pmap_is_prefaultable() is incorrectly implemented. It is going to return FALSE when it should return TRUE, and occasionally the opposite.

See https://reviews.freebsd.org/D33597 for the pmap_pte_exists() prototype.

In D33509#757401, @kib wrote:

May be, it makes sense to add something like pmap_pte_exists() function that asserts that L3 page exists, and use it instead of repeated KASSERT().

I'm confused. I don't see how this change makes any functional difference. The original code set *level == 0 and returned NULL when the L0 entry was not L0_TABLE, and only under those circumstances.

In the commit message, I would somehow explain that the consequence of the bug was only that the wrong reservations might be broken, not that unaligned or inappropriately boundary crossing memory would be returned by contigmalloc(), et al.

I think that's all I have to say.

Individually, the updated comments make perfect sense from a purely localized standpoint, that is, they explain what is happening in that place. However, if I put myself in the place of a first-time reader of this code, the question that I would ask that isn't explained by either the old or updated comments is why any data is paged in at shutdown time.

I will look at this change over the weekend.

In D32515#737492, @markj wrote:

In D32515#737429, @alc wrote:

If you can wait until the weekend, I will look at this then. Weren't there other changes related to replacing preallocation with explicit reservation?

Thank you. There's no real urgency, the problem is limited to kernel sanitizers (which disable UMA_MD_SMALL_ALLOC) and NUMA systems.

I think I made some attempts to merge uma_prealloc() and uma_zone_reserve() but it stalled. That is somewhat orthogonal to this, though, unless I misunderstood.

If you can wait until the weekend, I will look at this then. Weren't there other changes related to replacing preallocation with explicit reservation?

Just to be clear, I believe that I've looked at all of the patches, and unless there is a recent change that you want me to look at, I'm done.

I strongly suspect that the introduction of kern_exec.c's shared page in every address space rendered pmap_remove()'s early termination optimization completely ineffective. (Keep in mind that the shared page belongs to an OBJT_PHYS object, so the shared page has an unmanaged mapping.)

I'm unclear on whether the conditional pmap_page_set_memattr() call was added.

In D31985#733674, @markj wrote:

Is there any objection to committing this and the rest of the series (the reviews listed under the "stack" tab)? Especially with regards to naming since many consumers are being updated.

There are a number of places where VM_ALLOC_NORMAL is missing, but implied. And, given its definition (as 0), we have no way of enforcing its use. So, I'm ready to suggest that we simply eliminate it.

Ultimately, I think that the text will have to grow a new paragraph: (1) mentioning the possible existence of large page sizes on some architectures (See getpagesizes()); (2) that if the specified range does not cover an entire large page, the system will either demote the page mapping to a sufficiently small size or return an error, depending on whether the large page was created automatically or explicitly via shm_open(). In particular, I see no way of describing this without introducing the notion of demotion.