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 <[email protected]> > > > > > > > > Use the new dma_buf_attach_revocable() helper to restrict attachments to > > > > importers that support mapping invalidation. > > > > > > > > Signed-off-by: Leon Romanovsky <[email protected]> > > > > --- > > > > 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
