20191125 08:32:45 all (271/680): proccontrol.sh
panic: caller failed to provide space 0x400000 at address 0x800a56000
cpuid = 4
time = 1574667167
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe01b74cc6c0
vpanic() at vpanic+0x17e/frame 0xfffffe01b74cc720
panic() at panic+0x43/frame 0xfffffe01b74cc780
vm_map_alignspace() at vm_map_alignspace+0x9b/frame 0xfffffe01b74cc7f0
vm_map_find() at vm_map_find+0x697/frame 0xfffffe01b74cc8b0
vm_map_find_min() at vm_map_find_min+0x85/frame 0xfffffe01b74cc930
vm_mmap_object() at vm_mmap_object+0x395/frame 0xfffffe01b74cc9c0
kern_mmap() at kern_mmap+0x56b/frame 0xfffffe01b74ccaa0
sys_mmap() at sys_mmap+0x2a/frame 0xfffffe01b74ccac0
amd64_syscall() at amd64_syscall+0x2f1/frame 0xfffffe01b74ccbf0
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfffffe01b74ccbf0
--- syscall (477, FreeBSD ELF64, sys_mmap), rip = 0x800ec3f6a, rsp = 0x7fffff8ea238, rbp = 0x7fffff8ea250 ---
KDB: enter: panic
[ thread pid 65014 tid 102218 ]
Stopped at      kdb_enter+0x37: movq    $0,0x1082cc6(%rip)
db>

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

I am going to commit this soon if there are no objections.

Reconsider a pessimization to vm_map_findspace.

Remove the bits that have been checked in separately.

thank you

In D22527#492846, @markj wrote:

As far as I know the only reason to disallow sleeping readers is that rmlock trackers typically live on the stack, and the stacks of sleeping threads may be swapped out. That seems like a fairly dubious reason in this day and age - do you know of any other reasons?

In D22527#492846, @markj wrote:

As far as I know the only reason to disallow sleeping readers is that rmlock trackers typically live on the stack, and the stacks of sleeping threads may be swapped out. That seems like a fairly dubious reason in this day and age - do you know of any other reasons?

inet_pton() stroes network byte order, so lose the original (now extra)
htonl() and unbreak IPv4 support.

As far as I know the only reason to disallow sleeping readers is that rmlock trackers typically live on the stack, and the stacks of sleeping threads may be swapped out. That seems like a fairly dubious reason in this day and age - do you know of any other reasons?

Take out the parts that have been check in separately. Leave in the renaming parts from a patch awaiting review. Macro-size some splay-helper functions to help improve performance.

In D22515#492391, @emaste wrote:

Do you think we could add all of these test cases to the tree somewhere?

Revision intentionally abandoned.

In D22532#492817, @otis_sk.freebsd.org wrote:

The last comment there was that Juraj volonteered to maintain the port. Is he a member of the elastic@ team?

• I refer to comment no. 5 from feld@
• I am Juraj Lutter

In D22532#492810, @girgen wrote:

In D22532#492809, @otis_sk.freebsd.org wrote:

In D22532#492806, @girgen wrote:

I agree with the change, but I reckon this should primarliy be approved by feld@.

Palle

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237372 for my reasoning. feld@ is not going to maintain it any longer so setting it to elastic@ seems more apropriate.

The last comment there was that Juraj volonteered to maintain the port. Is he a member of the elastic@ team?

In D22532#492809, @otis_sk.freebsd.org wrote:

In D22532#492806, @girgen wrote:

I agree with the change, but I reckon this should primarliy be approved by feld@.

Palle

See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237372 for my reasoning. feld@ is not going to maintain it any longer so setting it to elastic@ seems more apropriate.

In D22532#492806, @girgen wrote:

I agree with the change, but I reckon this should primarliy be approved by feld@.

Palle

I agree with the change, but I reckon this should primarliy be approved by feld@.

In D22535#492799, @otis_sk.freebsd.org wrote:

Yes, this one was created by my accidental misuse of arc diff.