On Tue, Feb 17, 2026 at 10:32:25AM +0530, Selvin Xavier wrote: > On Mon, Feb 16, 2026 at 1:37 PM Leon Romanovsky <[email protected]> wrote: > > > > On Mon, Feb 16, 2026 at 09:29:29AM +0530, Selvin Xavier wrote: > > > On Fri, Feb 13, 2026 at 4:31 PM Leon Romanovsky <[email protected]> wrote: > > > > > > > > From: Leon Romanovsky <[email protected]> > > > > > > > > There is no need to defer the CQ resize operation, as it is intended to > > > > be completed in one pass. The current bnxt_re_resize_cq() implementation > > > > does not handle concurrent CQ resize requests, and this will be > > > > addressed > > > > in the following patches. > > > bnxt HW requires that the previous CQ memory be available with the HW > > > until > > > HW generates a cut off cqe on the CQ that is being destroyed. This is > > > the reason for > > > polling the completions in the user library after returning the > > > resize_cq call. Once the polling > > > thread sees the expected CQE, it will invoke the driver to free CQ > > > memory. > > > > This flow is problematic. It requires the kernel to trust a user‑space > > application, which is not acceptable. There is no guarantee that the > > rdma-core implementation is correct or will invoke the interface properly. > > Users can bypass rdma-core entirely and issue ioctls directly (syzkaller, > > custom rdma-core variants, etc.), leading to umem leaks, races that > > overwrite > > kernel memory, and access to fields that are now being modified. All of this > > can occur silently and without any protections. > > > > > So ib_umem_release should wait. This patch doesn't guarantee that. > > > > The issue is that it was never guaranteed in the first place. It only > > appeared > > to work under very controlled conditions. > > > > > Do you think if there is a better way to handle this requirement? > > > > You should wait for BNXT_RE_WC_TYPE_COFF in the kernel before returning > > from resize_cq. > The difficulty is that libbnxt_re in rdma-core has the queue the > consumer index used for completion lookup. The driver therefore has to > use copy_from_user to read the queue memory and then check for > BNXT_RE_WC_TYPE_COFF, along with the queue consumer index and the > relevant validity flags. I’ll explore if we have a way to handle this > and get back.
The thing is that you need to ensure that after libbnxt_re issued resize_cq command, kernel won't require anything from user-space. Can you cause to your HW to stop generate CQEs before resize_cq? Thanks
