From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DF36175A6E; Tue, 5 May 2026 18:04:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778004261; cv=none; b=UUnJ/5JM6YTDeqGgn83UTGnHC4Mt26YvVgITj8idibqoNgHNz/d1ZVDeAdtCMkw+SvUG6Iqy6QnAuRFY/MC+ENmohLvcnS8zaf5ec2EvHnppPi4QOba/+QmFB3f93RFckCi6Vqv6q9RKP2FLXlSe889uDe+XU7HYOdQbyZDYJxQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778004261; c=relaxed/simple; bh=3mTZeVHSefVi+AiG2PyL7wAb7XbmEcO8m7IKhqMY1r8=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=pr9Z2Oy+XZnr8NRac/vUMRV0VuYTR6lhutWQ2cRA56MkeL4xMC28p6q3FBBgeFVtX2e/LD71boaxI2cBgitT6VJ59CJtRY23AqGI08xs/miPijsTBs6s3ThLinzjzvEB41vyjThY9ajIci/74/1srrMS09tNMPr9zF2WbZA6NZI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Zr5Jg4zo; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Zr5Jg4zo" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3136DC2BCC7; Tue, 5 May 2026 18:04:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1778004261; bh=3mTZeVHSefVi+AiG2PyL7wAb7XbmEcO8m7IKhqMY1r8=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Zr5Jg4zooK8XnA3PV9HZhiQViUqWpFwcI4KCCnnJhm2YVonatAeLEBpS9c4DLe1gq PNx6jCZCk7DinGT82V3EFyR0kf7bj+tmtzLOqX3iSMFreW96JeU4FqI/biDgY0a5IC laMkoBUFgPXEQ3Wb8H1/8aGGrS1Ki8Y2FZUcpOXvvsRKFYsI6dvieS55vDU3XlcZd7 BBzZwID6kevpt0BWkbt99FJUsCqnyW8fgqreRjWokAPuZjtK57ONMtBlVCTSqHhpAC 59PsuFZVEvjC718Tp3RsfvZuU9TjFnVIygDrzftgT9JGexV+wNKhAcZ0t11kW+iJEd ykBywTuyOf+Cw== Message-ID: <51fb70c0db4d2d065aac18729ee1d4862e9637fc.camel@kernel.org> Subject: Re: [PATCH net 1/1] net/rds: handle zerocopy send cleanup before the message is queued From: Allison Henderson To: Paolo Abeni , linux-rdma@vger.kernel.org, rds-devel@oss.oracle.com Cc: davem@davemloft.net, edumazet@google.com, kuba@kernel.org, horms@kernel.org, santosh.shilimkar@oracle.com, sowmini.varadhan@oracle.com, willemb@google.com, yuantan098@gmail.com, yifanwucs@gmail.com, tomapufckgml@gmail.com, bird@lzu.edu.cn, lx24@stu.ynu.edu.cn, tonanli66@gmail.com, Ren Wei , netdev@vger.kernel.org Date: Tue, 05 May 2026 11:04:19 -0700 In-Reply-To: <673288e7-37ac-4533-a4d3-2fa87dc282f1@redhat.com> References: <87f79bc7483aa1a7b3a44718b62a5cd5bd016f8c.camel@kernel.org> <673288e7-37ac-4533-a4d3-2fa87dc282f1@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.52.3-0ubuntu1.1 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Tue, 2026-05-05 at 15:32 +0200, Paolo Abeni wrote: > On 5/1/26 9:40 PM, Allison Henderson wrote: > > On Fri, 2026-05-01 at 09:08 +0800, Ren Wei wrote: > > > From: Nan Li > > >=20 > > > A zerocopy send can fail after user pages have been pinned but before > > > the message is attached to the sending socket. > > >=20 > > > The purge path currently infers zerocopy state from rm->m_rs, so an > > > unqueued message can be cleaned up as if it owned normal payload page= s. > > > However, zerocopy ownership is really determined by the presence of > > > op_mmp_znotifier, regardless of whether the message has reached the > > > socket queue. > > >=20 > > > Capture op_mmp_znotifier up front in rds_message_purge() and use it a= s > > > the cleanup discriminator. If the message is already associated with = a > > > socket, keep the existing completion path. Otherwise, drop the pinned > > > page accounting directly and release the notifier before putting the > > > payload pages. > > >=20 > > > This keeps early send failure cleanup consistent with the zerocopy > > > lifetime rules without changing the normal queued completion path. > > >=20 > > > Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.") > > > Cc: stable@kernel.org > > > Reported-by: Yuan Tan > > > Reported-by: Yifan Wu > > > Reported-by: Juefei Pu > > > Reported-by: Xin Liu > > > Co-developed-by: Xiao Liu > > > Signed-off-by: Xiao Liu > > > Signed-off-by: Nan Li > > > Signed-off-by: Ren Wei > >=20 > > This fix looks fine to me. Thanks Ren Wei! > > Reviewed-by: Allison Henderson >=20 > Note that sashiko spotted more pre-existing problems in this area, > please have a look: >=20 > https://sashiko.dev/#/patchset/d2ea98a6313d5467bac00f7c9fef8c7acddb9258.1= 777550074.git.tonanli66%40gmail.com >=20 > /P Thanks for pointing this out. It looks like a valid catch, I will see if I= can get a fix out today or tomorrow. =20 Thank you! Allison >=20