Bug 206219 - Kernel panic from lagg_ioctl and lagg_port_ioctl
Summary: Kernel panic from lagg_ioctl and lagg_port_ioctl
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.2-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-net (Nobody)
URL: https://lists.freebsd.org/pipermail/f...
Keywords: patch
Depends on:
Reported: 2016-01-14 01:43 UTC by Ravi Pokala
Modified: 2017-09-01 06:20 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Ravi Pokala 2016-01-14 01:43:05 UTC
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.

Comment 1 Ravi Pokala 2016-01-14 01:46:56 UTC
The patch is up on Phabricator: https://reviews.freebsd.org/D4929
Comment 2 commit-hook freebsd_committer 2016-01-15 04:06:51 UTC
A commit references this bug:

Author: rpokala
Date: Fri Jan 15 04:05:56 UTC 2016
New revision: 294070
URL: https://svnweb.freebsd.org/changeset/base/294070

  [PR 206219] Kernel panic from lagg_ioctl and lagg_port_ioctl

  r287723 removed some cleanup from lagg(4), which leads to panics when
  changing configuration. Restore the spirit of the code which was removed.
  This issue has been refactored out of existence in -HEAD, so this patch is
  directly against stable/10.

  PR:		206219
  Submitted by:	Fred Lewis < flewis @ panasas.com >
  Reviewed by:	hiren, Daniel O'Connor < darius @ dons.net.au >
  Approved by:	jhb
  Sponsored by:	Panasas, Inc.
  Differential Revision:	https://reviews.freebsd.org/D4929