On Tue, Feb 17, 2026 at 4:22 PM Selvin Xavier <[email protected]> wrote: > > 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. After discussing with other teams internally, we feel that the sequence given by you should work fine. As per the sequence, BNXT_RE_WC_TYPE_COFF should be available when resize request is returned from FW. We will test your series and confirm above behavior. > > > > Thanks
smime.p7s
Description: S/MIME Cryptographic Signature
