Date: Thu, 12 Sep 2024 13:41:09 +0200 From: Kristof Provost <kp@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: Drew Gallatin <gallatin@fastmail.com>, Mark Johnston <markj@freebsd.org>, src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Subject: Re: git: f08247fd888e - main - Assert that mbufs are writable if we write to them Message-ID: <61045FAC-D1C5-42AE-BE1B-757AC2222554@FreeBSD.org> In-Reply-To: <1f61b6de-0fe2-4343-b4ad-f0866785a4bc@FreeBSD.org> References: <202409111118.48BBIQ2h065089@gitrepo.freebsd.org> <ZuGtGHm-u4QiJGUz@nuc> <ED0A74EE-FB1B-44E6-8DEE-E34D22953825@FreeBSD.org> <a0eeed9d-d2ff-49c2-af3f-328e0c0c28b1@app.fastmail.com> <2b1955e2-fbf1-41cb-b256-a9a257b16a83@FreeBSD.org> <1f61b6de-0fe2-4343-b4ad-f0866785a4bc@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
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, Kristofhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?61045FAC-D1C5-42AE-BE1B-757AC2222554>