mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH rdma-next v2 1/1] RDMA/mana_ib: return PD number to the user
@ 2026-02-05 12:13 Konstantin Taranov
  2026-02-05 14:22 ` Jason Gunthorpe
  0 siblings, 1 reply; 4+ messages in thread
From: Konstantin Taranov @ 2026-02-05 12:13 UTC (permalink / raw)
  To: kotaranov, shirazsaleem, longli, jgg, leon; +Cc: linux-rdma, linux-kernel

From: Konstantin Taranov <kotaranov@microsoft.com>

Implement returning to userspace applications PDNs of created PDs.
The PDN is used by applications that build work requests outside of the
rdma-core code base. The PDN is used to build work requests that require
additional PD isolation checks. The requests can fit only 16 bit PDNs.
Allow users to request short PDNs which are 16 bits.

Signed-off-by: Konstantin Taranov <kotaranov@microsoft.com>
---
v2: updated commit message
 drivers/infiniband/hw/mana/main.c | 19 ++++++++++++++++++-
 include/net/mana/gdma.h           |  4 ++--
 include/uapi/rdma/mana-abi.h      | 14 ++++++++++++++
 3 files changed, 34 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/hw/mana/main.c b/drivers/infiniband/hw/mana/main.c
index fac159f71..7ee4493cb 100644
--- a/drivers/infiniband/hw/mana/main.c
+++ b/drivers/infiniband/hw/mana/main.c
@@ -69,9 +69,11 @@ int mana_ib_cfg_vport(struct mana_ib_dev *dev, u32 port, struct mana_ib_pd *pd,
 int mana_ib_alloc_pd(struct ib_pd *ibpd, struct ib_udata *udata)
 {
 	struct mana_ib_pd *pd = container_of(ibpd, struct mana_ib_pd, ibpd);
+	struct mana_ib_alloc_pd_resp cmd_resp = {};
 	struct ib_device *ibdev = ibpd->device;
 	struct gdma_create_pd_resp resp = {};
 	struct gdma_create_pd_req req = {};
+	struct mana_ib_alloc_pd ucmd = {};
 	enum gdma_pd_flags flags = 0;
 	struct mana_ib_dev *dev;
 	struct gdma_context *gc;
@@ -83,8 +85,15 @@ int mana_ib_alloc_pd(struct ib_pd *ibpd, struct ib_udata *udata)
 	mana_gd_init_req_hdr(&req.hdr, GDMA_CREATE_PD, sizeof(req),
 			     sizeof(resp));
 
-	if (!udata)
+	if (!udata) {
 		flags |= GDMA_PD_FLAG_ALLOW_GPA_MR;
+	} else {
+		err = ib_copy_from_udata(&ucmd, udata, min(sizeof(ucmd), udata->inlen));
+		if (err)
+			return err;
+		if (ucmd.flags & MANA_IB_PD_SHORT_PDN)
+			flags |= GDMA_PD_FLAG_SHORT_PDN;
+	}
 
 	req.flags = flags;
 	err = mana_gd_send_request(gc, sizeof(req), &req,
@@ -107,6 +116,14 @@ int mana_ib_alloc_pd(struct ib_pd *ibpd, struct ib_udata *udata)
 
 	mutex_init(&pd->vport_mutex);
 	pd->vport_use_count = 0;
+
+	if (udata) {
+		cmd_resp.pdn = resp.pd_id;
+		err = ib_copy_to_udata(udata, &cmd_resp, min(sizeof(cmd_resp), udata->outlen));
+		if (err)
+			return err;
+	}
+
 	return 0;
 }
 
diff --git a/include/net/mana/gdma.h b/include/net/mana/gdma.h
index 8649eb789..cebb9b2bd 100644
--- a/include/net/mana/gdma.h
+++ b/include/net/mana/gdma.h
@@ -824,8 +824,8 @@ struct gdma_destroy_dma_region_req {
 }; /* HW DATA */
 
 enum gdma_pd_flags {
-	GDMA_PD_FLAG_INVALID = 0,
-	GDMA_PD_FLAG_ALLOW_GPA_MR = 1,
+	GDMA_PD_FLAG_ALLOW_GPA_MR = BIT(0),
+	GDMA_PD_FLAG_SHORT_PDN = BIT(2),
 };
 
 struct gdma_create_pd_req {
diff --git a/include/uapi/rdma/mana-abi.h b/include/uapi/rdma/mana-abi.h
index a75bf32b8..88b24ae50 100644
--- a/include/uapi/rdma/mana-abi.h
+++ b/include/uapi/rdma/mana-abi.h
@@ -87,4 +87,18 @@ struct mana_ib_create_qp_rss_resp {
 	struct rss_resp_entry entries[64];
 };
 
+enum mana_ib_create_pd_flags {
+	MANA_IB_PD_SHORT_PDN = 1 << 0,
+};
+
+struct mana_ib_alloc_pd {
+	__u32 flags;
+	__u32 reserved;
+};
+
+struct mana_ib_alloc_pd_resp {
+	__u32 pdn;
+	__u32 reserved;
+};
+
 #endif
-- 
2.43.0


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH rdma-next v2 1/1] RDMA/mana_ib: return PD number to the user
  2026-02-05 12:13 [PATCH rdma-next v2 1/1] RDMA/mana_ib: return PD number to the user Konstantin Taranov
@ 2026-02-05 14:22 ` Jason Gunthorpe
  2026-02-05 16:35   ` Konstantin Taranov
  0 siblings, 1 reply; 4+ messages in thread
From: Jason Gunthorpe @ 2026-02-05 14:22 UTC (permalink / raw)
  To: Konstantin Taranov
  Cc: kotaranov, shirazsaleem, longli, leon, linux-rdma, linux-kernel

On Thu, Feb 05, 2026 at 04:13:54AM -0800, Konstantin Taranov wrote:
> From: Konstantin Taranov <kotaranov@microsoft.com>
> 
> Implement returning to userspace applications PDNs of created PDs.
> The PDN is used by applications that build work requests outside of the
> rdma-core code base. The PDN is used to build work requests that require
> additional PD isolation checks. The requests can fit only 16 bit PDNs.
> Allow users to request short PDNs which are 16 bits.

What?

PDN is protected information it should never be given to the HW
directly from userspace.

How can this possibly be secure?

Jason

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH rdma-next v2 1/1] RDMA/mana_ib: return PD number to the user
  2026-02-05 14:22 ` Jason Gunthorpe
