[Bug 293382] Dead lock and kernel crash around closefp_impl

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=293382

Kyle Evans <kevans@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alc@FreeBSD.org

--- Comment #75 from Kyle Evans <kevans@freebsd.org> ---
CC alc@

Kristofer can shed a little more detail later, but the summary so far is that
we seem to have a few reports of issues that can be traced back to bad
interactions with INVLGPGB/EFER.TCE on some Gen 4/5 EPYC hardware.  Kristofer
ran his memcpy test with the following results (hw.tce_disable being a knob he
patched in to disable it):

 - vm.pmap.invlpgb_works=1, hw.tce_disable=0: memory corruption
 - vm.pmap.invlpgb_works=1, hw.tce_disable=1: no memory corruption
 - vm.pmap.invlpgb_works=0, hw.tce_disable=0: no memory corruption
 - vm.pmap.invlpgb_works=0, hw.tce_disable=1: no memory corruption

An excerpt of his speculation:

```
The commit (1c1acaf6858be) also mentions INVLPG (i.e. ... targeted TLB
invalidation instructions, such as invlpg, only ...) which invalidates TLB
entries on only the local CPU however INVLPGB is a broadcast TLB invalidation
on all cores. With EFER.TCE=0, this would invalidate all upper level TLB
entries on all cores whereas with EFER.TCE=1 upper level TLB entries on other
cores would only be flushed if they matched the path on the core that invoked
INVLPGB.

The scenario I'm wondering about is if the other core had the PDE cached (2nd
level) but not the invalidated page so not flushed while the first core
replaces the PDE due to the large number of pages being mapped (i.e. it goes
over a 2MB boundary).

There's a lot of code in the guts of vm & pmap and I don't have a good enough
sense what goes on with allocation/mapping and page table management.
```

-- 
You are receiving this mail because:
You are the assignee for the bug.