Created attachment 232736 [details] Script to trigger epair panic This panic looks very similar to bug #234985 and can be triggered easily using the attached crash_epair.sh script. Tested on: - 13.0-RELEASE-p8 - 13.1-BETA1 - 13.1-BETA2 If it helps, I could create a separate PR for 13.0 (as epair changed a lot, crashdumps differ), but for know I would like to keep the discussion in one place.
Created attachment 232737 [details] Crashinfo on 13.0-RELEASE-p8
Created attachment 232738 [details] Crashinfo on 13.1-BETA2
Created attachment 232787 [details] Test patch for main Can you give this patch a try (it's against main and likely will not apply to 13)?
(In reply to Kristof Provost from comment #3) Patch applies cleanly to 13.1-BETA2 and seems to work, ifconfig emits this error instead (which I assume is the intended outcome): ifconfig: SIOCSIFVNET: Operation not supported by device jail: /sbin/ifconfig epair0b vnet myjail: failed
(In reply to Michael Gmelin from comment #4) > ifconfig emits this error instead To clarify: ifconfig now reports an error if it's trying to vmove while the interface is being destroyed instead of causing a kernel panic. So the patch works for me on 13.1-BETA2 without changes.
@kp What about landing this patch in CURRENT, so there is a chance to later MFC to stable/13, releng/13? This way it could land in 13.1-pX or at least 13.2 eventually.
Please read the review https://reviews.freebsd.org/D34704 for the current state.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=868bf82153e8ff22f09a8860c872149e0fb6bdef commit 868bf82153e8ff22f09a8860c872149e0fb6bdef Author: Kristof Provost <kp@FreeBSD.org> AuthorDate: 2022-03-27 18:23:25 +0000 Commit: Kristof Provost <kp@FreeBSD.org> CommitDate: 2022-05-06 11:55:08 +0000 if: avoid interface destroy race When we destroy an interface while the jail containing it is being destroyed we risk seeing a race between if_vmove() and the destruction code, which results in us trying to move a destroyed interface. Protect against this by using the ifnet_detach_sxlock to also covert if_vmove() (and not just detach). PR: 262829 MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D34704 sys/net/if.c | 22 ++++++++++++++++++++-- tests/sys/net/if_clone_test.sh | 29 +++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+), 2 deletions(-)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=4dfd3ffc4488e5e2662cdc40deec17d82432da0b commit 4dfd3ffc4488e5e2662cdc40deec17d82432da0b Author: Kristof Provost <kp@FreeBSD.org> AuthorDate: 2022-03-27 18:23:25 +0000 Commit: Kristof Provost <kp@FreeBSD.org> CommitDate: 2022-05-27 16:25:10 +0000 if: avoid interface destroy race When we destroy an interface while the jail containing it is being destroyed we risk seeing a race between if_vmove() and the destruction code, which results in us trying to move a destroyed interface. Protect against this by using the ifnet_detach_sxlock to also covert if_vmove() (and not just detach). PR: 262829 MFC after: 3 weeks Differential Revision: https://reviews.freebsd.org/D34704 (cherry picked from commit 868bf82153e8ff22f09a8860c872149e0fb6bdef) sys/net/if.c | 22 ++++++++++++++++++++-- tests/sys/net/if_clone_test.sh | 29 +++++++++++++++++++++++++++++ 2 files changed, 49 insertions(+), 2 deletions(-)
Was this patch applied to a release? Currently using 13.1-RELEASE and having this issue.
(In reply to Alex Seitsinger from comment #10) The fix is in 13.2-RELEASE.
^Triage: assign to committer that resolved. Apparently now in all supported releases.