Re: [PATCH] ufs: free the buffer head container in ubh_bforget

[Ali Ahmet Memis <ali@iusegentoo.com>]

On Sun, Aug 02 2026, Luis Henriques wrote:

> But the fix still looks OK.  My original patch also dropped the 'if',
> but that's just a minor detail.

It is not only cosmetic, and your own commit message already gave the
reason: bforget() is a no-op for a NULL buffer head. ubh_brelse() has no
such test either, so dropping it is what actually makes the two functions
match, which is what the changelog claims. v2 is posted with that
changed:

  https://lore.kernel.org/all/20260802114130.6261-1-ali@iusegentoo.com/

That makes v2 the same change as your 2018 patch. If you would rather it
went in under your authorship, say so and I will resend it that way. Your
posting got no replies at all back then, so it stalled rather than being
turned down.

> I don't know who's using this ufs driver these days -- each BSD has
> it's own thing, and it's likely to be risky to mount a filesystem in
> rw mode.

It is risky, and I have been finding out how much. I sent a series
yesterday for cases where fs/ufs mishandles filesystems that are
perfectly valid rather than crafted, among them a short symlink carrying
extended attributes: because the fast symlink test looks at i_blocks
instead of i_size, the link target is taken for a block pointer array,
readlink walks off the device and unlink hands the target bytes to
ufs_free_fragments().

  https://lore.kernel.org/all/20260801225530.148386-1-ali@iusegentoo.com/

So the read-write path could use more attention rather than less, at
least while it is still in the tree and mountable.

If v2 looks right to you, an Acked-by would help it move along. The
diagnosis was yours.

Apologies if this and the v2 reach you twice or late: I took your address
from the 2018 posting and mail to it bounced, so your copies did not go
out with the rest.

Thanks for looking at this after so long.

--
Ali