Page MenuHomeFreeBSD

Unlocked getblk: Fix new false-positive assertion
ClosedPublic

Authored by cem on Aug 1 2020, 5:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Oct 13, 9:40 AM
Unknown Object (File)
Mon, Oct 6, 3:50 AM
Unknown Object (File)
Thu, Sep 18, 9:25 PM
Unknown Object (File)
Sep 16 2025, 3:29 AM
Unknown Object (File)
Sep 16 2025, 2:31 AM
Unknown Object (File)
Aug 26 2025, 3:39 AM
Unknown Object (File)
Aug 2 2025, 10:48 PM
Unknown Object (File)
Jul 1 2025, 12:26 PM
Subscribers

Details

Summary

A free buf's lock may be held (temporarily) due to unlocked lookup, so
buf_alloc() must acquire it without LK_NOWAIT. The unlocked getblk path
should unlock it promptly once it realizes the identity does not match
the buffer it was searching for.

Report by: gallatin

Test Plan

Report from Drew:

getnewbuf_empty: Locked buf 0xfffffe00cf5b52e0 on free queue

I audited the tree for other BUF_LOCK / BUF_TIMELOCK invocations with LK_NOWAIT or LK_SLEEPFAIL; no others seemed problematic.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

cem requested review of this revision.Aug 1 2020, 5:52 PM
cem created this revision.
This revision is now accepted and ready to land.Aug 1 2020, 8:23 PM

I am running tests with the scenario that triggered the panic multiple times.

In D25914#574158, @pho wrote:

I am running tests with the scenario that triggered the panic multiple times.

No problems seen with this test for a 10 hour run.

This revision was automatically updated to reflect the committed changes.

Should we also null out bufobj at buf_free time to ensure the identity check doesn’t match freed bufs, or is that guaranteed somewhere else? It looks like instead, bufobj is nulled on alloc today.