Page MenuHomeFreeBSD

sbuf(9): Add NOWAIT dynamic buffer extension mode
ClosedPublic

Authored by cem on Jul 21 2019, 5:17 PM.
Tags
None
Referenced Files
F82108180: D21015.id60003.diff
Thu, Apr 25, 3:05 PM
F82104118: D21015.diff
Thu, Apr 25, 2:08 PM
F82094685: D21015.id59991.diff
Thu, Apr 25, 11:00 AM
F82072086: D21015.id59992.diff
Thu, Apr 25, 6:22 AM
Unknown Object (File)
Wed, Apr 24, 6:37 PM
Unknown Object (File)
Tue, Apr 23, 9:53 PM
Unknown Object (File)
Fri, Apr 19, 2:47 AM
Unknown Object (File)
Tue, Apr 16, 10:17 PM
Subscribers

Details

Summary

The goal is to avoid some kinds of low-memory deadlock when formatting
buffers.

Test Plan

This reconciles one of the few semantic gaps between our in-house sbuf clone
and sbuf(9).

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 25444
Build 24070: arc lint + arc unit

Event Timeline

Need to M_NOWAIT the allocation in sbuf_newbuf for this use case as well.

share/man/man9/sbuf.9
46

Oops.

sys/kern/subr_sbuf.c
240

Why do we ignore SBUF_NOWAIT in flags here? (Was this just for testing?)

Thanks!

share/man/man9/sbuf.9
46

vim-o, will fix

sys/kern/subr_sbuf.c
240

This one is actually constructing the struct sbuf itself. I don't see much value in a heap version of that one that gracefully handles OOM, but I don't feel strongly about it. If you'd prefer it for consistency, I'm happy to use the flag here as well.

cem marked an inline comment as done.

Fix the typo in sbuf.9

sys/kern/subr_sbuf.c
240

I agree that it doesn’t seem useful, but I think it’s best to be consistent. If the caller passes NOWAIT, blocking in malloc would be astonishing behavior.

cem marked 2 inline comments as done.

Extend use of NOWAIT flag to initial heap sbuf allocation.

This revision is now accepted and ready to land.Jul 22 2019, 1:41 AM
This revision was automatically updated to reflect the committed changes.