Page MenuHomeFreeBSD

Unlocked getblk: Fix new false-positive assertion
ClosedPublic

Authored by cem on Aug 1 2020, 5:52 PM.

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
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; 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.