Re: git: 35b59986b5aa - main - g_part: access leak causes process to hang

On 2026-10-04 21:22, Warner Losh wrote:
> The branch main has been updated by imp:
>
> 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


Hello,

are you still planning to MFC this?

I noted two more of your highly appreciated contributions as MFC-timer 
lapsed:
0bc6c9279e51 - main - da: Stop the probing when periph invalidated in 
dadone_proberc
e2bcab51fb50 - main - da: Fix logic error

Maybe this is a desireable MFC candidate as well:
b5f0e7f36afc - main - loader.efi: Be cautious about using GOPs

Thanks,

-harry