From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta0.migadu.com (out-181.mta0.migadu.com [91.218.175.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 313FF2773E5 for ; Fri, 13 Feb 2026 23:22:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771024956; cv=none; b=Q8y9F7fVE6Kj55XFJEOpQ3IwUwQDmxtd7fjwqzMV2dKynBEPEHriz59n8qS5LzFhBNsXe5HPHT/9Oui4VDGk3Uk8iK5YpOL+Ye+m969cJROI5XADfreyHpetWL1CRcznJCYYlN2hN6Pc9EgvrszK4T7v2UZkLmiMe6fL/WVH9ig= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771024956; c=relaxed/simple; bh=UQJ6pYXPnPIXRM8pirMc4ug+s9oYY+R3WK/G2UaY5uc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=GHb8aYa3zHHQ2F2xZ+9th5Z5gIJfe9dvZnJ7/y/fXCHhH/xfjUZh1BOBrbp26nYCrMWqfrLNz9poUtTLl3wR80D9neO6haa/61ABNFjOEMTaaIINo3C+fL5nBAwZIdP7r+iT3X2J0PSxHGoq+yDNCpPZ/fJFjXRxeyX2qlaClBA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=lv7QZffq; arc=none smtp.client-ip=91.218.175.181 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="lv7QZffq" Message-ID: <459a01fe-8f23-4114-a127-98ec95c53464@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1771024941; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6bje+VS+HFc4IP5MZonfLHHhjiuUCgTadQIT/tXFDSo=; b=lv7QZffqRt9lWP9tzW9wJx7l6G5Of/DfSmbd732cmGm9+xdcBoXlqsBiuTxpzY/0KARVR0 P1yZBpssN2K8k2PgFLnv2i6d3DtkxLzCihxfyE9mYZVVLwJw1wynGqbbcyCX6qKpupPv3A o9Z2EldUq//1yE9yf68/bK0LQJFOgNc= Date: Fri, 13 Feb 2026 15:22:13 -0800 Precedence: bulk X-Mailing-List: linux-rdma@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH rdma-next 29/50] RDMA/rxe: Split user and kernel CQ creation paths To: Leon Romanovsky , Jason Gunthorpe , Selvin Xavier , Kalesh AP , Potnuri Bharat Teja , Michael Margolin , Gal Pressman , Yossi Leybovich , Cheng Xu , Kai Shen , Chengchang Tang , Junxian Huang , Abhijit Gangurde , Allen Hubbe , Krzysztof Czurylo , Tatyana Nikolova , Long Li , Konstantin Taranov , Yishai Hadas , Michal Kalderon , Bryan Tan , Vishnu Dasa , Broadcom internal kernel review list , Christian Benvenuti , Nelson Escobar , Dennis Dalessandro , Bernard Metzler , Zhu Yanjun Cc: linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, linux-hyperv@vger.kernel.org References: <20260213-refactor-umem-v1-0-f3be85847922@nvidia.com> <20260213-refactor-umem-v1-29-f3be85847922@nvidia.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "yanjun.zhu" In-Reply-To: <20260213-refactor-umem-v1-29-f3be85847922@nvidia.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 2/13/26 2:58 AM, Leon Romanovsky wrote: > From: Leon Romanovsky > > Separate the CQ creation logic into distinct kernel and user flows. > > Signed-off-by: Leon Romanovsky > --- > drivers/infiniband/sw/rxe/rxe_verbs.c | 81 ++++++++++++++++++++--------------- > 1 file changed, 47 insertions(+), 34 deletions(-) > > diff --git a/drivers/infiniband/sw/rxe/rxe_verbs.c b/drivers/infiniband/sw/rxe/rxe_verbs.c > index 38d8c408320f..1e651bdd8622 100644 > --- a/drivers/infiniband/sw/rxe/rxe_verbs.c > +++ b/drivers/infiniband/sw/rxe/rxe_verbs.c > @@ -1072,58 +1072,70 @@ static int rxe_post_recv(struct ib_qp *ibqp, const struct ib_recv_wr *wr, > } > > /* cq */ > -static int rxe_create_cq(struct ib_cq *ibcq, const struct ib_cq_init_attr *attr, > - struct uverbs_attr_bundle *attrs) > +static int rxe_create_user_cq(struct ib_cq *ibcq, const struct ib_cq_init_attr *attr, > + struct uverbs_attr_bundle *attrs) > { > struct ib_udata *udata = &attrs->driver_udata; > struct ib_device *dev = ibcq->device; > struct rxe_dev *rxe = to_rdev(dev); > struct rxe_cq *cq = to_rcq(ibcq); > - struct rxe_create_cq_resp __user *uresp = NULL; > - int err, cleanup_err; > + struct rxe_create_cq_resp __user *uresp; > + int err; > > - if (udata) { > - if (udata->outlen < sizeof(*uresp)) { > - err = -EINVAL; > - rxe_dbg_dev(rxe, "malformed udata, err = %d\n", err); > - goto err_out; > - } > - uresp = udata->outbuf; > - } > + if (udata->outlen < sizeof(*uresp)) > + return -EINVAL; > > - if (attr->flags) { > - err = -EOPNOTSUPP; > - rxe_dbg_dev(rxe, "bad attr->flags, err = %d\n", err); > - goto err_out; > - } > + uresp = udata->outbuf; > > - err = rxe_cq_chk_attr(rxe, NULL, attr->cqe, attr->comp_vector); > - if (err) { > - rxe_dbg_dev(rxe, "bad init attributes, err = %d\n", err); > - goto err_out; > - } > + if (attr->flags || ibcq->umem) > + return -EOPNOTSUPP; > + > + if (attr->cqe > rxe->attr.max_cqe) > + return -EINVAL; > > err = rxe_add_to_pool(&rxe->cq_pool, cq); > - if (err) { > - rxe_dbg_dev(rxe, "unable to create cq, err = %d\n", err); > - goto err_out; > - } > + if (err) > + return err; > > err = rxe_cq_from_init(rxe, cq, attr->cqe, attr->comp_vector, udata, > uresp); Neither rxe_create_user_cq() nor rxe_create_cq() explicitly validates attr->comp_vector. Is this guaranteed to be validated by the core before reaching the driver, or should rxe still enforce device-specific limits? > - if (err) { > - rxe_dbg_cq(cq, "create cq failed, err = %d\n", err); > + if (err) > goto err_cleanup; The err_cleanup label is only used for this specific error path. It may improve readability to inline the cleanup logic at this site and remove the label altogether. > - } > > return 0; > > err_cleanup: > - cleanup_err = rxe_cleanup(cq); > - if (cleanup_err) > - rxe_err_cq(cq, "cleanup failed, err = %d\n", cleanup_err); > -err_out: > - rxe_err_dev(rxe, "returned err = %d\n", err); > + rxe_cleanup(cq); > + return err; > +} > + > +static int rxe_create_cq(struct ib_cq *ibcq, const struct ib_cq_init_attr *attr, > + struct uverbs_attr_bundle *attrs) > +{ > + struct ib_device *dev = ibcq->device; > + struct rxe_dev *rxe = to_rdev(dev); > + struct rxe_cq *cq = to_rcq(ibcq); > + int err; > + > + if (attr->flags) > + return -EOPNOTSUPP; > + > + if (attr->cqe > rxe->attr.max_cqe) > + return -EINVAL; > + > + err = rxe_add_to_pool(&rxe->cq_pool, cq); > + if (err) > + return err; > + > + err = rxe_cq_from_init(rxe, cq, attr->cqe, attr->comp_vector, NULL, > + NULL); > + if (err) > + goto err_cleanup; ditto Thanks a lot. Zhu Yanjun > + > + return 0; > + > +err_cleanup: > + rxe_cleanup(cq); > return err; > } > > @@ -1478,6 +1490,7 @@ static const struct ib_device_ops rxe_dev_ops = { > .attach_mcast = rxe_attach_mcast, > .create_ah = rxe_create_ah, > .create_cq = rxe_create_cq, > + .create_user_cq = rxe_create_user_cq, > .create_qp = rxe_create_qp, > .create_srq = rxe_create_srq, > .create_user_ah = rxe_create_ah, >