From: Leon Romanovsky <leonro@nvidia.com>
Use the new dma_buf_attach_revocable() helper to restrict attachments to
importers that support mapping invalidation.
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
---
drivers/vfio/pci/vfio_pci_dmabuf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
index 5fceefc40e27..85056a5a3faf 100644
--- a/drivers/vfio/pci/vfio_pci_dmabuf.c
+++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
@@ -31,6 +31,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
if (priv->revoked)
return -ENODEV;
+ if (!dma_buf_attach_revocable(attachment))
+ return -EOPNOTSUPP;
+
return 0;
}
--
2.52.0On Wed, Jan 21, 2026 at 02:59:16PM +0200, Leon Romanovsky wrote: > From: Leon Romanovsky <leonro@nvidia.com> > > Use the new dma_buf_attach_revocable() helper to restrict attachments to > importers that support mapping invalidation. > > Signed-off-by: Leon Romanovsky <leonro@nvidia.com> > --- > drivers/vfio/pci/vfio_pci_dmabuf.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > index 5fceefc40e27..85056a5a3faf 100644 > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > @@ -31,6 +31,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, > if (priv->revoked) > return -ENODEV; > > + if (!dma_buf_attach_revocable(attachment)) > + return -EOPNOTSUPP; > + > return 0; > } We need to push an urgent -rc fix to implement a pin function here that always fails. That was missed and it means things like rdma can import vfio when the intention was to block that. It would be bad for that uAPI mistake to reach a released kernel. It's tricky that NULL pin ops means "I support pin" :| Jason
On Wed, Jan 21, 2026 at 09:47:12AM -0400, Jason Gunthorpe wrote: > On Wed, Jan 21, 2026 at 02:59:16PM +0200, Leon Romanovsky wrote: > > From: Leon Romanovsky <leonro@nvidia.com> > > > > Use the new dma_buf_attach_revocable() helper to restrict attachments to > > importers that support mapping invalidation. > > > > Signed-off-by: Leon Romanovsky <leonro@nvidia.com> > > --- > > drivers/vfio/pci/vfio_pci_dmabuf.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > > index 5fceefc40e27..85056a5a3faf 100644 > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > > @@ -31,6 +31,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, > > if (priv->revoked) > > return -ENODEV; > > > > + if (!dma_buf_attach_revocable(attachment)) > > + return -EOPNOTSUPP; > > + > > return 0; > > } > > We need to push an urgent -rc fix to implement a pin function here > that always fails. That was missed and it means things like rdma can > import vfio when the intention was to block that. It would be bad for > that uAPI mistake to reach a released kernel. I don't see any urgency here. In the current kernel, the RDMA importer prints a warning to indicate it was attached to the wrong exporter. VFIO also invokes dma_buf_move_notify(). With this series, we finally remove that warning. Let's focus on getting this series merged. Thanks > > It's tricky that NULL pin ops means "I support pin" :| > > Jason
On Wed, Jan 21, 2026 at 04:47:01PM +0200, Leon Romanovsky wrote: > > We need to push an urgent -rc fix to implement a pin function here > > that always fails. That was missed and it means things like rdma can > > import vfio when the intention was to block that. It would be bad for > > that uAPI mistake to reach a released kernel. > > I don't see any urgency here. In the current kernel, the RDMA importer > prints a warning to indicate it was attached to the wrong exporter. > VFIO also invokes dma_buf_move_notify(). The design of vfio was always that it must not work with RDMA because we cannot tolerate the errors that happen due to ignoring the move_notify. The entire purpose of this series could be stated as continuing to block RDMA while opening up other pining users. So it must be addressed urgently before someone builds an application relying on this connection. Jason
On Wed, Jan 21, 2026 at 11:41:37AM -0400, Jason Gunthorpe wrote: > On Wed, Jan 21, 2026 at 04:47:01PM +0200, Leon Romanovsky wrote: > > > We need to push an urgent -rc fix to implement a pin function here > > > that always fails. That was missed and it means things like rdma can > > > import vfio when the intention was to block that. It would be bad for > > > that uAPI mistake to reach a released kernel. > > > > I don't see any urgency here. In the current kernel, the RDMA importer > > prints a warning to indicate it was attached to the wrong exporter. > > VFIO also invokes dma_buf_move_notify(). > > The design of vfio was always that it must not work with RDMA because > we cannot tolerate the errors that happen due to ignoring the > move_notify. > > The entire purpose of this series could be stated as continuing to > block RDMA while opening up other pining users. > > So it must be addressed urgently before someone builds an application > relying on this connection. Done, https://lore.kernel.org/all/20260121-vfio-add-pin-v1-1-4e04916b17f1@nvidia.com/T/#u Thanks > > Jason
On Wed, Jan 21, 2026 at 09:47:12AM -0400, Jason Gunthorpe wrote:
> On Wed, Jan 21, 2026 at 02:59:16PM +0200, Leon Romanovsky wrote:
> > From: Leon Romanovsky <leonro@nvidia.com>
> >
> > Use the new dma_buf_attach_revocable() helper to restrict attachments to
> > importers that support mapping invalidation.
> >
> > Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> > ---
> > drivers/vfio/pci/vfio_pci_dmabuf.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > index 5fceefc40e27..85056a5a3faf 100644
> > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> > @@ -31,6 +31,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf,
> > if (priv->revoked)
> > return -ENODEV;
> >
> > + if (!dma_buf_attach_revocable(attachment))
> > + return -EOPNOTSUPP;
> > +
> > return 0;
> > }
>
> We need to push an urgent -rc fix to implement a pin function here
> that always fails. That was missed and it means things like rdma can
> import vfio when the intention was to block that. It would be bad for
> that uAPI mistake to reach a released kernel.
>
> It's tricky that NULL pin ops means "I support pin" :|
>
I've been wondering about this for a while now, I've been sitting on the
following:
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index a4d8f2ff94e4..962bce959366 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -1133,6 +1133,8 @@ int dma_buf_pin(struct dma_buf_attachment *attach)
if (dmabuf->ops->pin)
ret = dmabuf->ops->pin(attach);
+ else
+ ret = -EOPNOTSUPP;
return ret;
}
But didn't get a chance to dive in the history yet. I thought there's a
good reason we didn't have it? Would it break exisitng dmabuf users?
Praan
On Wed, Jan 21, 2026 at 02:22:31PM +0000, Pranjal Shrivastava wrote: > On Wed, Jan 21, 2026 at 09:47:12AM -0400, Jason Gunthorpe wrote: > > On Wed, Jan 21, 2026 at 02:59:16PM +0200, Leon Romanovsky wrote: > > > From: Leon Romanovsky <leonro@nvidia.com> > > > > > > Use the new dma_buf_attach_revocable() helper to restrict attachments to > > > importers that support mapping invalidation. > > > > > > Signed-off-by: Leon Romanovsky <leonro@nvidia.com> > > > --- > > > drivers/vfio/pci/vfio_pci_dmabuf.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > > > index 5fceefc40e27..85056a5a3faf 100644 > > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > > > @@ -31,6 +31,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, > > > if (priv->revoked) > > > return -ENODEV; > > > > > > + if (!dma_buf_attach_revocable(attachment)) > > > + return -EOPNOTSUPP; > > > + > > > return 0; > > > } > > > > We need to push an urgent -rc fix to implement a pin function here > > that always fails. That was missed and it means things like rdma can > > import vfio when the intention was to block that. It would be bad for > > that uAPI mistake to reach a released kernel. > > > > It's tricky that NULL pin ops means "I support pin" :| > > > > I've been wondering about this for a while now, I've been sitting on the > following: > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index a4d8f2ff94e4..962bce959366 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1133,6 +1133,8 @@ int dma_buf_pin(struct dma_buf_attachment *attach) > > if (dmabuf->ops->pin) > ret = dmabuf->ops->pin(attach); > + else > + ret = -EOPNOTSUPP; > > return ret; > } > > But didn't get a chance to dive in the history yet. I thought there's a > good reason we didn't have it? Would it break exisitng dmabuf users? Probably every importer which called to dma_buf_pin() while connecting to existing exporters as many in tree implementation don't have ->pin() implemented. Thanks > > Praan
On Wed, Jan 21, 2026 at 04:25:28PM +0200, Leon Romanovsky wrote: > On Wed, Jan 21, 2026 at 02:22:31PM +0000, Pranjal Shrivastava wrote: > > On Wed, Jan 21, 2026 at 09:47:12AM -0400, Jason Gunthorpe wrote: > > > On Wed, Jan 21, 2026 at 02:59:16PM +0200, Leon Romanovsky wrote: > > > > From: Leon Romanovsky <leonro@nvidia.com> > > > > > > > > Use the new dma_buf_attach_revocable() helper to restrict attachments to > > > > importers that support mapping invalidation. > > > > > > > > Signed-off-by: Leon Romanovsky <leonro@nvidia.com> > > > > --- > > > > drivers/vfio/pci/vfio_pci_dmabuf.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c > > > > index 5fceefc40e27..85056a5a3faf 100644 > > > > --- a/drivers/vfio/pci/vfio_pci_dmabuf.c > > > > +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c > > > > @@ -31,6 +31,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, > > > > if (priv->revoked) > > > > return -ENODEV; > > > > > > > > + if (!dma_buf_attach_revocable(attachment)) > > > > + return -EOPNOTSUPP; > > > > + > > > > return 0; > > > > } > > > > > > We need to push an urgent -rc fix to implement a pin function here > > > that always fails. That was missed and it means things like rdma can > > > import vfio when the intention was to block that. It would be bad for > > > that uAPI mistake to reach a released kernel. > > > > > > It's tricky that NULL pin ops means "I support pin" :| > > > > > > > I've been wondering about this for a while now, I've been sitting on the > > following: > > > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > > index a4d8f2ff94e4..962bce959366 100644 > > --- a/drivers/dma-buf/dma-buf.c > > +++ b/drivers/dma-buf/dma-buf.c > > @@ -1133,6 +1133,8 @@ int dma_buf_pin(struct dma_buf_attachment *attach) > > > > if (dmabuf->ops->pin) > > ret = dmabuf->ops->pin(attach); > > + else > > + ret = -EOPNOTSUPP; > > > > return ret; > > } > > > > But didn't get a chance to dive in the history yet. I thought there's a > > good reason we didn't have it? Would it break exisitng dmabuf users? > > Probably every importer which called to dma_buf_pin() while connecting > to existing exporters as many in tree implementation don't have ->pin() > implemented. Fair point. I agree with Jason that we cannot leave this open for VFIO and we can have a pin op that always fails. But at the same time, I'd like to discuss if we should think about changing the dmabuf core, NULL op == success feels like relying on a bug I agree that it means the exporter has no mm, but I believe there should be some way for the importer to know that.. the importer can still decide to use the exported dmabuf while being aware. Thanks, Praan
On Wed, Jan 21, 2026 at 02:47:29PM +0000, Pranjal Shrivastava wrote: > But at the same time, I'd like to discuss if we should think about > changing the dmabuf core, NULL op == success feels like relying on a bug Agree, IMHO, it is surprising and counter intuitive in the kernel that a NULL op means the feature is supported and default to success. Jason
On 1/21/26 14:47, Jason Gunthorpe wrote: > On Wed, Jan 21, 2026 at 02:59:16PM +0200, Leon Romanovsky wrote: >> From: Leon Romanovsky <leonro@nvidia.com> >> >> Use the new dma_buf_attach_revocable() helper to restrict attachments to >> importers that support mapping invalidation. >> >> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> >> --- >> drivers/vfio/pci/vfio_pci_dmabuf.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c >> index 5fceefc40e27..85056a5a3faf 100644 >> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c >> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c >> @@ -31,6 +31,9 @@ static int vfio_pci_dma_buf_attach(struct dma_buf *dmabuf, >> if (priv->revoked) >> return -ENODEV; >> >> + if (!dma_buf_attach_revocable(attachment)) >> + return -EOPNOTSUPP; >> + >> return 0; >> } > > We need to push an urgent -rc fix to implement a pin function here > that always fails. That was missed and it means things like rdma can > import vfio when the intention was to block that. It would be bad for > that uAPI mistake to reach a released kernel. > > It's tricky that NULL pin ops means "I support pin" :| Well it means: "I have no memory management and my buffers are always pinned.". Christian. > > Jason
© 2016 - 2026 Red Hat, Inc.