Re: git: f08247fd888e - main - Assert that mbufs are writable if we write to them

On 12 Sep 2024, at 11:40, John Baldwin wrote:
> On 9/12/24 05:03, John Baldwin wrote:
>> I think part of the motivation for marking M_EXTPG as read-only is that you can't "write"
>> to m_data via mtod() or the like.  That said, M_EXTPG aren't really read-only.  It
>> depends on the backing store.  M_EXTPG were first merged into FreeBSD prior to KTLS to
>> support sendfile, and in that case, they should be M_RDONLY because they alias pages
>> from the file's VM object.  However, M_EXTPG mbufs allocated via functions like
>> m_uiotombuf_nomap should not be M_RDONLY.  I think this originated in the original
>> import of KTLS which doesn't push setting M_RDONLY out to the callers of mb_alloc_extpgs,
>> and a few other places that hardcode M_RDONLY with M_EXTPG (_mb_unmapped_to_ext should
>> preserve M_RDONLY from the original mbuf instead of forcing M_RDONLY).
>>
>> I can take a stab at a patch but won't have time to really test it until after Euro.
>
> Patch available below.  Compile tested but not run-tested:
>
> https://github.com/freebsd/freebsd-src/compare/main...bsdjhb:freebsd:m_extpg_rdonly
>
I’m still seeing a panic (with the extra assertions from https://reviews.freebsd.org/D46572 in opencrypto) in ktls_test:ktls_receive_aes128_cbc_1_1_sha1_long.

It’s unhappy because there’s an mbuf with m_flags = 0x2001 (so M_EXT | M_PROTO1) that has an ext_cnt of 2.

It’s not urgent, I’m mostly interested in these assertions to catch bugs like 280036 sooner. I’ll also be at euro, I can give you access to a box that trivially produces this panic then.

Best regards,
Kristof