From nobody Wed Sep 11 20:56:17 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4X3tCs55D4z5VxZX; Wed, 11 Sep 2024 20:56:41 +0000 (UTC) (envelope-from gallatin@fastmail.com) Received: from fhigh5-smtp.messagingengine.com (fhigh5-smtp.messagingengine.com [103.168.172.156]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4X3tCs3HHcz4hMH; Wed, 11 Sep 2024 20:56:41 +0000 (UTC) (envelope-from gallatin@fastmail.com) Authentication-Results: mx1.freebsd.org; none Received: from phl-compute-10.internal (phl-compute-10.phl.internal [10.202.2.50]) by mailfhigh.phl.internal (Postfix) with ESMTP id 600EA11401E5; Wed, 11 Sep 2024 16:56:40 -0400 (EDT) Received: from phl-imap-13 ([10.202.2.103]) by phl-compute-10.internal (MEProxy); Wed, 11 Sep 2024 16:56:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm1; t=1726088200; x=1726174600; bh=VfWGOW1snH njqdAGWuQlpKnVFQ40u69Y+EHB5G51Jdw=; b=ns66kmYkyuy8CoHyYb3a3DsvOp hEpu/uoBexVszsz9e1+i+cVlovaynNz1C1HAc9TRKtIoH/GapQhcMufoblZpYTtC YqPaStBiLUjGmm3unxTzB+18s+Cn0mdfTwIcl8pyAKUqY94L1r2r3GMGnyKDS4Yh gbUxf+IsQnsLc9XnKhAQZgOERv1jzL3FxXRjPDtxIM7qegagqwNV5jsF9ltLQoMV Zx+3PfunJjpSSL/FdcViNnFwIEtXsUGqHN1KGepkW+N674ElGIhKKyj0sUN2sFt3 dQZgcJGOZ0JpIZO1g59CTKT5hlgCLNWy+syQuHhAwKADqhUixrYg8Wq05u5g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; t=1726088200; x=1726174600; bh=VfWGOW1snHnjqdAGWuQlpKnVFQ40 u69Y+EHB5G51Jdw=; b=Ev8mNYbBVUdENV2FOBqV/bpRjQ963pl70APSOHym5+sQ r8QPHNM69LgzfRKWl+ga8JaibdQ1QX2zNgtyfVhF8XXuz4ARSDKdNLVIx7GGp/y/ 5ebFkAwq/xyG9vhhdjDXG0zmQsBg1Ggqn926XSG1bwFiaolP96ttuXoWDe8cbr4R JaAMEP/5k2QvG6KWFrzYxGXavJZIcILwUFJ0vmsAUk7ApGTCf7fYS0akbloCzGPi sF+ZrX2YmXAK49szsxykVGCDCDF0qt3ESH8M39No17lGVk4qWKhGNvvNckZn4nxu BsK4lGPitxCYMaXw+k9eLZkI43s8XZMvy0CnOeenJg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeftddrudejuddgudehgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpggftfghnshhusghstghrihgsvgdp uffrtefokffrpgfnqfghnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivg hnthhsucdlqddutddtmdenucfjughrpefoggffhffvvefkjghfufgtsegrtderreertdej necuhfhrohhmpedfffhrvgifucfirghllhgrthhinhdfuceoghgrlhhlrghtihhnsehfrg hsthhmrghilhdrtghomheqnecuggftrfgrthhtvghrnhepgfdtkedtgedugeetkeduvdev ueeuhfeihedtieffteeftdeilefhueefudefgfelnecuffhomhgrihhnpehfrhgvvggssh gurdhorhhgpdhshiiikhgrlhhlvghrrdgrphhpshhpohhtrdgtohhmnecuvehluhhsthgv rhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepghgrlhhlrghtihhnsehfrg hsthhmrghilhdrtghomhdpnhgspghrtghpthhtohepiedpmhhouggvpehsmhhtphhouhht pdhrtghpthhtohepuggvvhdqtghomhhmihhtshdqshhrtgdqrghllhesfhhrvggvsghsug drohhrghdprhgtphhtthhopeguvghvqdgtohhmmhhithhsqdhsrhgtqdhmrghinhesfhhr vggvsghsugdrohhrghdprhgtphhtthhopehjhhgssehfrhgvvggsshgurdhorhhgpdhrtg hpthhtohepkhhpsehfrhgvvggsshgurdhorhhgpdhrtghpthhtohepmhgrrhhkjhesfhhr vggvsghsugdrohhrghdprhgtphhtthhopehsrhgtqdgtohhmmhhithhtvghrshesfhhrvg gvsghsugdrohhrgh X-ME-Proxy: Feedback-ID: i2f014658:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 202101F000B4; Wed, 11 Sep 2024 16:56:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: dev-commits-src-all@freebsd.org Sender: owner-dev-commits-src-all@FreeBSD.org MIME-Version: 1.0 Date: Wed, 11 Sep 2024 16:56:17 -0400 From: "Drew Gallatin" To: "Kristof Provost" , "Mark Johnston" , "John Baldwin" Cc: src-committers@freebsd.org, dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Message-Id: In-Reply-To: References: <202409111118.48BBIQ2h065089@gitrepo.freebsd.org> Subject: Re: git: f08247fd888e - main - Assert that mbufs are writable if we write to them Content-Type: multipart/alternative; boundary=c716c615bd2f40de8ba52bcfbdeae1f0 X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:209242, ipnet:103.168.172.0/24, country:US] X-Rspamd-Queue-Id: 4X3tCs3HHcz4hMH --c716c615bd2f40de8ba52bcfbdeae1f0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable M_EXTPGS mbufs are marked read-only because they refer to external data.= The original crypto code, (before kTLS was converted to OCF), used to= just build an iovec using PHYS_TO_DMAP() on the page array. I think th= is case was missed during the conversion to OCF. I'm not sure what the best thing to do is, as they should be read only, = except this one specific case.... I'd be tempted to just nerf the KASSER= T for EXTPGS. On Wed, Sep 11, 2024, at 11:02 AM, Kristof Provost wrote: > On 11 Sep 2024, at 16:45, Mark Johnston wrote: > > On Wed, Sep 11, 2024 at 11:18:26AM +0000, Kristof Provost wrote: > >> The branch main has been updated by kp: > >> > >> URL: https://cgit.FreeBSD.org/src/commit/?id=3Df08247fd888e6f7db0ec= f2aaa39377144ac40b4c > >> > >> commit f08247fd888e6f7db0ecf2aaa39377144ac40b4c > >> Author: Kristof Provost > >> AuthorDate: 2024-09-10 20:15:31 +0000 > >> Commit: Kristof Provost > >> CommitDate: 2024-09-11 11:17:48 +0000 > >> > >> Assert that mbufs are writable if we write to them > >> > >> m_copyback() modifies the mbuf, so it must be a writable mbuf. > > > > This change still triggers a panic for me when running KTLS tests. I > > note that EXTPG mbufs always have M_RDONLY set, but I'm not quite su= re > > why. I suspect such mbufs need special handling with respect to the= new > > assertion. > > > > syzbot also triggered this panic: > > https://syzkaller.appspot.com/bug?extid=3D58c918369f9dc323409d > > > Yeah, I saw that one before I went out for a bike ride. >=20 > Clearly something is wrong. Either ktls is using read-only buffers or = the M_WRITABLE() macro isn=E2=80=99t quite smart enough to spot this spe= cific case. >=20 > I=E2=80=99m not familiar enough with ktls to easily tell which. >=20 > I=E2=80=99ll back this assertion change out for now, so we=E2=80=99re = not panicing test machines while we figure this out. >=20 > Best regards, > Kristof >=20 --c716c615bd2f40de8ba52bcfbdeae1f0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
M_EXTPGS mbufs = are marked read-only because they refer to external data.   Th= e original crypto code, (before kTLS was converted to OCF), used to just= build an iovec using PHYS_TO_DMAP() on the page array.  I think th= is case was missed during the conversion to OCF.

