On Tue, Feb 17, 2026 at 1:27 PM Leon Romanovsky <[email protected]> wrote: > > 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? we dont have this control (especially on the Receive CQ side). For the Tx side, maybe we can prevent posting to the Tx queue. > > Thanks
smime.p7s
Description: S/MIME Cryptographic Signature
