clip without corrupting map

[dougm]

Summary

The clipping functions modify start and end entries of an entry in the vm_map, making invariants related to the max_free entry field invalid. Move the clipping work into vm_map_entry_link, so that linking is okay when the new entry clips a current entry, and the vm_map doesn't have to be briefly corrupted. Change assertions and conditions in SPLAY_{LEFT,RIGHT}_STEP since the max_free invariants can now be trusted in all cases.

[pho]

With D22897.65888.diff I got this after 5 hours:

20191221 15:05:39 all (182/683): nfs15lockd3.sh
panic: pmap_is_modified: page 0xfffffe00211cd888 is not managed
cpuid = 6
time = 1576937152
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe0994268540
vpanic() at vpanic+0x17e/frame 0xfffffe09942685a0
panic() at panic+0x43/frame 0xfffffe0994268600
pmap_is_modified() at pmap_is_modified+0x32/frame 0xfffffe0994268610
vm_page_test_dirty() at vm_page_test_dirty+0x1f/frame 0xfffffe0994268630
vfs_setdirty_range() at vfs_setdirty_range+0x2d/frame 0xfffffe0994268650
bdwrite() at bdwrite+0x17a/frame 0xfffffe09942686c0
ffs_update() at ffs_update+0x31d/frame 0xfffffe0994268720
ufs_inactive() at ufs_inactive+0x267/frame 0xfffffe0994268760
VOP_INACTIVE_APV() at VOP_INACTIVE_APV+0x60/frame 0xfffffe0994268780
vinactive() at vinactive+0xf4/frame 0xfffffe09942687d0
vputx() at vputx+0x275/frame 0xfffffe0994268830
vput() at vput+0x39/frame 0xfffffe0994268860
kern_funlinkat() at kern_funlinkat+0x302/frame 0xfffffe0994268aa0
sys_unlink() at sys_unlink+0x28/frame 0xfffffe0994268ac0
amd64_syscall() at amd64_syscall+0x2f1/frame 0xfffffe0994268bf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe0994268bf0
--- syscall (10, FreeBSD ELF64, sys_unlink), rip = 0x80041257a, rsp = 0x7fffffffd1e8, rbp = 0x7fffffffd230 ---

https://people.freebsd.org/~pho/stress/log/dougm069.txt

[dougm]

In D22897#501357, @pho wrote:

With D22897.65888.diff I got this after 5 hours:

Is this problem addressed by r355985?

[pho]

In D22897#501467, @dougm wrote:

In D22897#501357, @pho wrote:

With D22897.65888.diff I got this after 5 hours:

Is this problem addressed by r355985?

I can not say for sure. Recreating the panic is not easy. Maybe Mark has a more helpful answer?

[markj]

In D22897#501537, @pho wrote:

In D22897#501467, @dougm wrote:

In D22897#501357, @pho wrote:

With D22897.65888.diff I got this after 5 hours:

Is this problem addressed by r355985?

I can not say for sure. Recreating the panic is not easy. Maybe Mark has a more helpful answer?

Yes I think it should be fixed by r355985. At least, the bug fixed in r355985 could cause this panic. This is a VMIO buffer and so should contain managed pages.

[dougm]

Yes I think it should be fixed by r355985. At least, the bug fixed in r355985 could cause this panic. This is a VMIO buffer and so should contain managed pages.

Peter, could you retest this please?

[pho]

In D22897#503110, @dougm wrote:

Yes I think it should be fixed by r355985. At least, the bug fixed in r355985 could cause this panic. This is a VMIO buffer and so should contain managed pages.

Peter, could you retest this please?

Sure, I'll do that later today.

[pho]

I ran a partial test with this patch and r356153 for 16 hours / 577 tests. No problems seen.

[alc]

sys/vm/vm_map.c

1381

I think that you need to write comments (1) explaining the three cases and (2) motivating the new breakdown of responsibility between this function and the clipping functions.

[dougm]

Add comments.