[Bug 254333] [tcp] sysctl net.inet.tcp.hostcache.list hangs

[bugzilla-noreply at freebsd.org]

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

Richard Scheffenegger <rscheff at freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rscheff at freebsd.org

--- Comment #4 from Richard Scheffenegger <rscheff at freebsd.org> ---
I just noticed, that sysctl will actually do a syscall to sysctl twice.
First, with no buffer space - expecting to receive the size to allocate for a
buffer, then it tries to allocate twice as much buffer (apparently "for
reasons"), before doing the syscall to sysctl a 2nd time.

As the system continues to run, I am curious how large the list of hostcache
entries is just prior to the "freeze" (of sysctl), and if the system may be
space-constrained.

Note that during the call, it appears that both kernel and userspace need
memory (twice as much in the userspace). userspace seems to use a non-blocking
malloc call, after the first round where the return length is checked.

Possibly the system has a hard time allocating a sufficiently large chunk of
memory, if the hostcache is fully utilized and extremely busy...

In sbuf_new, the kernel is trying a malloc(size, M_SBUF, M_WAITOK|M_ZERO)...

Perhaps the sysctl callback procedure could be improved to 
a) not actually allocate memory when the user has not yet provided a buffer to
fill - only return the require size (reducing the chances to run out-of-space
somewhat)

b) not allocate a huge chunk in sbuf_new right away, but use sbuf_extend
repeatedly (although sbuf.c will actually grab a larger chunk of memory, copy
the data over,and release the old chunk - thus driving temporary memory
requirements higher

c) use a different memory model supporting disjoint segments of a c-string
scattered in smaller memory chunks, subsequently concatenating them on the
SYSCTL_OUT.

d) change the M_WAITOK in /kern/subr_sbuf.c#59 to M_NOWAIT and expect an error
on very busy systems every once in a while.


As a reasonable short term fix, I guess a combination of M_NOWAIT in sbuf.c and
use of sbuf_new(smaller size) / sbuf_extend(smaller_size) may be the prudent
approach, if this turns out to be the culprit.

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