| created | 2021-03-09T19:57:14Z |
|---|---|
| begin | 2021-03-04T00:00:00Z |
| end | 2021-03-05T00:00:00Z |
| path | src/sys |
| commits | 9 |
| date | 2021-03-04T08:38:48Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/uvm/uvm_pager.h | log | diff | annotate |
| src/sys/uvm/uvm_vnode.c | log | diff | annotate | |
| src/sys/uvm/uvm_vnode.h | log | diff | annotate | |
| message |
Bring back previous fix for UVM vnode deadlock. tb@ reports that refaulting when there's contention on the vnode makes firefox start very slowly on his machine. To revisit when the fault handler will be unlocked. ok anton@ Original commit message: Fix a deadlock between uvn_io() and uvn_flush(). While faulting on a page backed by a vnode, uvn_io() will end up being called in order to populate newly allocated pages using I/O on the backing vnode. Before performing the I/O, newly allocated pages are flagged as busy by uvn_get(), that is before uvn_io() tries to lock the vnode. Such pages could then end up being flushed by uvn_flush() which already has acquired the vnode lock. Since such pages are flagged as busy, uvn_flush() will wait for them to be flagged as not busy. This will never happens as uvn_io() cannot make progress until the vnode lock is released. Instead, grab the vnode lock before allocating and flagging pages as busy in uvn_get(). This does extend the scope in uvn_get() in which the vnode is locked but resolves the deadlock. ok mpi@ Reported-by: [email protected] |
|||
| date | 2021-03-04T09:00:03Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/uvm/uvm_anon.c | log | diff | annotate |
| src/sys/uvm/uvm_aobj.c | log | diff | annotate | |
| src/sys/uvm/uvm_km.c | log | diff | annotate | |
| src/sys/uvm/uvm_pdaemon.c | log | diff | annotate | |
| src/sys/uvm/uvm_swap.c | log | diff | annotate | |
| src/sys/uvm/uvmexp.h | log | diff | annotate | |
| message |
Modify `uvmexp.swpgonly' atomically, required for uvm_fault() w/o KERNEL_LOCK() ok kettenis@ |
|||
| date | 2021-03-04T09:02:37Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/kern/kern_sig.c | log | diff | annotate |
| src/sys/kern/kern_synch.c | log | diff | annotate | |
| message |
Merge issignal() and CURSIG() in preparation for turning it mp-safe. This makes appear some redundant & racy checks. ok semarie@ |
|||
| date | 2021-03-04T09:02:38Z | |||
|---|---|---|---|---|
| author | mpi | |||
| files | src/sys/sys/signalvar.h | log | diff | annotate |
| src/sys/ufs/mfs/mfs_vfsops.c | log | diff | annotate | |
| message |
Merge issignal() and CURSIG() in preparation for turning it mp-safe. This makes appear some redundant & racy checks. ok semarie@ |
|||
| date | 2021-03-04T15:38:06Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/arch/mips64/mips64/clock.c | log | diff | annotate |
| message |
Update clock interrupt count atomically. This avoids errors that can arise when multiple cores update the variable at the same time. |
|||
| date | 2021-03-04T16:34:47Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/arch/octeon/dev/octeon_pcibus.c | log | diff | annotate |
| src/sys/arch/octeon/dev/Attic/octeon_pcibusvar.h | log | diff | annotate | |
| message | Combine octeon_pcibusvar.h into octeon_pcibus.c to reduce scatter. | |||
| date | 2021-03-04T16:44:07Z | |||
|---|---|---|---|---|
| author | visa | |||
| files | src/sys/arch/octeon/dev/octeon_pcibus.c | log | diff | annotate |
| message | Tweak whitespace and adjust prototypes. | |||
| date | 2021-03-04T18:32:52Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm64/arm64/cpu.c | log | diff | annotate |
| message |
Print feature that indicates a CPU core supports 16-bit ASIDs. ok patrick@ |
|||
| date | 2021-03-04T18:36:52Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm64/arm64/pmap.c | log | diff | annotate |
| message |
Turns out the cores on Apple's M1 SoC only support 8-bit ASIDs. Thank you Apple (not)! Add an initial attempt to support such systems. This isn't good enough since the kernel will hang once you create more than 127 processes. But it makes things work reasonably well until you reach that limit which is good enough to build things on the machine itself. ok patrick@ |
|||