Re: sysctl -a panic on VIMAGE kernels

On Sun, Aug 9, 2015 at 6:36 AM, Gleb Smirnoff <glebius_at_freebsd.org> wrote:

> On Sun, Aug 09, 2015 at 12:28:22PM +0200, Kristof Provost wrote:
> K> Hi,
> K>
> K> I’ve run into a reproducible panic on a VIMAGE kernel with ‘sysctl -a’.
> K>
> K> Relevant backtrace bits:
> K> #8  0xffffffff80e7dd28 in trap (frame=0xfffffe01f16b26a0)
> K>     at /usr/src/sys/amd64/amd64/trap.c:426
> K> #9  0xffffffff80e5e6a2 in calltrap ()
> K>     at /usr/src/sys/amd64/amd64/exception.S:235
> K> #10 0xffffffff80cea67d in uma_zone_get_cur (zone=0x0)
> K>     at /usr/src/sys/vm/uma_core.c:3006
> K> #11 0xffffffff80cec029 in sysctl_handle_uma_zone_cur (
> K>     oidp=0xffffffff818a7c90, arg1=0xfffffe00010c0438, arg2=0,
> K>     req=0xfffffe01f16b2868) at /usr/src/sys/vm/uma_core.c:3580
> K> #12 0xffffffff80a28614 in sysctl_root_handler_locked
> (oid=0xffffffff818a7c90,
> K>     arg1=0xfffffe00010c0438, arg2=0, req=0xfffffe01f16b2868)
> K>     at /usr/src/sys/kern/kern_sysctl.c:183
> K> #13 0xffffffff80a27d70 in sysctl_root (arg1=<value optimized out>,
> K>     arg2=<value optimized out>) at /usr/src/sys/kern/kern_sysctl.c:1694
> K> #14 0xffffffff80a28372 in userland_sysctl (td=0x0,
> name=0xfffffe01f16b2930,
> K>     namelen=<value optimized out>, old=<value optimized out>,
> K>     oldlenp=<value optimized out>, inkernel=<value optimized out>,
> K>     new=<value optimized out>, newlen=<value optimized out>,
> K>     retval=<value optimized out>, flags=0)
> K>     at /usr/src/sys/kern/kern_sysctl.c:1798
> K> #15 0xffffffff80a28144 in sys___sysctl (td=0xfffff8000b1e49a0,
> K>     uap=0xfffffe01f16b2a40) at /usr/src/sys/kern/kern_sysctl.c:1724
> K>
> K> In essence, what happens is that we end up in
> sysctl_handle_uma_zone_cur() and arg1 is a pointer to NULL,
> K> so we call uma_zone_get_cur(zone); with zone == NULL.
> K>
> K> There’s been a bit of churn around tcp_reass_zone, and I think the
> latest version is wrong.
> K> It marks the sysctl as CTLFLAG_VNET, but the exposed variable is not
> VNET_DEFINE().
> K>
> K> The following fixes it for me:
> K>
> K> diff --git a/sys/netinet/tcp_reass.c b/sys/netinet/tcp_reass.c
> K> index 77d8940..3913ef3 100644
> K> --- a/sys/netinet/tcp_reass.c
> K> +++ b/sys/netinet/tcp_reass.c
> K> _at__at_ -84,7 +84,7 _at__at_ SYSCTL_INT(_net_inet_tcp_reass, OID_AUTO,
> maxsegments, CTLFLAG_RDTUN,
> K>      "Global maximum number of TCP Segments in Reassembly Queue");
> K>
> K>  static uma_zone_t tcp_reass_zone;
> K> -SYSCTL_UMA_CUR(_net_inet_tcp_reass, OID_AUTO, cursegments,
> CTLFLAG_VNET,
> K> +SYSCTL_UMA_CUR(_net_inet_tcp_reass, OID_AUTO, cursegments, 0,
> K>      &tcp_reass_zone,
> K>      "Global number of TCP Segments currently in Reassembly Queue”);
>
> Right, if a variable isn't virtualized, the CTLFLAG_VNET must be removed.
>
> Patrick, how is your progress wuth improved reassembly?
>

Kristof, thanks for committing this patch.

Gleb, I expect to have a tcp reassembly patch up for review at some point
this week.

-Patrick