Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Jun 2023 17:01:29 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 272089] FreeBSD -CURRENT panic: panic invalid slot (wg(4) related)
Message-ID:  <bug-272089-7501-OCfcWjVdy5@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-272089-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-272089-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D272089

--- Comment #4 from commit-hook@FreeBSD.org ---
A commit in branch main references this bug:

URL:
https://cgit.FreeBSD.org/src/commit/?id=3Db08ee10c0646e683cd03c9e28f537d9a7=
ba306af

commit b08ee10c0646e683cd03c9e28f537d9a7ba306af
Author:     Kyle Evans <kevans@FreeBSD.org>
AuthorDate: 2023-06-21 18:56:58 +0000
Commit:     Kyle Evans <kevans@FreeBSD.org>
CommitDate: 2023-06-23 17:00:09 +0000

    wg: fix a number of issues with module load failure handling

    If MOD_LOAD fails, then MOD_UNLOAD will be called to unwind module
    state, but wg_module_init() will have already deinitialized everything
    it needs to in a manner that renders it unsafe to call MOD_UNLOAD
    after (e.g., freed zone not reset to NULL, wg_osd_jail_slot not reset
    to 0).  Let's simply stop trying to handle freeing everything in
    wg_module_init() to simplify it; let the subsequent MOD_UNLOAD deal with
    it, and let's make that robust against partially-constructed state.

    jhb@ notes that MOD_UNLOAD being called if MOD_LOAD fails is kind of an
    anomaly that doesn't match other paradigms in the kernel; e.g., if
    device_attach() fails, we don't invoke device_detach().  It's likely
    that a future commit will revert this and instead stop calling
    MOD_UNLOAD if MOD_LOAD fails, expecting modules to clean up after
    themselves in MOD_LOAD upon failure.  Some other modules already do this
    and may see similar problems to the wg module (see: carp).  The proper
    fix is decidedly a bit too invasive to do this close to 14 branching,
    and it requires auditing all kmods (base + ports) for potential leaks.

    PR:             272089
    Reviewed by:    emaste
    MFC after:      3 days
    Differential Revision:  https://reviews.freebsd.org/D40708

 sys/dev/wg/if_wg.c     | 28 +++++++++-------------------
 sys/dev/wg/wg_cookie.c |  9 ++++++++-
 2 files changed, 17 insertions(+), 20 deletions(-)

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-272089-7501-OCfcWjVdy5>