Use M_WRITABLE_EXTPG since m_copyback supports writing to M_EXTPG
mbufs.
This reverts commit 299175f2e52e1a5cf495316d53a245bea00dfca7.
Differential D46788
Reapply "Assert that mbufs are writable if we write to them" jhb on Sep 25 2024, 3:13 PM. Authored by Tags None Referenced Files
Details Use M_WRITABLE_EXTPG since m_copyback supports writing to M_EXTPG This reverts commit 299175f2e52e1a5cf495316d53a245bea00dfca7.
Diff Detail
Event TimelineComment Actions @kp are you ok with this change? I think m_unshare can still be resolved orthogonally from the rest of this series. Comment Actions I'm okay with this, yes. The if_ovpn changes are on my todo list, but I expect it'll be a few weeks before I have something reviewable. Comment Actions Hmm, I still get panics from ktls_test. The problem now is not with M_EXTPG mbufs, but the decryption code might (or might not) have a bug. The panic is due to writing to an M_EXT mbuf that is not marked read-only but has a reference count of 2. The reason it has a reference count of 2 is that for TLS decryption we have to "split" mbufs if a TLS record ends in the middle of a boundary, and in that case you end up with shared references to the backing cluster. I'm not quite sure how to untangle this assumption that a reference count > 1 implies read-only data. There probably are some cases where that is true, but in the case of KTLS, the two mbufs are referencing different parts of the backing cluster, not truly sharing the data, so it is a false positive. I'm not sure how you could fix the assertion to work properly for these cases. |