I'm not sure what the best thing to do is, as they should be read = only, except this one specific case.... I'd be tempted to just nerf the = KASSERT for EXTPGS.

On Wed, Sep 11, 2024, a= t 11:02 AM, Kristof Provost wrote:
On 11 Sep 2024, at 16:45, Mark Johnston wrote:
> On Wed, Sep 11, 2024 at 11:18:26AM +0000, Kristof Prov= ost wrote:
>> The branch main has been updated by kp= :
>>
>>
>> co= mmit f08247fd888e6f7db0ecf2aaa39377144ac40b4c
>> Aut= hor:     Kristof Provost <kp@FreeBSD.org>
>> AuthorDate: 202= 4-09-10 20:15:31 +0000
>> Commit:   &= nbsp; Kristof Provost <kp@FreeBSD.o= rg>
>> CommitDate: 2024-09-11 11:17:48 +0000<= br>
>>
>>     As= sert that mbufs are writable if we write to them
>><= br>
>>     m_copyback() modifies the= mbuf, so it must be a writable mbuf.
>
&= gt; This change still triggers a panic for me when running KTLS tests.&n= bsp; I
> note that EXTPG mbufs always have M_RDONLY set= , but I'm not quite sure
> why.  I suspect such mb= ufs need special handling with respect to the new
> ass= ertion.
>
> syzbot also triggered this= panic:
>
Yeah, I s= aw that one before I went out for a bike ride.

<= div>Clearly something is wrong. Either ktls is using read-only buffers o= r the M_WRITABLE() macro isn=E2=80=99t quite smart enough to spot this s= pecific case.

I=E2=80=99m not familiar enou= gh with ktls to easily tell which.

I=E2=80=99= ll back this assertion change out for now, so we=E2=80=99re not panicing= test machines while we figure this out.

Be= st regards,
Kristof

<= div>
--c716c615bd2f40de8ba52bcfbdeae1f0--