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)
Dec 22 2023, 10:46 PM
Unknown Object (File)
Nov 14 2023, 6:24 PM
Unknown Object (File)
Sep 5 2023, 10:40 PM
Unknown Object (File)
Aug 4 2023, 4:25 AM
Unknown Object (File)
Aug 4 2023, 4:25 AM
Unknown Object (File)
Aug 4 2023, 4:21 AM
Unknown Object (File)
Aug 4 2023, 3:48 AM
Unknown Object (File)
Apr 6 2023, 6:41 AM
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.