[Bug 206219] Kernel panic from lagg_ioctl and lagg_port_ioctl

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Jan 14 01:43:06 UTC 2016


            Bug ID: 206219
           Summary: Kernel panic from lagg_ioctl and lagg_port_ioctl
           Product: Base System
           Version: 10.2-STABLE
          Hardware: Any
               URL: https://lists.freebsd.org/pipermail/freebsd-net/2016-J
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: rpokala at panasas.com
                CC: flewis at panasas.com

>From freebsd-net@:

Hi FreeBSD Networking folks.

We are seeing a kernel panics on stable/10 that are being caused by
lagg_ioctl() and lagg_port_ioctl().
The panic occurs when moving from an lacp configuration to, say, a
failover configuration.

Please double-check me, but what appears to be happening is that the
software context is not getting
cleaned up properly on a mode change and lacp_portreq() is getting called
when the lagg is set to failover
mode. In particular, sc->sc_portreq is left  pointing to lacp_portreq when
the mode is no longer lacp.

In earlier versions of lagg_ioctl() (e.g. stable/10/r171247) all of the
vectors are set to NULL which I think will prevent the problem. Similar
NULLing code
is also in stable/7. I didn't check other releases.

   if (sc->sc_proto != LAGG_PROTO_NONE) {
           error = sc->sc_detach(sc);
           /* Reset protocol and pointers */
           sc->sc_proto = LAGG_PROTO_NONE;
           sc->sc_detach = NULL;
           sc->sc_start = NULL;
           sc->sc_input = NULL;
           sc->sc_port_create = NULL;
           sc->sc_port_destroy = NULL;
           sc->sc_linkstate = NULL;
           sc->sc_init = NULL;
           sc->sc_stop = NULL;
           sc->sc_lladdr = NULL;
           sc->sc_req = NULL;
           sc->sc_portreq = NULL;

Looks like the above code was taken out via r287723.

Evidently this has been made moot in HOL via r272170 and r272178 (maybe

Here is one of the backtrace snippets:

panic() at panic+0x155/frame 0xfffffe201e3df2e0
trap_fatal() at trap_fatal+0x38f/frame 0xfffffe201e3df340
trap_pfault() at trap_pfault+0x308/frame 0xfffffe201e3df3e0
trap() at trap+0x47a/frame 0xfffffe201e3df5f0
calltrap() at calltrap+0x8/frame 0xfffffe201e3df5f0
--- trap 0xc, rip = 0xffffffff804b9811, rsp = 0xfffffe201e3df6b0, rbp =
0xfffffe201e3df730 ---
__mtx_lock_sleep() at __mtx_lock_sleep+0x1a1/frame 0xfffffe201e3df730
__mtx_lock_flags() at __mtx_lock_flags+0x5a/frame 0xfffffe201e3df750
lacp_portreq() at lacp_portreq+0x2f/frame 0xfffffe201e3df780
lagg_port2req() at lagg_port2req+0x62/frame 0xfffffe201e3df7b0
lagg_port_ioctl() at lagg_port_ioctl+0x14b/frame 0xfffffe201e3df820
ifioctl() at ifioctl+0x162b/frame 0xfffffe201e3df8e0
kern_ioctl() at kern_ioctl+0x255/frame 0xfffffe201e3df950
sys_ioctl() at sys_ioctl+0x13c/frame 0xfffffe201e3df9a0

Is there any chance of getting this fixed in stable/10 before code freeze?

We have tested a set of diffs that  fix the issue and will submit them for
review shortly.


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

More information about the freebsd-bugs mailing list