I would add a debug-only dtor which verifies that the child pointers are zeroed.

In D15560#338076, @cem wrote:

In D15560#337979, @markj wrote:

Apologies for the delay. Would anyone with a Ryzen or TR be able to test a microcode update with the updated patch applied?

I'd be able to if AMD has published any microcode updates for Ryzen/TR. It seems the ones they distribute through non-BIOS channels are just for Epyc.

Isn't this invalid if both the old and new mappings are wired? Or should it not be possible

In D15910#338067, @alc wrote:

In D15910#337632, @kib wrote:

In D15910#337582, @alc wrote:

1. In regards to pmap_enter(), we should aim to kill two birds with one stone. Recall the copy-on-write mapping bug that Kostik worked around in vm_fault(). I say worked around because the root cause is here in pmap_enter(). When the physical page mapped at va is changing, pmap_enter() should destroy the old mapping before creating the new one. Once pmap_enter() is restructured in this way, you can simply recycle the old mapping's PV entry.

Can you elaborate more, please ? What do you mean by destroying the old mapping ? In particular, do you mean installing the pte with clear PG_V into the changing PTE ?

Yes, I mean destroying the PTE, including TLB shootdown. In effect, briefly the PTE will be 0. Then, installing the new PTE is just a pte_store(). All of the stuff that we currently perform under "if ((origpte & PG_V) != 0) {" will already have been performed when we destroyed the PTE.

• Only set "reclaimed" once when executing the loop.
• Fix the problem in the arm64 pmap code.

Apologies for the delay. Would anyone with a Ryzen or TR be able to test a microcode update with the updated patch applied?

Only update microcode on physical CPUs.

I note that arm64 has this bug as well. I'll fix that identically if the current diff is ok.

• Only recount after a reclaim.

In D15910#337582, @alc wrote:

I have two comments.

1. The change to reserve_pv_entries() is unnecessary. That function is only called during demotion. At that point, the only PV entry will be for the superpage mapping, and reclaim_pv_chunk() already skips superpage mappings.

In D15911#336659, @kib wrote:

This should be fine.

Can we return an indicator if the page freed from the locked pmap, and retry only in this case ?

In D15560#336684, @sbruno wrote:

bump. @markj Did you want to shovel this into head?

I'll admit that I've never seen any reason to prefer dtruss to truss(1).

I think this is fine. The panic string buffer is bigger than it needs to be.

Regarding the testing section, after running pgbench in a loop for roughly 12 hours, I see:

• Address some review feedback.

• Remove brk.S from MDASM in a couple more places.

Check for non-dump I/O in biodone() instead.

In D15607#330348, @cem wrote:

In D15607#330347, @jhb wrote:

I do think it was intentional to truncate once the output buffer was exhausted rather than failing with ENOMEM. Its debatable if that is a useful thing or not. Most sysctls return ENOMEM instead so that the request can be retried with a larger output buffer so it is probably better to do what this does.

That makes sense in sysctl context. I'm not sure it makes sense in core dump context. Maybe it does, but it would probably require additional changes there.

In D15592#329715, @imp wrote:

So I'm still uneasy about this.

Why are we doing this at the lowest levels? Some of the CCBs that might be completed are for components that are fine during a dump. This is an upper layer problem, not a CAM problem. Wouldn't it make more sense to do this in biodone or bufdone? That way we don't have to worry about tagging every last little thing with CAM_CCB_DUMP that needs it. Since we're doing the dump, that won't go through the upper layers at all. If we put the block at the entry to geom, or the exit from geom, that would accomplish the same thing.

• Update the comment per imp's remark.

• Use an if statement.

In D15607#329598, @cem wrote:

I don't see how this affects tmux in any way, unless the error code breaks the previously working-but-truncated path(s). If that's the case, I think those should be changed to swallow ENOMEM. But then, what's the point of propagating the error up?

• Fix nvme compilation; use sim_links linkage instead of periph_links.

• Check "dumping" as well, in case kern.sync_on_panic is set.

In D15523#328786, @sbruno wrote:

In D15523#328555, @markj wrote:

In D15523#327973, @sbruno wrote:

Trying out some debugging here. Can someone apply this patch
https://people.freebsd.org/~sbruno/cpucontrol.diff.txt

And send me the results of something like the following?

I get the same output, i.e., "CPU is not found in the equivalence table" for all files.

Can you post the detection output for your CPU? I assume you have a 17h here, but I'm not sure.

In D15523#327973, @sbruno wrote:

Trying out some debugging here. Can someone apply this patch
https://people.freebsd.org/~sbruno/cpucontrol.diff.txt

And send me the results of something like the following?

In D15560#328520, @avg wrote:

@markj something like that, yes.
I am not sure if logical_cpus_mask is accurate on Ryzen, but I think that we collect enough topology information to either make it correct or to provide another way of checking whether a CPU is a "primary" thread of a core.

In D15560#328515, @avg wrote:

I think that it should be relatively easy to instruct threads to do either an update or just a spin.
Having said that, I won't object against this change if it fixes a problem that has been experienced.