@ 2026-02-05 16:35   ` Konstantin Taranov
  2026-02-05 17:25     ` Jason Gunthorpe
  0 siblings, 1 reply; 4+ messages in thread
From: Konstantin Taranov @ 2026-02-05 16:35 UTC (permalink / raw)
  To: Jason Gunthorpe, Konstantin Taranov
  Cc: Shiraz Saleem, Long Li, leon, linux-rdma, linux-kernel


> On Thu, Feb 05, 2026 at 04:13:54AM -0800, Konstantin Taranov wrote:
> > From: Konstantin Taranov <kotaranov@microsoft.com>
> >
> > Implement returning to userspace applications PDNs of created PDs.
> > The PDN is used by applications that build work requests outside of
> > the rdma-core code base. The PDN is used to build work requests that
> > require additional PD isolation checks. The requests can fit only 16 bit
> PDNs.
> > Allow users to request short PDNs which are 16 bits.
> 
> What?
> 
> PDN is protected information it should never be given to the HW directly
> from userspace.
> 
> How can this possibly be secure?

As far as I know, it is secure as classical PD check for WQ exists and it is just some
additional requirement to mention PDN in a request. I am not the one
who created this requirement to mention PDN in the request, but I got an ask to
expose that since some vendors do that, and there were no security concerns 
(see struct mlx5dv_pd from mlx5dv_init_obj()). It seems is not a concern when
the PDN is set from user-space into the address vector (see fill_ud_av() from hns,
mlx4_create_ah(). and mthca_alloc_av()). As far as I understand, the use-case
aimed here is similar to address vectors.

- Konstantin

> 
> Jason

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH rdma-next v2 1/1] RDMA/mana_ib: return PD number to the user
  2026-02-05 16:35   ` Konstantin Taranov
@ 2026-02-05 17:25     ` Jason Gunthorpe
  0 siblings, 0 replies; 4+ messages in thread
From: Jason Gunthorpe @ 2026-02-05 17:25 UTC (permalink / raw)
  To: Konstantin Taranov
  Cc: Konstantin Taranov, Shiraz Saleem, Long Li, leon, linux-rdma,
	linux-kernel

On Thu, Feb 05, 2026 at 04:35:44PM +0000, Konstantin Taranov wrote:
> 
> > On Thu, Feb 05, 2026 at 04:13:54AM -0800, Konstantin Taranov wrote:
> > > From: Konstantin Taranov <kotaranov@microsoft.com>
> > >
> > > Implement returning to userspace applications PDNs of created PDs.
> > > The PDN is used by applications that build work requests outside of
> > > the rdma-core code base. The PDN is used to build work requests that
> > > require additional PD isolation checks. The requests can fit only 16 bit
> > PDNs.
> > > Allow users to request short PDNs which are 16 bits.
> > 
> > What?
> > 
> > PDN is protected information it should never be given to the HW directly
> > from userspace.
> > 
> > How can this possibly be secure?
> 
> As far as I know, it is secure as classical PD check for WQ exists and it is just some
> additional requirement to mention PDN in a request. 

If all you are doing is sending a PDN in a WQ that must always match
that PDN that the WQ already has then I would agree that is OK.

But a completely nonsensical thing to do - to the point I'm skeptical
that it is actually being validated ???

> I am not the one who created this requirement to mention PDN in the
> request, but I got an ask to expose that since some vendors do that,
> and there were no security concerns (see struct mlx5dv_pd from
> mlx5dv_init_obj()).

That's different, that is going through a FW path and mlx5 has a UID
mechanism to link the permitted PDN to the user making the request.

> It seems is not a concern when
> the PDN is set from user-space into the address vector (see fill_ud_av() from hns,
> mlx4_create_ah(). and mthca_alloc_av()). As far as I understand, the use-case
> aimed here is similar to address vectors.

All these AH cases all end up with checks in SW or HW that the PDN is
valid for the context. What you are describing could be real, but is
so hard to accept that I'm going to ask you to strongly verify it and
document all this in the commit message.

Jason

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2026-02-05 17:25 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-02-05 12:13 [PATCH rdma-next v2 1/1] RDMA/mana_ib: return PD number to the user Konstantin Taranov
2026-02-05 14:22 ` Jason Gunthorpe
2026-02-05 16:35   ` Konstantin Taranov
2026-02-05 17:25     ` Jason Gunthorpe

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®