Page MenuHomeFreeBSD

mbuf: Add M_WRITABLE_EXTPG
AcceptedPublic

Authored by jhb on Sep 25 2024, 3:13 PM.
Tags
None
Referenced Files
F102074828: D46787.id.diff
Thu, Nov 7, 7:38 AM
Unknown Object (File)
Sun, Oct 27, 2:15 AM
Unknown Object (File)
Thu, Oct 17, 1:01 PM
Unknown Object (File)
Oct 8 2024, 7:08 PM
Unknown Object (File)
Sep 30 2024, 4:21 PM
Unknown Object (File)
Sep 30 2024, 3:18 PM
Unknown Object (File)
Sep 28 2024, 9:26 PM
Unknown Object (File)
Sep 27 2024, 12:56 PM
Subscribers

Details

Reviewers
gallatin
kp
Summary

This can be used instead of M_WRITABLE where the calling code is
prepared to handle writing to M_EXTPG mbufs.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 59597
Build 56484: arc lint + arc unit

Event Timeline

jhb requested review of this revision.Sep 25 2024, 3:13 PM

I'm confused.. if we are marking non-writable M_EXTPG mufs as M_RDONLY, why can't we simply remove the M_EXTPG check from M_WRITABLE? Why do we need a new macro?

I'm confused.. if we are marking non-writable M_EXTPG mufs as M_RDONLY, why can't we simply remove the M_EXTPG check from M_WRITABLE? Why do we need a new macro?

Because there are many places that call M_WRITABLE in the tree and if it succeeds expect to directly use mtod() to get a writable pointer to the data payload (possibly after using m_pullup which panics if called on an M_EXTPG mbuf). m_copyback() is explicitly aware of M_EXTPG mbufs and handles them correctly, so the new macro works fine the assertion there.

This revision is now accepted and ready to land.Sep 26 2024, 2:37 PM