[rds-devel] [External] : Re: [PATCH net 1/1] net/rds: handle zerocopy send cleanup before the message is queued

[Allison Henderson]

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 <tonanli66 at gmail.com>
> > > 
> > > A zerocopy send can fail after user pages have been pinned but before
> > > the message is attached to the sending socket.
> > > 
> > > 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 pages.
> > > However, zerocopy ownership is really determined by the presence of
> > > op_mmp_znotifier, regardless of whether the message has reached the
> > > socket queue.
> > > 
> > > Capture op_mmp_znotifier up front in rds_message_purge() and use it as
> > > 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.
> > > 
> > > This keeps early send failure cleanup consistent with the zerocopy
> > > lifetime rules without changing the normal queued completion path.
> > > 
> > > Fixes: 0cebaccef3ac ("rds: zerocopy Tx support.")
> > > Cc: stable at kernel.org
> > > Reported-by: Yuan Tan <yuantan098 at gmail.com>
> > > Reported-by: Yifan Wu <yifanwucs at gmail.com>
> > > Reported-by: Juefei Pu <tomapufckgml at gmail.com>
> > > Reported-by: Xin Liu <bird at lzu.edu.cn>
> > > Co-developed-by: Xiao Liu <lx24 at stu.ynu.edu.cn>
> > > Signed-off-by: Xiao Liu <lx24 at stu.ynu.edu.cn>
> > > Signed-off-by: Nan Li <tonanli66 at gmail.com>
> > > Signed-off-by: Ren Wei <n05ec at lzu.edu.cn>
> > 
> > This fix looks fine to me.  Thanks Ren Wei!
> > Reviewed-by: Allison Henderson <achender at kernel.org>
> 
> Note that sashiko spotted more pre-existing problems in this area,
> please have a look:
> 
> https://sashiko.dev/#/patchset/d2ea98a6313d5467bac00f7c9fef8c7acddb9258.1777550074.git.tonanli66%40gmail.com
> 
> /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.  

Thank you!
Allison

>