[Bug 297777] geom_part: access leaked when a resized table is spoiled, wedging all USB enumeration

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=297777

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

URL:
https://cgit.FreeBSD.org/src/commit/?id=35b59986b5aaedbafefbb79e3da30789ca9aeb24

commit 35b59986b5aaedbafefbb79e3da30789ca9aeb24
Author:     Warner Losh <imp@FreeBSD.org>
AuthorDate: 2026-10-04 19:19:59 +0000
Commit:     Warner Losh <imp@FreeBSD.org>
CommitDate: 2026-10-04 19:21:17 +0000

    g_part: access leak causes process to hang

    So if one inserts a USB drive with a GPT that doesn't match the media
    size, a resize is initiated, so gpart takes g_access(cp, 1, 1, 1) on the
    disk and holds it until the resize is accepted or rejected. The orphan
    path releases it, but the spoil path does not. So if the drive is
    ejected while the resize is in flight, we call spoil directly, without
    releasing the access. Since gpt_opened is not cleared for the spoil
    path, this causes several different process to hang in the open path
    waiting for the leaked access.

    Move the release into the wither function when gpt_opened is set, and
    remove the release elsewhere. Since all paths to destroy the geom pass
    through wither, this ensure that access is always released when we've
    taken the access for resize.

    PR:                     297777
    Reported by:            Rick Richard
    MFC After:              1 week
    Sponsored by:           Netflix
    Differential Revision:  https://reviews.freebsd.org/D59138

 sys/geom/part/g_part.c | 14 +++-----------
 1 file changed, 3 insertions(+), 11 deletions(-)

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