Page MenuHomeFreeBSD

bus_dma.9: Correct crap suggestion to burn all of your memory
AbandonedPublic

Authored by cem on Jul 12 2018, 4:18 PM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 22 2023, 11:31 PM
Unknown Object (File)
Oct 18 2023, 2:48 AM
Unknown Object (File)
Sep 2 2023, 6:23 AM
Unknown Object (File)
Aug 2 2023, 6:07 PM
Unknown Object (File)
Jul 15 2023, 10:06 PM
Unknown Object (File)
Jul 12 2023, 3:50 PM
Unknown Object (File)
Jul 11 2023, 5:43 PM
Unknown Object (File)
Jun 12 2023, 1:54 AM
Subscribers

Details

Reviewers
jhb
imp
Group Reviewers
manpages
Summary

Passing UNRESTRICTED nsegments causes INT_MAX-sized array allocation in DMA
code. So it is utterly stupid to recommend it.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17999
Build 17751: arc lint + arc unit

Event Timeline

Small textual suggestion.

share/man/man9/bus_dma.9
433

I'd remove the "So" and just start the sentence with "Users should ..."

share/man/man9/bus_dma.9
428

I actually view it is an API bug and would kind of document it as such, something like:

"BUS_SPACE_UNRESTRICTED cannot be used with nsegments as it is instead interpreted as a very large segment count.
For devices with no restriction on the number of segments should compute a
reasonable number of segments for their DMA region."

OTOH, I would actually like it if we had a non-terrible way to support BUS_SPACE_UNRESTRICTED such as clamping 'nsegments' at some value like 64, I just don't feel confident in picking that number.