Page MenuHomeFreeBSD

g_part: access leak causes process to hang
ClosedPublic

Authored by imp on Aug 24 2026, 3:15 AM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, Oct 10, 7:23 PM
Unknown Object (File)
Sat, Oct 10, 10:18 AM
Unknown Object (File)
Sat, Oct 10, 7:48 AM
Unknown Object (File)
Fri, Oct 9, 11:34 PM
Unknown Object (File)
Fri, Oct 9, 11:32 PM
Unknown Object (File)
Fri, Oct 9, 6:46 AM
Unknown Object (File)
Fri, Oct 9, 5:29 AM
Unknown Object (File)
Thu, Oct 8, 7:12 PM

Details

Summary

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, and don't
release 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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

imp requested review of this revision.Aug 24 2026, 3:15 AM
imp created this revision.

Sorry it took so long to test this, I needed the machine to stay up for a while.

I just tested your patch on a second machine. First I reproduced the problem with the same SD card and card reader, then I applied your patch and tested again. dtrace shows the problem path get executed and the fix working, so this is good!

This revision was not accepted when it landed; it landed in state Needs Review.Sun, Oct 4, 7:22 PM
This revision was automatically updated to reflect the committed changes.