All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cheng Xu <chengyou@linux.alibaba.com>
To: Jacob Moroni <jmoroni@google.com>
Cc: Myeonghun Pak <mhun512@gmail.com>,
	Kai Shen <kaishen@linux.alibaba.com>,
	Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
	linux-rdma@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ijae Kim <ae878000@gmail.com>
Subject: Re: [PATCH] RDMA/erdma: Fix CEQ tasklet use-after-free on removal
Date: Wed, 22 Jul 2026 10:18:54 +0800	[thread overview]
Message-ID: <c61972bb-bdb9-c1f8-be16-5e98fd28fa5c@linux.alibaba.com> (raw)
In-Reply-To: <CAHYDg1QDaWPxD7pb-A1ZmqxaX6YACWTsinzEG4_EZDKbAX38kQ@mail.gmail.com>



On 7/21/26 9:24 PM, Jacob Moroni wrote:
> Hi,
> 
> I was looking at this driver and was curious if you also need
> some type of synchronization after the xa_erase in erdma_destroy_cq.
> 
> Otherwise, it seems like the CEQ tasklet could do the xa_load right
> before erdma_destroy_cq does the xa_erase, then destroy_cq proceeds
> to return and kfree the CQ while the tasket is in the middle of comp_handler.
> 
> Most drivers either do a synchronize_irq (which I don't think would work for
> this since it's a tasklet) or some form of locked refcounting when
> accessing the xarray.
> 

Hi Jacob,

Thanks for pointing this out.

For kernel CQs this should be unlikely in practice, since the associated
QPs are destroyed first and the kernel QP destroy path drains the WQEs
before the CQ is destroyed.

However, the user CQ path does not have the same guarantee, so the race
you described still needs to be handled. We need to add synchronization
in the CQ destroy path, and I will take a closer look at this.

Thanks,
Cheng Xu

> Thanks,
> Jake

  reply	other threads:[~2026-07-22  2:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-21  8:25 [PATCH] RDMA/erdma: Fix CEQ tasklet use-after-free on removal Myeonghun Pak
2026-07-21  9:01 ` Cheng Xu
2026-07-21 13:24   ` Jacob Moroni
2026-07-22  2:18     ` Cheng Xu [this message]
2026-07-22  8:36 ` Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c61972bb-bdb9-c1f8-be16-5e98fd28fa5c@linux.alibaba.com \
    --to=chengyou@linux.alibaba.com \
    --cc=ae878000@gmail.com \
    --cc=jgg@ziepe.ca \
    --cc=jmoroni@google.com \
    --cc=kaishen@linux.alibaba.com \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=mhun512@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.