Summary: | epair: New panic when destroying epair interface of vnet jail | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Michael Gmelin <grembo> | ||||||||||
Component: | kern | Assignee: | Kristof Provost <kp> | ||||||||||
Status: | Closed FIXED | ||||||||||||
Severity: | Affects Some People | CC: | alexseitsinger, bz, crest, kp, pat | ||||||||||
Priority: | --- | ||||||||||||
Version: | 13.1-RELEASE | ||||||||||||
Hardware: | Any | ||||||||||||
OS: | Any | ||||||||||||
URL: | https://reviews.freebsd.org/D34704 | ||||||||||||
Attachments: |
|
Description
Michael Gmelin
2022-03-26 13:18:40 UTC
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. |