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
Unknown Object (File)
Wed, Dec 11, 9:40 PM
Unknown Object (File)
Sat, Nov 23, 9:51 PM
Unknown Object (File)
Nov 21 2024, 10:00 AM
Unknown Object (File)
Nov 18 2024, 12:49 PM
Unknown Object (File)
Oct 29 2024, 4:04 AM
Unknown Object (File)
Oct 4 2024, 8:27 PM
Unknown Object (File)
Sep 26 2024, 10:59 PM
Unknown Object (File)
Sep 16 2024, 2:55 AM
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

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

Event Timeline

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

share/man/man9/sbuf.9
46 ↗(On Diff #59992)

Oops.

sys/kern/subr_sbuf.c
240 ↗(On Diff #59992)

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

Thanks!

share/man/man9/sbuf.9
46 ↗(On Diff #59992)

vim-o, will fix

sys/kern/subr_sbuf.c
240 ↗(On Diff #59992)

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 ↗(On Diff #59992)

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.